Your FAQ Schema Says Something Your Page Doesn't. Ours Did Too.

Last week we ran a full content audit on our agency site: 64 pages, fetched live, scored for the patterns that make writing look machine-generated. Most of the site came back cleaner than we expected. Then a smaller, duller problem turned up, the kind that never shows in a visual check.

On our logo design page, one FAQ answer on the page itself ended with an extra sentence, a pointer to a related guide. The same answer inside the page's FAQPage schema did not have that sentence. The visible text and the structured data had drifted apart, probably during an earlier edit that updated one and not the other.

Google is explicit about this: structured data should describe what is actually on the page. A mismatch is not a dramatic penalty trigger, but it is exactly the sort of quiet inconsistency that erodes trust in your markup. And it is invisible unless you compare the two copies directly.

How we check for drift now

Our pages are hand-built static HTML, so the FAQ text lives twice in every file: once in the markup a visitor reads, once in a JSON-LD block. After this catch, we added a mechanical check to our editing routine:

1. Extract every application/ld+json block and parse it with a real JSON parser. String counting ("the file contains 8 questions") proves nothing. Parsing proves the block is valid.
2. For FAQPage blocks, pull each question and answer out of the parsed JSON.
3. Extract the visible FAQ text from the HTML.
4. Diff the two sets. Any pair that is not character-for-character equal gets fixed before the file ships, and the same check runs again on the live page after upload.

That last step matters. Edits are uploaded over SFTP here, and an interrupted transfer can leave a file in a state nobody intended. The live page is the only copy that counts, so the live page is what gets verified.

The same audit, wider

The drift check came out of a bigger pass. We scored every page for generic filler phrasing, repetition across pages, specificity (real numbers, prices, dates) and punctuation density. Two findings from that pass are worth stealing:

• Filler was rare, templating was structural. Only 19 boilerplate phrases across 64 pages, but whole FAQ and policy blocks repeated across dozens of pages. Repetition at the block level is a bigger tell than any single word.
• Punctuation density is a real signal. Our blog posts ran 12 to 20 em-dashes per thousand words, roughly double what the same writers produce naturally. We thinned them page by page, protecting headings, lists and schema text, and read every change before it shipped. Density now sits around 7 to 9 per thousand.

We wrote up the indexing side of this programme separately, in why your website is not showing on Google and what to check first. The short version: most "SEO problems" on a small site are not mysteries. They are small, checkable inconsistencies, and they accumulate quietly until someone builds the check that catches them.

Build the check. Run it on the live page. Fix what it finds the same day.