Visibility and reach
When ranking is not the problem: X/Twitter visibility filtering explained
A post cannot win a ranking contest it was never allowed to enter. X filters candidates before scoring and checks visibility again after selection, but many of those decisions are personal to the viewer rather than account-wide penalties.
The short answer
X/Twitter makes two separate decisions about a recommended post. Ranking decides where an eligible candidate should appear. Visibility filtering decides whether that candidate may be shown, removed, or placed behind an interstitial.
The public pipeline also removes routine mismatches before scoring: duplicates, older posts, content already seen, muted keywords, blocked accounts, inaccessible subscriber posts, and other candidates that do not fit the request.
Those mechanics do not prove that every reach drop is a penalty. Many filters describe one viewer's preferences or history. A person who muted a keyword will not see the same candidate set as someone who did not.
Pre-scoring filters remove posts that should not compete
The official filtering table lists the filters and their order. Several are simple request hygiene rather than judgments about quality.
| Filter type | Example | What it means |
|---|---|---|
| Duplicate control | The same post came from two retrieval sources | Keep one candidate |
| Freshness | The post is older than 48 hours | Remove it from this For You candidate path |
| Viewer history | The viewer already saw or received the post | Avoid serving it again |
| Viewer choice | The author is blocked or muted, or the text matches a muted keyword | Respect that viewer's settings |
| Access | The viewer cannot open a subscriber-only post | Remove an inaccessible candidate |
| Recommendation context | Some out-of-network replies or reposts are ineligible | Narrow discovery outside followed accounts |
A filtered candidate never reaches the scoring stage for that request. Improving its predicted like probability would not matter because it is no longer in the race.
Visibility rules answer a different question
After X ranks and selects candidates, its visibility service evaluates the post for that viewer and safety level. The service can return outcomes such as show, drop, or show behind an interstitial.
The August 2026 release added public code for visibility filtering and several systems that produce labels used by those rules. The label sources cover text and media classification, account behavior, reports, adult content, spam, and enforcement.
This is more specific than saying "safety affects reach," but it still does not let an outsider determine every label applied to one post from the code alone.
Some rules only affect recommendations
X documents an additional set of rules for posts recommended from accounts the viewer does not follow. Those rules can remove a candidate from out-of-network recommendations while still allowing a follower to see it.
That distinction can create a confusing result: existing followers continue to see a post, while discovery beyond the network is limited. It is one possible explanation, not a diagnosis you can make from a low impression count.
Why "shadowban" is usually too vague to help
The word can refer to several different symptoms:
- fewer impressions than usual;
- no discovery among non-followers;
- search or reply visibility changes;
- a label or rule that limits recommendations;
- a normal weak result compared with an unusual previous post.
Those situations do not share one cause. Calling all of them a shadowban prevents a useful diagnosis.
If your engagement fell, start with the observable split between reach and response. The guide on why tweets stop getting engagement walks through that check without assuming a visibility penalty first.
Check Under the Hood when it is available
X launched an Under the Hood transparency page alongside the repository update. X says it shows aggregate statistics about visibility-impacting labels applied to an account and its posts, with availability expanding over time.
This is the first-party place to inspect possible labels. It is more useful than a third-party "shadowban test" that cannot see X's internal decisions.
Aggregate statistics still have limits. They may show that labels exist without proving which label caused the result of one post or how much distribution changed.
A practical reach diagnosis
Use this order before changing your entire content strategy:
- Compare impressions with your normal median, not your largest recent post.
- Check whether response rates changed with reach or stayed close to normal.
- Separate original posts from replies and compare like with like.
- Check for obvious changes in topic, audience, publishing volume, or timing.
- Review X's Under the Hood report if it is available on the account.
- Test one change across several posts before calling the result fixed.
The public code can explain the categories of filtering. It cannot identify the cause of one account's drop from the outside.
What PilotMyX can and cannot show
PilotMyX does not have access to X's private ranking scores or hidden labels. It cannot promise to detect a visibility restriction.
It can make the observable diagnosis faster by keeping posts and replies with their available metrics, showing freshness timestamps, and helping an AI agent compare periods without mixing unlike samples. That tells you whether the change looks broad, tied to a content group, or dominated by one outlier.
Use the result to decide whether you need a content test, more time, or a closer look at X's own transparency data.
Use your own account