Structured data that describes what the page doesn't show
Structured data is a factual claim about a page, not decoration. A rating or price a visitor cannot see is the riskiest field, and easy to leave in.
· 4 min read
What structured data is actually promising
Structured data — the JSON-LD block search engines read alongside a page's visible content — is not decoration copied from a tutorial. It's a machine-readable statement about what the page actually contains, written specifically because a search engine cannot always be certain how to interpret ordinary prose and images the way a person can. Adding a Product schema block with a price and a rating is, functionally, telling a search engine: this exact information is really here, verified, safe to surface directly in a search result.
Because that markup exists specifically to be trusted as a shortcut instead of re-parsing the page's prose, a mismatch between what it claims and what a visitor can actually see isn't treated as a stylistic slip. It's a trust problem, and search engines act on trust problems differently than they act on a merely thin or repetitive page — the entire value of a rich result rests on the promise that the marked-up fact is genuinely on the page behind it.
The mistake, and how ordinary it is
The way this usually happens has nothing to do with anyone trying to game a ranking. A business copies a schema template — Product, FAQ, LocalBusiness — from a generator or a tutorial, fills in the requested fields quickly to get a green checkmark, and includes a rating or a price the page doesn't actually display anywhere a visitor would see it. Sometimes the field felt required so it got filled with a plausible number. Sometimes the figure was true on an earlier version of the page and the page moved on without anyone remembering the markup underneath it.
None of this looks careless in the moment. It looks like completing a form correctly. That's exactly what makes it common: the mistake requires no bad intent and very little inattention — just a template with more fields than the page has visible answers for, and a business trying to be thorough.
Why this specific mismatch gets treated more seriously than most SEO mistakes
A page that's thin or repetitive costs rankings gradually, the way most on-page issues do. Markup claiming a review score, a price or an availability status a visitor can't verify by actually reading the page is a different category entirely, because the whole reason rich results exist — stars next to a listing, a price shown directly in search — depends on the promise that what's marked up matches what's shown. Break that promise and the rich result itself becomes the problem, not a bonus.
A stale or invented number that keeps surfacing in search results long after the page it described has changed is worse for the business than having no rich result at all — a visitor arrives expecting a rating or a price that isn't there, the mismatch is now visible to them directly rather than hidden in code, and the business's own markup produced the bad first impression.
What checking this from a page's own HTML can catch
A genuinely free, no-vendor check is possible here, and it runs in two directions. Generating markup can refuse outright to emit a value the page's own visible text doesn't actually contain — checking a name, a headline, a price, a rating value or a review count against the page's own text before writing it into the markup, with a rupee figure shown as plain text on the page treated as satisfying the equivalent number in the JSON-LD.
The same rule reads just as well backwards, over markup somebody else already wrote: scanning existing JSON-LD on a page and flagging any property whose value doesn't actually appear anywhere in the page's own text as an error, and separately flagging any schema block that's missing a required property for its declared type as a warning — because incomplete required fields get quietly ignored by search engines while still looking finished to whoever wrote them, which is arguably worse than having no markup there at all. Both directions come entirely from the page's own HTML; no paid data is needed to catch this specific class of mistake.
The refusal that matters most: no rating, no review count, unless it's real
A rating value or a review count is the single highest-risk field in any schema block, because star ratings displayed directly in a search result are the most visible thing a mismatch damages — a visitor sees the stars before they ever load the page, and the disappointment when the page doesn't match happens instantly and publicly. The only honest fix is sequencing: display the real number on the page itself first, and only then mark it up to match — never invent a starting figure, never leave an old rating in the markup after the page it described has changed, and never fill in whatever placeholder value a generator suggested to get past a required field.
This piece takes that discipline seriously about itself, not just as advice to hand out: it carries no Review or AggregateRating markup anywhere, and neither does any other page in this article set — the JSON-LD attached to this article is Article type and nothing else, which is the only honest way to write about this specific mistake without making it on the page making the argument.
A short self-check before publishing new markup
Before publishing any new structured data, open the rendered page and read every value sitting in the JSON-LD block one at a time, asking of each: could a visitor confirm this by reading the page right now, with nothing else open, no other tab, no external source? If the honest answer is no for even a single field, that field is the one about to cause a problem — remove it, or make the page itself true first, before the markup claims it.
The exact rules this checking runs on, and the difference between a missing-property warning and a not-on-the-page error, are documented in full at /docs/khoji, alongside the rest of what a page audit and a schema generator can honestly promise without a paid data source behind them.
Common questions
How does a search engine actually catch a structured-data mismatch?
By checking whether the values asserted in the JSON-LD block can be found in the page's own rendered content — the same comparison an honest schema generator runs on itself before ever publishing markup. A rating value with no corresponding number anywhere a visitor could read on the page is exactly the pattern this check is built to catch.
Is it safer to just leave a rating field blank than to guess a number?
Yes, structurally so — a schema block missing a rating is incomplete but not false. A schema block with an invented or stale rating is actively asserting something untrue, which is the category of mistake that gets acted on directly rather than simply reducing how a page ranks.
What if the number was true when I added it and the page has since changed?
Then the markup is now false, even though nothing was ever falsified on purpose. Structured data has no expiry mechanism of its own — it stays exactly as written until someone updates it, which means it needs to be revisited every time the page itself changes, not just written once and left alone.
Does this article use Review or AggregateRating schema anywhere?
No. This page, like every article in this set, carries only Article structured data — the same rule being described applies to the page describing it. Making the mistake this article is about, on the page arguing against it, would undercut the entire point being made.
Related pages