FAQ Schema vs. Your Actual Page Text: The Mismatch That Can Get You Flagged

You add FAQPage schema to a page. The questions are good, the answers are tight, and Google Search Console shows it validating cleanly. Then it quietly stops showing up as a rich result, or worse, an AI answer engine lifts a "fact" from your schema that nobody reading the actual page would ever see. The schema was valid JSON. It just wasn't true to the page.

What Google's policy actually says

Google's structured data general guidelines are specific about this: the markup has to represent content that's actually on the page, visible to a visitor, not content that only exists inside a <script type="application/ld+json"> tag. Google has pulled or ignored structured data from sites where the schema answers don't match the visible text. A valid JSON-LD block only gets you past the syntax check. It doesn't get you past this one, and this one isn't checked by any JSON validator — only by comparing schema text against rendered text.

Why AI answer engines care even more than Google does

When an AI assistant cites your page, it's not citing your page. It's citing a claim it believes your page supports. If a user later clicks through and can't find the sentence the assistant quoted, that's not a ranking problem — it's a trust problem, and it's the kind of thing that gets a domain treated as unreliable going forward. A model pulling "yes, free returns within 90 days" out of your FAQPage schema when the actual page copy says something different (or doesn't mention it at all) is a liability, not a win.

The irony is that FAQPage schema exists specifically to make a page more citable. Used accurately, it's one of the most reliable ways to get a clean, attributable answer picked up. Used as a shortcut to stuff keywords or promises that never made it into the visible copy, it does the opposite.

How the mismatch actually happens

Nobody sets out to fake their schema. It drifts:

• A marketing edit updates the on-page FAQ copy, and the JSON-LD block three files away in the template doesn't get touched.
• The schema was written first, as a content outline, and the final page copy diverged from it before publish.
• A migration moves content between templates and the old hardcoded schema comes along for the ride, pointed at new page text.
• Someone writes schema answers that are more complete or more flattering than what's actually written on the page, assuming nobody checks.

All four produce the same JSON-LD-is-valid, page-is-wrong result, and all four are invisible to a schema validator, because a validator only checks that the JSON parses and the required fields are present. It has no idea what your page says.

How to check it yourself

The direct way: open the rendered page, open the JSON-LD block, and for every Question/acceptedAnswer pair, confirm the question text and the answer text both appear somewhere in the visible page — not paraphrased, not "close enough," actually present as text a reader would see.

That's tedious by hand past a handful of pages, so we added it to our free page audit tool: it now checks every FAQ/Q&A schema block on a page against the page's own visible text and flags any pair that doesn't actually appear. It's the same substring check described above, just automated, and it's free to run on any URL — yours or anyone else's.

The fix, once you find one

There's only one correct direction: make the schema match the page, not the other way around. If the answer in your schema is better than what's on the page, move that improvement into the visible copy and keep the schema in sync. Don't write FAQ schema that's aspirational, and don't leave it unattended after a content edit — treat it as part of the content, reviewed on the same cycle, not a one-time technical setup you forget about.