Does Your Structured Data Have to Match What the Page Says?

Does your structured data have to match what the page actually says?

Yes, and Google says so plainly. Its structured data general guidelines state that your structured data must be a true representation of the page content, and that you should not mark up content that is not visible to readers of the page. Markup that describes a better page than you published is a policy problem.

This sounds obvious and is violated constantly, almost never on purpose. Markup gets written once, the page gets rewritten three times, and nobody goes back to check whether the two still agree. Six months later the page says one thing and the JSON-LD says another.

I have written several hundred articles about schema and how answer engines read pages, and mismatch is the single most common problem I find on sites that have implemented structured data properly at some point.

What exactly does Google ask for?

Three things, in its own words. That your structured data must be a true representation of the page content. That you should not mark up content that is not visible to readers of the page. And that you should specify all required properties listed in the documentation for your specific rich result type.

The visibility requirement is stricter than people assume. Google's example is direct: if the JSON-LD markup describes a performer, the HTML body must describe that same performer. It is not enough for the fact to be true, or to be somewhere else on your site. It has to be on that page, visible.

The completeness requirement has a concrete consequence attached. Google's guidelines say that items missing required properties are not eligible for rich results. That is not a penalty, it is simply ineligibility, and it is the most common reason markup does nothing at all.

What happens if the markup and the page disagree?

Google's guidelines say that a structured data issue on a page can result in a manual action, and that a structured data manual action means the page loses eligibility for appearance as a rich result. The same guidelines add that it does not affect how the page ranks in Google web search.

That last clause is worth reading carefully, because it is more reassuring than most people expect and it also removes a common excuse. The downside is bounded and specific: you lose the enhanced appearance, not your position. Which means the risk of sloppy markup is real but contained.

The practical reading is that you should implement structured data because you want the enhanced appearance and the clarity it gives machines, not because you expect a ranking effect. Framing it honestly makes the maintenance conversation with a client much easier.

Why does markup drift out of sync in the first place?

Because it lives somewhere different from the content. On a CMS driven site the visible copy sits in fields a marketer edits weekly and the markup sits in a template a developer touched a year ago. Two systems, two owners, two update schedules, and no mechanism connecting them.

Hard coded values in a template are the worst offender. A schema block with a fixed author name, a fixed date, or a fixed price will keep asserting that value forever regardless of what the page shows. It was correct the day it was written and has been quietly wrong ever since.

The fix is structural rather than vigilant. Bind every schema property to the same CMS field that renders the visible content, so that changing the field changes both. Markup that cannot drift is better than markup somebody has promised to check, because nobody checks.

Which properties go wrong most often?

Dates, authors, prices, and ratings. Dates because a published date gets hard coded and a modified date never updates. Authors because bylines change. Prices because they live in two places. Ratings because they are the most tempting thing to assert without a visible equivalent.

Dates deserve a particular mention because Google's guidelines also ask you to provide up to date information and state that it will not show a rich result for time sensitive content that is no longer relevant. A modified date that never moves is a claim about freshness that your content is not supporting.

Ratings are where good intentions turn into a policy problem fastest. If the markup asserts a rating, the page has to show that rating to readers. Aggregate review markup on a page with no visible reviews is exactly the case Google's visibility rule exists to prevent.

How do you audit a page for mismatch?

Open the page, open its structured data, and read them side by side property by property. Ask of each property whether a person reading the page would be able to find that same fact. Where the answer is no, either add it to the page or remove it from the markup.

Do this on one page per template rather than on every page. On a CMS site the markup is generated the same way for every item, so a problem on one blog post is a problem on all of them, and checking one well is more useful than skimming forty.

Validation tools will tell you whether your markup is syntactically valid and whether required properties are present. They cannot tell you whether the content of the properties matches your page, because they do not know what your page means. That comparison is a human job and it is the one that matters, which is a distinction I have made before in which schema types are worth the maintenance.

Does any of this matter for AI answer engines?

It matters for a different reason. Answer engines do not owe you a rich result, so the eligibility question is irrelevant to them, but a page whose markup contradicts its prose is a page giving two different answers to the same question, and ambiguity is not what gets a page quoted confidently.

Markup that agrees with the page is a second, machine readable statement of the same fact. That redundancy is useful. It confirms what the prose says in a format that requires no interpretation, which is exactly what you want when something is deciding whether your page is a reliable source for a claim.

What it will not do is rescue a page that does not say anything clearly. Schema describes content, it does not create it, and a vague page with immaculate markup is still a vague page. Write the sentence first and mark it up second.

Who should own this on a small team?

Whoever owns the template, with a standing note that any change to what a page asserts is also a change to its markup. On teams of two or three this is usually the same person, and the risk is that the two tasks feel unrelated because they happen in different tools.

Add a line to whatever checklist governs a content change asking whether this edit affects a schema property. Most edits will not. The ones that do are the price, the author, the date, and anything you have chosen to assert as a rating or an offer.

Review the whole setup once a year, on a date you have chosen in advance. Structured data requirements change, your page templates change, and an annual read of the current guidelines against your actual output catches the drift that a checklist cannot.

What should you do next?

Pick your most important template, open one page from it, and compare its markup to its visible copy property by property. Remove anything asserted that a reader cannot see, and add anything to the page that you want the markup to claim.

Then find every hard coded value in your schema template and bind it to the field that renders the corresponding visible content. That one change prevents most future drift and takes less time than the audit you just did. The same principle applies to the way your title, heading, and social tags should agree with each other, which I covered in how to fix a page that gets impressions but no clicks.

If you have schema on your site and no idea whether it still matches your pages, send me a URL. I am happy to read the two side by side and tell you what I would change.