X Algorithm Labels Explained: How Visibility Filtering Works

X can leave a post visible to its author and followers while preventing that same post from being recommended to non-followers. The mechanism is not hidden speculation anymore. It appears in the open-source X recommendation code as a system of account labels, post labels, and visibility rules.

The published names are unusually direct. An account can be marked SpamHighRecall, AbusiveHighRecall, ImpersonationHighPrecision or even DoNotAmplify. Individual posts have another set of labels for spam, malicious URLs, abuse, adult content, violent speech, and other policy categories.

How X labeling and visibility filtering work

X’s open-source For You repository separates recommendation ranking from visibility filtering. Candidate posts are sourced, hydrated, filtered, scored, mixed, and then passed through visibility rules before the final feed is served. Labels are produced continuously and stored so those rules can use them when a recommendation is evaluated.

A visibility decision is contextual. It can consider the post label, the account label, whether the viewer is the author, whether the viewer follows the author, the viewer’s age, and the product surface. The same post can therefore be allowed for one person and dropped for another.

1. X labels the account or post. The labels describe suspected spam, authenticity, safety, adult-content, or policy conditions.
2. The ranker scores candidates. Engagement predictions and other ranking signals determine the order of eligible candidates.
3. Visibility rules evaluate each result. A rule can allow the post, put it behind an interstitial warning, or drop it from the surface.
4. The viewer receives the filtered feed. A follower, non-follower, minor, logged-out visitor, and the author may not receive the same outcome.

This is the distinction most algorithm advice misses. A weak score and a visibility drop can produce the same surface symptom: low reach. They are not the same failure.

The real X account labels published in the code

X’s Under the Hood label catalog publishes 12 account labels and their user-facing explanations. All 12 are included below, with related labels grouped together. These are internal names from the repository, not labels invented by creators.

The repeated phrase matters: hidden from recommendations to non-followers. That is narrower than deletion and broader than simply receiving a weak ranking score. The content remains available in some contexts while discovery is restricted.

What DoNotAmplify means on X

DoNotAmplify is the clearest example because its name describes its purpose. The public account-label text says X believes the account is likely to violate its Terms of Service and that the account is pending further review. While that label is active, its posts are hidden from recommendations to non-followers.

There is also an uppercase post label named DO_NOT_AMPLIFY. X describes that one as a legacy label for malicious links that has been replaced by MALICIOUS_URL. The similar names refer to different label types, which is easy to miss when discussing the code.

The post labels that can limit reach

The same catalog publishes 18 post labels. All 18 are included below, with related labels grouped together. Post-level labels can produce more varied outcomes than account labels. Some limit recommendations. Others add a warning, restrict the post to the author’s profile, or stop the post from being shown anywhere.

The exact implementation appears in X’s post-label drop rules. Several rules explicitly exempt the post’s author, which explains how restricted content can still look live when viewed from the account that published it.

Why your post can look normal while discovery is restricted

The account-label rules first check whether the viewer is the author. If so, the content is allowed. For selected rules, the code then checks whether the viewer follows the author. If the viewer is a follower, the post is allowed. A non-follower receives a DROP result.

X publishes this logic directly in its user-label visibility rules. It creates a specific form of limited distribution:

• The author can open the post and see it normally.
• Existing followers may continue to see and engage with it.
• The post can still collect likes and replies from that existing network.
• Non-followers may never receive it through the recommendation surface.

This mechanism can produce the experience people casually call a shadowban. The code does not support diagnosing every low-reach post that way. Reach can also fall because of weak predicted engagement, audience mismatch, competition, freshness, or diversity rules. A visible post with low impressions is evidence of low distribution, not proof of a label.

What X’s Under the Hood feature actually reveals

X added an Under the Hood tool to expose aggregate statistics for supported labels that can limit visibility. The published serving schema tracks account labels by active days and post labels by days carried or removed within monthly reports.

That is useful transparency, but it has limits. The public implementation uses an allowlist of labels with user-facing descriptions. X also states that some rules and prompts are omitted from the repository to reduce gaming and abuse. Under the Hood should therefore be read as a supported view into the system, not a complete export of every internal trust or safety signal.

What creators should learn from the label system

1. Separate ranking problems from eligibility problems

Rewriting a hook can improve predicted engagement. It cannot fix an active account-level restriction. Diagnose the category before optimizing the copy.

2. Do not use your own profile as the visibility test

The published rules often allow authors to see their own posts. Being able to open a post confirms that it exists. It does not confirm that it is eligible for non-follower recommendations.

3. Treat account health as a distribution input

Spam, impersonation, compromise, abuse, profile imagery, and malicious links are not only moderation concerns. In the published system they can change access to recommendation surfaces. Account security and policy compliance belong in any serious growth strategy.

4. Avoid pretending the labels explain every bad result

Most disappointing posts are probably just disappointing posts. The valuable lesson is not to blame the platform automatically. It is to recognize that content quality and recommendation eligibility are separate variables, then use the evidence available to determine which one failed.

For the ranking side of the system, read our guide to how the X algorithm works. To compare reach against your own baseline instead of guessing, use the ClimbX analytics dashboard.

Frequently asked questions

Ranking decides who wins. Labels decide who gets to compete.

The open-source release makes one thing clear: reach is not a single score. X first estimates which posts a viewer is likely to value, then applies a separate visibility system that can allow, warn, or drop those results. A post can be good enough to rank and still be ineligible for discovery.

That is the useful model for creators. Improve the post so it can win the ranking contest. Protect the account so the post is allowed into that contest in the first place.