A validator tells you the structured data is valid. It is checking syntax and required properties, which is a narrow question. It has no way to open the page, read it, and confirm that the claims match.
Google's guidelines for structured data are explicit on this point: the markup has to represent the content that is actually on the page, and content marked up but not visible to users is a policy violation rather than a technical warning. Valid and false is the combination that costs you something.
What counts as a contradiction?
Any claim in the markup that a reader of the page would not be able to verify by looking at it. The bar is what the visitor sees, not what exists somewhere in your database.
The common ones are dull and specific:
- An aggregate rating in the markup with no reviews shown on the page.
- A price in the markup that no longer matches the price in the template.
- Availability marked in stock while the page says the item is sold out.
- Questions and answers in FAQ markup that appear nowhere in the body.
- A publication date in the markup that disagrees with the byline.
- An author in the markup who is not credited on the page.
None of these are exotic. Each is the normal result of markup and content being produced by different systems on different schedules.
Why is a mismatch worse than missing markup?
Missing markup costs you a rich result you never had. A contradiction risks the rich results across the whole site plus the trust behind them.
Google treats structured data that misrepresents a page as a spam policy issue, and the response can be a manual action against structured data — which removes eligibility for rich results across the affected pages rather than fixing the one property that was wrong. Recovery requires a fix and a review, and the interval between those two events is entirely outside your control.
There is a slower cost as well. A searcher who clicks a result showing a rating and finds no reviews on the page has been misled by you, in public. That returns to the results page immediately, and no amount of valid schema markup compensates for a promise the page did not keep.
Validation answers "is this markup well formed". Nothing in your toolchain answers "is this markup true". That second question has no automated owner, which is exactly why contradictions survive for years.
Where do contradictions come from?
Almost always from a gap between two systems that were correct when they were built. Nobody writes false markup on purpose; they write markup against a template, and then the template changes.
| Source | How it happens | What goes stale |
|---|---|---|
| Plugin defaults | Markup generated from settings, not from the rendered page | Ratings, author, organization details |
| Product feeds | Markup built from the feed while the page renders from the catalog | Price, availability, currency |
| Template edits | A visible section is removed; the markup block is left behind | Review counts, FAQ entries |
| Caching layers | Markup cached separately from the content it describes | Anything that changes frequently |
| Client-side rendering | Content appears after load, markup is injected from a different source | Whatever the two disagree about |
The pattern is consistent enough to be useful: contradictions accumulate wherever markup is generated from a source other than the page itself. Product schema driven by a feed is the clearest example, because the feed and the page can be hours or days apart and both will look fine in isolation.
How do you find them?
Compare the rendered page against the rendered markup, on the same URL, at the same moment. Every step that drops one of those three conditions is how a contradiction gets missed.
A practical pass takes an afternoon:
- Pick one URL from each template — product, article, service, location — rather than auditing at scale. Contradictions are template-level, so one example finds the class.
- Read the markup as rendered, not as written in the source file. Anything injected after load has to be inspected after load.
- Read each property out loud as a sentence about the page: "this page shows 47 reviews averaging 4.6 stars." Then look for them.
- Check the properties nobody looks at — currency, availability, dates — because they fail silently and are the ones most often fed from elsewhere.
- Repeat on a page that changed recently. Freshly edited templates are where the drift is.
Search Console's enhancement reports are worth reading alongside this, but they report items that are invalid or missing required properties. A property that is present, well formed, and wrong is not an error to any tool, and it will not appear.
Treating a clean validation run as an audit. The validator confirmed you built the markup correctly. It has no opinion about whether the page agrees with it.
What do you do when the page and the markup cannot agree?
Change the page or delete the property. Those are the only two honest options, and the choice depends on whether the claim is one you want to make.
If the rating is real and simply is not displayed, display it — that is the better outcome anyway, since the same information now helps the visitor as well as the result. If the claim cannot be shown on the page, remove it from the markup. A smaller, accurate set of properties is worth more than a complete set that includes one that will not survive scrutiny.
What does not work is leaving it in place on the theory that nobody will check. The mismatch is machine-detectable by the party that decides your eligibility, and it is human-detectable by every visitor who clicks the result and looks for the reviews.
Who owns this after today?
Markup drifts because it has no owner once it is shipped, and the fix is to attach it to something that already gets checked. The most reliable version is to treat a change to a template as a change to its structured data, so the two move together instead of separately.
That is a process decision rather than a technical one, and it is the difference between finding a contradiction in a quarterly audit and finding it after the organic search traffic to a product template has already dropped.
Pick your highest-traffic template and read its markup as a set of claims about the page. Either everything in it is currently true, or you now know what the next fix is.
Not sure whether your markup still matches your pages?
We will audit your structured data against what the templates actually render and show you where the two have drifted apart.
Get in Touch →Does this apply to your site?
Reading about it is one thing. Point the scan at your own site and see whether this applies to you, and what it is worth fixing.
Free and unlimited. No account, no card, and you get every finding rather than a teaser.