Google Demoted Your Page for a Schema Error You Can’t Find

Your schema passes every validator, the Rich Results Test reports no errors, and yet the rich results are gone and there is no manual action in Search Console to appeal. The reason you cannot find the error is that it is not a syntax error. Validators check structure and required properties; they do not check whether your markup tells the truth. Google’s quality systems cross-reference what your schema claims against the visible page, user behavior, and patterns across your site, and when the markup misrepresents the page, they can algorithmically suppress your rich results, sometimes site-wide, with no notification and no reconsideration path. Recovery is auditing every property for accuracy and waiting for Google to re-trust the site.

The boundary that makes this case distinct: if your schema were simply absent, the testing tool would tell you so and the fix would be to restore it. Here the tool says everything is fine. That inversion (valid but suppressed, versus gone) is the entire diagnosis, and it rules out the manual-action-and-reconsideration playbook entirely. This is algorithmic. There is nothing to file.

Two layers: technical validity and content accuracy

Structured data is judged on two separate axes that people collapse into one.

The first is technical validity: is the JSON-LD well-formed, are the required properties present, does it parse. This is what the Rich Results Test and the structured-data validators measure, and passing it is necessary but not sufficient.

The second is content accuracy: does the markup faithfully describe what is actually on the page and true about it. Google’s systems compare the schema against the visible content a user sees, against how users behave when they arrive, and against patterns across your whole site. A plugin that passes validation will faithfully output whatever you feed it, accurate or not, which is why the plugin is almost never the culprit. The markup is correct as code and wrong as a claim.

The canonical trigger: ratings that are not ratings

The most common cause of accuracy-based suppression is an AggregateRating that did not come from genuine reviews. Google’s review-snippet guidance is explicit that ratings must reflect real user reviews, and the rating and review count in your markup must match what is actually visible on the page. The violations that get sites demoted are the ones where the stars are manufactured.

Computing an aggregate rating from engagement signals (saves, prints, time on page) and presenting it as a user rating is a fabrication in Google’s eyes. So is seeding a baseline star value so nothing ever shows as unrated, or running content through a “quality score” and exposing that as a rating. So is a count mismatch, where the schema claims a number of ratings the page cannot show. Each of these passes validation because the number is a valid number; each fails accuracy because the number does not represent what it claims to represent. There is also a self-serving restriction: an organization or local business rating itself through its own schema is ineligible for the star rich result regardless of how genuine the underlying reviews are.

Other accuracy traps validators never surface

Ratings are the headline case, but any property that misstates the page is a candidate for the same treatment.

Count mismatches extend beyond reviews: a recipe that claims more steps or yields than the page contains, an item list whose count does not match its items. Unrealistic times are a quiet one, because user behavior exposes them. If a recipe’s stated cook time is shorter than anyone can actually achieve, users return to the search results quickly, and that pogo-sticking is a signal the page did not deliver what the markup promised. Serving sizes, authorship claims without a real author behind them, and any property where the schema is aspirational rather than descriptive all sit in this category. The common thread is that none of them is a syntax problem, so none of them shows up in a tool that only checks syntax.

A long history of clean rich results is not a shield. Sites assume that years of working markup prove the schema is fine, but trust systems evolve, and a site-wide pattern of inflated or invented values eventually crosses a threshold. The markup did not change; the evaluation did. “It worked for years” is a description of the past, not a defense.

The site-wide dimension is the part that makes this expensive. Google’s evaluation of structured-data trust is not strictly per-URL; a pattern of inaccurate markup across many pages can lower how much Google trusts the markup on the whole property, which is why a single product line with manufactured ratings can drag rich results across an otherwise honest catalog. That is also why the fix has to be comprehensive rather than surgical. Correcting the three worst pages while leaving the same inflated pattern on three hundred others leaves the site-wide signal intact, and the rich results do not come back. You are restoring trust in the property’s markup as a whole, not patching individual entries.

The mental model: bad data is worse than no data

Treat accurate-but-absent and inaccurate-but-present as genuinely different states, with the inaccurate one being the more damaging. A page with no schema is simply not eligible for the rich result. A page whose schema misrepresents it has given Google a reason to distrust the markup, and that distrust can generalize across the site. It is closer to a bad credit score than to no credit history: the negative signal actively works against you in a way that mere absence does not.

This reframes the fix. The instinct is to “fix the schema” by tweaking properties to look better, but the only durable move is to make every property true, even when that means showing a worse number or no number at all.

Recovery: audit, strip, keep the truth, wait

There is no button to press, so recovery is a discipline rather than a request.

Audit every property in your structured data against the visible page content, one by one. For each claim the markup makes, confirm the page actually shows it and that it is true. Strip any rating that is not sourced from genuine reviews; if you cannot substantiate a property, remove it. Where the choice is between an inaccurate value and no value, choose no value, because inaccurate markup is the thing being penalized.

Keep the corrected schema in place rather than deleting all structured data. Full removal guarantees you will never earn the rich result again, which is the wrong direction; accurate markup keeps you eligible once trust returns. Then wait for recrawl and algorithmic reevaluation. There is no confirmation event, no message that says you have been cleared, and no timeline you can state as fact. You will know it worked when the rich results come back, and the only thing under your control is making sure the data is honest enough to deserve them.

Frequently Asked Questions

Should I file a reconsideration request?

No. Reconsideration requests apply to manual actions, and this is not a manual action. There is no manual action in your Search Console for this case, which is exactly why the tool and the messages give you nothing to find. Recovery is automatic once the data is accurate and Google reprocesses the site.

Will removing all my schema fix it faster?

It removes the inaccurate signal, but it also makes you permanently ineligible for the rich result. The better move is to keep schema that is accurate and remove only the properties you cannot substantiate, so you stay eligible when algorithmic trust is restored.

Sources

Review snippet (Review, AggregateRating) structured data: https://developers.google.com/search/docs/appearance/structured-data/review-snippet
Structured data general guidelines: https://developers.google.com/search/docs/appearance/structured-data/sd-policies