Why Does Your Schema Validate But Not Show?

My schema validates. Why does nothing show up in search?

Because validation and eligibility are different tests, and passing the first says almost nothing about the second. A validator checks that your markup is well formed and uses recognized properties. Whether Google chooses to render a rich result from it depends on policy, page quality and its own judgment, none of which a validator inspects.

This is the most common structured data frustration I am asked about, and it is usually not a bug. The markup is fine. The page is failing a rule that has nothing to do with syntax, and the validator was never going to tell you that.

So here is what each check actually proves, in the order I would work through them.

What does validation actually prove?

That your syntax parses and your properties exist. The Rich Results Test and the Schema Markup Validator confirm the structure is legal and that you have not misspelled a field name or nested something in the wrong place. Those are real problems worth catching, and they are the shallowest layer of what can go wrong.

What it cannot check is whether your markup is true. No tool can look at a review rating of five stars and determine whether anybody left that review. Truthfulness is exactly where structured data goes wrong most consequentially, and it is invisible to every automated checker.

So I treat a passing validator as the beginning of the work. Green means you may proceed, not that you have done anything right. People stop at green constantly, which is why so much markup is both valid and useless.

What does Google actually say about guarantees?

It says there are none, in plain words. Its structured data general guidelines state that Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly. That single sentence resolves most of the confusion I encounter.

Read it carefully, because it rules out a whole category of explanation. If correct markup does not guarantee a rich result, then the absence of a rich result is not evidence that your markup is incorrect. People spend days re-checking syntax that was never the problem.

What that sentence should change is your expectations rather than your effort. Mark up your pages properly because it is the right way to describe them, and treat any rich result as an outcome you have made possible rather than one you have purchased.

Which rule do sites break most often?

The visibility one, and the wording is unambiguous. Google's guidelines say not to mark up content that is not visible to readers of the page. A great deal of markup in the wild describes things a human visitor cannot find, and that is a policy problem rather than a technical one.

The pattern I see most is markup generated from a database field that is no longer rendered. Somebody removes a section from the template, the field stays populated, and the structured data keeps describing content that is not on the page. Nothing errors, and the page is now making a claim it does not support.

The second pattern is deliberate and worse, which is marking up answers that exist only in the markup because somebody read that it helps. If a reader cannot see it on the page, it should not be in your structured data, and that rule is simple enough to check by eye.

What does a true representation rule out?

Google's guidelines require that your structured data must be a true representation of the page content, and that constraint is stricter than people assume. It is not enough for each field to be individually defensible. The markup as a whole has to describe what the page actually is.

In practice that rules out a few tempting moves. Marking a thin page as an Article or BlogPosting with full detail. Describing a blog post as a Product. Attaching AggregateRating to something that is not really reviewed. Each of those might pass a validator while plainly misdescribing the page to anyone who looked.

It also rules out letting markup drift. A page you substantially rewrote is a different page, and markup written for the old version may no longer represent it. I would re-read the structured data whenever the content changes meaningfully, which is the same discipline as keeping dates honest.

Can you actually be penalized for this?

Yes, and Google says so directly. Its guidelines state that structured data issues can result in a manual action, and that a structured data manual action means a page loses eligibility for appearance as a rich result. So the downside is not merely that nothing shows, it is that nothing can show.

That changes the risk calculation on anything clever. The upside of aggressive markup is a slightly richer listing. The downside is losing eligibility on a page you care about, plus the time spent getting it back. I have never seen that trade be worth taking.

It also means you should check Search Console rather than assuming silence is neutral. Silence might be a policy decision you have not been told about in the place you were looking, and the report is where that sort of thing surfaces. I wrote about working through those specifically in finding schema errors in Search Console.

How do you tell whether your type is eligible at all?

By checking Google's own documentation for the specific search feature you want, rather than inferring it from schema.org. Those are two different vocabularies in practice. The schema.org vocabulary is large and describes far more than any search engine renders, so valid markup for a type nobody displays will never produce anything.

I am not going to list which types currently produce which results, because that set changes and a list written today would quietly become wrong. The durable advice is to find the Google documentation page for the feature itself and read the requirements there, since that page is the only authority on what it needs.

This is also where expectations go wrong in a specific way. People add markup for a type that was displayed at some point in the past, see nothing, and conclude their implementation failed. Checking whether the feature still exists is a faster first step than debugging your code.

What else stops valid markup from showing?

Three things I check in order. Whether the page is indexed at all, because a page that is not in the index cannot produce any kind of result. Whether the markup is actually in the served HTML rather than injected later by a script. And whether the page itself is strong enough to appear for the query in question.

That third one is the least discussed and often the real answer. Rich results decorate a listing that already ranks. If your page does not rank on the first page for anything, there is no listing to enhance, and no amount of markup changes that. People treat structured data as a ranking tactic when it is a presentation layer.

The script-injection case is worth checking specifically on sites with heavy client-side code. View the page source as delivered, not the inspected document after scripts run, and confirm your markup is actually there. On a Webflow site that usually means checking what your JSON-LD embed outputs rather than what you intended it to output, and confirming the same in Chrome DevTools against the raw response.

How should you debug this in order?

Cheapest checks first. Confirm the page is indexed. Confirm the markup is in the served HTML. Run the validator for syntax. Then read the policy guidelines against your own page honestly, specifically the visibility rule and the true-representation rule. Only after all of that would I suspect something unusual.

Doing it in that order matters because each step is faster than the one after it, and because the common causes are near the top. Most of the time I get to step four and find that the page is marking up something a visitor cannot see, which was visible from the start if anybody had read the markup next to the page.

What I would stop doing is re-running the validator repeatedly. If it passed once, it will pass again, and the loop feels productive without moving. That time is better spent on the question of whether your markup honestly describes what a visitor sees, which is also the question I ask about machine-generated schema markup.

What should you do next?

Open one page where markup is not showing, and read your structured data side by side with the rendered page. Check every claim in the markup against something a visitor can actually see. That comparison finds the problem more often than any tool, and it takes ten minutes.

Then decide whether you still want the markup. Some of it is worth having purely as an accurate description of the page, regardless of whether a rich result appears, because accurate description helps anything reading your site. Some of it was only ever there in hope of a listing feature and can be deleted. After 350 articles I have removed more markup than I have added, including the FAQ markup I used to add by default.

If you have a Webflow site where schema validates and nothing appears, and you want someone to work out which of these it is, reach out. It is usually one of the first four checks.