Structured Data Drift Check vs. checking it by eye

Q: What does checking JSON-LD against the page by eye actually catch?

It catches the case everyone tests: view-source, find the application/ld+json block, read one short FAQ answer, glance at the matching paragraph on the page, and see they say the same thing. That works fine for a single short claim someone is already looking straight at.

Q: Why does eyeballing miss a nested node?

Real JSON-LD nests: a Review sits inside a Product's review field, an Organization sits inside an Article's publisher field, and an @graph array can hold several unrelated top-level nodes in one script block. Finding every checkable claim means mentally walking that structure without missing a level, for however many script tags the page carries — and a person scanning for the FAQPage block they know is there has no particular reason to also open the Product node three lines below it.

Q: Why is a long claim harder to check by eye than a short one?

A HowTo step or an Article description can run to several sentences. Comparing two paragraph-length strings word for word by eye, across the gap between a minified JSON string and a rendered paragraph with different line wrapping, is exactly the kind of exhaustive comparison people are bad at doing reliably — and unlike a one-line FAQ answer, a single dropped clause in the middle of a long paragraph produces no visual cue that anything is missing.

This page names no specific product or company: "checking it by eye" is view-source plus reading, a generic manual habit anyone with a browser already has, not a competing tool.

Reading a page's <script type="application/ld+json"> block and comparing it by eye against the rendered page genuinely works for the case most people picture when they think about checking this: one short FAQ answer, one matching paragraph, both in view at the same time. That case is real, and it is not what this tool exists to replace. What it replaces is everything past that case — escaped punctuation that reads as ordinary text, a node nested inside another node, more than one <script> block on the page, and a claim long enough that a dropped clause in the middle produces no visual cue at all.

Case	Checking it by eye	This tool
One short FAQ answer next to its matching paragraph, both in view together	Works fine — this is the case the habit is built for	Also passes, the same way, as one of six checked claim types
A JSON-escaped straight quote (`\"`) vs. a curly one rendered on the page	Both read as an ordinary quote mark scanning past a long raw-text line — no visual difference to notice	Squashes and compares the decoded text directly, so a quote-style mismatch shows up as an exact divergence, not a guess
An em dash written as a plain double hyphen in the JSON-LD, or an HTML entity like `—`	Reads as unremarkable ASCII in the raw source either way	Decodes named and numeric entities before comparing, so the two only match when the actual characters agree
A `Review` nested inside a `Product`, or an `Organization` nested inside an `Article`'s `publisher` field	Only found if the person scanning the script block happens to open that nested object too, past whichever top-level type they were looking for	Walks every reachable node in every script block, including `@graph` arrays and nested fields, so a claim three levels deep is checked the same as a top-level one
A paragraph-length `HowTo` step or `Article` description	A manual word-for-word comparison across a line-wrap difference — exactly the kind of exhaustive check people get wrong under time pressure, with no signal when they do	A deterministic string comparison with no length limit, reporting the exact character where the two diverge
More than one `<script type="application/ld+json">` block on the page	Easy to check the one you already scrolled to and skip the others	Parses every JSON-LD script block on the page in one pass
Catching drift a future edit introduces	A one-time read answers for today; nothing re-checks the page after the next copy edit	`cli.mjs` reads local files with no network call and can run as a CI gate on every build

The gap that matters most: escaped text looks identical to decoded text

View-source shows the JSON-LD exactly as authored: a right single quote can be the six literal characters ’ or the escape sequence ’, and an em dash can be typed as two hyphens because it was faster to type than the real character. None of that looks unusual sitting inside a long minified string — there is no red flag, no obviously-wrong shape, just ordinary-looking text. The page's rendered copy, meanwhile, shows the decoded, real character. Two strings that differ by exactly one of these substitutions read as the same thing to someone scanning past them, and stay that way indefinitely, because nothing about a clean-looking read tells you whether you checked the actual characters or the ones your eye auto-corrected on the way past. This tool's decodeEntities step resolves both named and numeric character references before comparing, so a punctuation substitution shows up as a real divergence rather than passing on sight.

The gap that matters second: nesting has no visual marker

Schema.org nodes nest freely — a Review can live inside a Product's review field, an Organization can live inside an Article's publisher field, and a single script block can hold an @graph array of several unrelated top-level nodes. None of that changes how the raw text looks: it is still one long line of nested braces, and there is no highlighting to tell a person scanning it that a checkable claim sits three levels deeper than the type they came looking for. This tool walks every object reachable from every parsed script block — arrays, @graph, and every nested property — so a nested claim is checked the same way a top-level one is, with no dependence on whether a reader happened to open that branch.

When to still read the page yourself

This is a text comparison, not a content review. It has no opinion on whether the copy is accurate, well-written, or eligible for a rich result, and it checks only six schema.org types' textual fields — a claim outside FAQPage, HowTo, Article/BlogPosting/NewsArticle, Product, LocalBusiness/Organization, or Review is invisible to it the same way it would be to a person who never scrolled that far. Judging the substance of the content is still a job for reading it.

Common questions

What does checking JSON-LD against the page by eye actually catch?

It catches the case everyone tests: view-source, find the application/ld+json block, read one short FAQ answer, glance at the matching paragraph on the page, and see they say the same thing. That works fine for a single short claim someone is already looking straight at.

Why does eyeballing miss an entity or escape difference?

The JSON-LD in view-source is a raw, minified, escaped string: a curly right quote is the literal characters \u2019 or an HTML entity, an em dash can be a plain double hyphen, and a straight quote inside the JSON is backslash-escaped as \". None of those render as anything unusual when you read the raw source text — they look like ordinary characters mixed into a long line — so two strings that differ by exactly one of them read as identical to a person scanning past them, while a browser decoding the same page renders visibly different punctuation.

Why does eyeballing miss a nested node?

Real JSON-LD nests: a Review sits inside a Product's review field, an Organization sits inside an Article's publisher field, and an @graph array can hold several unrelated top-level nodes in one script block. Finding every checkable claim means mentally walking that structure without missing a level, for however many script tags the page carries — and a person scanning for the FAQPage block they know is there has no particular reason to also open the Product node three lines below it.

Why is a long claim harder to check by eye than a short one?

A HowTo step or an Article description can run to several sentences. Comparing two paragraph-length strings word for word by eye, across the gap between a minified JSON string and a rendered paragraph with different line wrapping, is exactly the kind of exhaustive comparison people are bad at doing reliably — and unlike a one-line FAQ answer, a single dropped clause in the middle of a long paragraph produces no visual cue that anything is missing.

Does this tool replace reading the page yourself?

No. It only compares text that is already on the page against text that is already in the page's own JSON-LD — it has no opinion on whether the copy is well-written, whether the JSON-LD is eligible for a rich result, or whether a claim outside its six checked types is accurate. Judging the content itself is still a job for reading it.