The page passes. You paste the URL into Google’s Rich Results Test, the check comes back green, and you close the laptop expecting star ratings to appear in search within a few days. A week later the listing is still a plain blue link. No stars, no FAQ dropdown, nothing. The markup is correct. The result is missing. That gap, between structured data that validates and a rich result that actually shows, is one of the most common sources of confusion in technical SEO, and little of it turns out to be a syntax problem.
Valid, eligible, and displayed are three different things #
The mistake underneath most of this frustration is reading “valid” as if it meant “will appear.” It does not. A page moves through three separate gates, and clearing one says nothing about the next.
The first gate is syntax. The structured data parses, the required properties are present, and a validator reports no errors. That is what “valid” means, and it is the only gate fully under your control.
The second gate is eligibility. Google turns only a subset of Schema.org types into rich results, and that list changes over time. Valid markup for a type Google no longer features earns nothing, however clean the code. FAQ markup is the clearest case. In an August 2023 change, Google’s Search Central documentation stated that FAQ rich results would be shown only for well-known, authoritative government and health sites, and that HowTo rich results would be limited to desktop before being removed. The markup on an ordinary business site still validates. It stopped being eligible.
The third gate is display, and this is the one nobody controls. Google’s own guidance is blunt: structured data makes a feature possible, it does not guarantee the feature appears. Even for an eligible type on an eligible site, Google decides for each page and each query whether to render the rich result. A green check in a validator confirms exactly one thing, the first gate, and stays silent about the other two.
The two tools, and what each one is telling you #
Some of the confusion is a leftover from tooling history. For years the Structured Data Testing Tool was the default check. Google announced its deprecation in 2020, the SEO community pushed back, and Google eventually moved the old tool to Schema.org, where it now runs as the Schema Markup Validator. Google’s own tool is the Rich Results Test. The two look almost identical and answer different questions.
| Tool | What it checks | What a pass actually means |
|---|---|---|
| Rich Results Test (Google) | Whether the page is eligible for a Google rich result, for the types Google features | The syntax is sound and the type can qualify. Display is still not promised. |
| Schema Markup Validator (Schema.org) | Whether the markup is well-formed against the Schema.org vocabulary | The schema is valid as schema. It says nothing about Google rich results. |
The practical result is that a clean pass in the Schema Markup Validator can sit next to an empty listing in search, and that is no contradiction. The validator confirmed the schema is well-formed. It never claimed Google would use it. When the question is specifically whether something will show in Google, the Rich Results Test is the closer answer, because it reports eligibility rather than generic validity.
Why a valid, eligible page can still show nothing #
Assume the syntax is clean and the type is one Google still features. A rich result can still be absent, and the reasons tend to cluster.
The page is not indexed. A rich result is a way of displaying an indexed page. If the URL is not in the index, there is nothing to decorate, and this is worth ruling out first because it is both common and invisible in a code-only test.
The marked-up content is not visible on the page. Google’s guidelines expect structured data to describe content a user can actually see. Review stars generated from data that appears nowhere on the rendered page, or FAQ markup whose questions sit behind a script that never runs, fall outside the guidelines even when the JSON parses cleanly.
There is a manual action. A structured data manual action means the page loses eligibility to appear as a rich result. Per Google’s documentation it does not change how the page ranks in ordinary web results, and it is triggered by patterns like marking up content invisible to users or marking up irrelevant or misleading content. Clearing it runs through the Manual Actions report and a reconsideration request, and those requests get rejected when the underlying markup still breaks the guidelines. That is why removing a single bad snippet is often not enough to lift it.
The report showed warnings, not errors. In Google’s validators, errors block the rich result and warnings do not. Warnings flag recommended properties that would strengthen the result if present. A page can carry a stack of warnings, read as eligible, and still render, so driving every warning to zero is rarely what unblocks a missing result.
It is Google’s call. Once indexing, visibility, guidelines, and eligibility all check out, the remaining variable is discretion, and there is no setting for it.
A debugging order that saves time #
When a rich result is missing, the fastest way to isolate the cause is to test the gates in the order Google applies them, rather than starting with the code.
The first step is confirming the page is indexed, using URL Inspection in Search Console. With no index there is no rich result, and the rest of the checks are moot. The second step is confirming the type is still featured, by checking whether Google currently documents a rich result for it, which is where FAQ and HowTo trip people who last looked years ago. The third step is running the Rich Results Test on the live URL rather than a pasted snippet, so the test sees the page Google renders, scripts and all, and reports whether it reads the page as eligible. The fourth step is confirming the marked-up content is visible on that rendered page and matches what a visitor sees. The fifth step is opening the Manual Actions report and the relevant enhancement report in Search Console. If all of that comes back clean, the sixth step is to treat the absence as discretion and stop, because past this point there is nothing left to fix.
That last step is the one people skip, and it costs the most time. A great deal of structured data debugging is largely the slow acceptance that the markup was never the problem.
Small sites and large sites hit this differently #
On a single page, a missing rich result is almost always an eligibility or type question. The markup validates, the type is restricted or the content is thin, and the fix is local. At that scale the temptation is over-engineering, piling on more schema types in the hope that volume forces a result, when volume is not the lever.
At the scale of a templated site, the same markup ships across thousands of URLs, so one template mistake becomes a sitewide pattern, and Google’s guidelines on irrelevant or invisible markup start to matter in aggregate. A spammy-markup manual action, when it lands, tends to be scoped to the pattern rather than one page, and the enhancement reports in Search Console become the practical way to see how far the problem spreads. The debugging order does not change. What changes is that the second gate, eligibility and guideline compliance, is now a template decision rather than a page decision, and fixing it once fixes it everywhere.
The honest limit #
The uncomfortable shape of structured data is that the one gate you can fully verify, syntax, is the gate that matters least to whether a rich result appears. Validators answer a real question, just a narrower one than the green check implies. Beyond it, eligibility moves with Google’s feature list and display stays at Google’s discretion, and cleaner markup buys past neither. Knowing which of the three gates you are actually stuck at is most of the work, and it is usually not the one the validator was testing.