Does your structured data say what the page says?
Structured data matches the visible text. Schema that contradicts the page reads as unreliable.
What the check looks at
The check takes the claims in a page's JSON-LD — the organization name, a product name and description, an article headline and author, each FAQ question and answer — and looks for them in the visible text. Names must match; prose is judged in the full read.
Why it matters
Schema that contradicts the page reads as unreliable. A FAQ answer in the schema that is not on the page, a headline that differs from the H1, a product name no visitor sees — engines learn to distrust the file, and a distrusted file grounds nothing.
How to see it on your own site
For each JSON-LD claim, find it on the page. The quick test: the FAQ questions in the schema and the FAQ questions on the page should be the same list.
Schema & entity check → — free, no signup.
How to fix it
- Generate the schema from the visible content, never beside it: the FAQ block and its FAQPage from one source.
- Headline = H1. Product name = the name on the page.
- When you rewrite a page, rewrite its schema in the same commit.
What the agent does: when the agent writes a FAQ block for a page, it writes the FAQPage schema from the same words — the two cannot drift.
Related checks
Part of the 23 checks · group: Brand identity — JSON-LD on the page, entity links (@id, sameAs), Wikidata record, consistent external profiles.
Questions people ask
Why is this "needs a full read" on the free check?
Names are compared as strings. Whether a long answer in the schema conveys the same fact as the prose needs a model to judge; the free structural check does the string part and marks the rest.
Start with the free check. Then tell the agent what you need.
The free check runs the 23 checks on your public pages. Nothing is installed, nothing changes until you press it.
Free check from outside in minutes · the report by email · nothing installed yet

