Repeat the same JSON-LD structured data checker result every time by pasting the exact same HTML into the same local extraction pipeline, because parsing happens in a detached browser template without fetching, executing, or re-rendering the page. Determinism in extraction is not a magical guarantee — it is a contract between what you supply and what the tool is allowed to do with it. A checker that never touches the network, never runs the pasted JavaScript, and never rewrites your input will produce an identical inventory of JSON-LD blocks and Microdata items on every run, as long as the bytes you paste are identical. The moment the source changes — for example, switching from the raw HTML response to a post-script rendered DOM, or re-saving the file with a different encoding — the extracted inventory can legitimately differ even though the underlying page looks the same in a browser. Treating repeatability as an input problem, not a tool problem, is the fastest way to make your checker runs comparable.
What Controls Whether a Run Repeats
Local extraction in the Structured Data Checker & Extractor is deterministic because four boundaries are fixed. First, the checker never requests a URL, so the source cannot change under network caching or a server-side experiment. Second, it never executes the pasted JavaScript, so client-side injected markup cannot appear or disappear between runs. Third, it builds a detached template fragment so the parsed nodes live outside the live page, which means no extensions, no third-party scripts, and no analytics tags can rewrite what you are inspecting. Fourth, input size and item counts are bounded, so an accidental full-site paste cannot freeze the parser or change which items it gets to.
Inside those boundaries, the parser still applies two visible layers that shape the result: the structural expansion of JSON-LD containers (single objects, top-level arrays, and @graph blocks each become their own rows) and the property profile for the supported types. A malformed JSON-LD script is reported separately, so one broken block never erases valid items found elsewhere in the same document. Microdata is walked as a bounded tree, and nested items remain visibly nested instead of being flattened into unrelated strings. None of these behaviours shift between consecutive runs unless you change the input or the profile version — which is the practical definition of a repeatable check.
Raw HTML vs Rendered DOM — Which Input Repeats
The most common reason two "same page" runs do not match is that the bytes pasted were not the same bytes. Three practical inputs exist, and each has a different repeatability profile.
| Input source | What it contains | Repeatability characteristic |
|---|---|---|
| Raw HTML response | The exact bytes the server sent, before any client-side script ran. | Most stable. Reflects the deployed template and any server-rendered JSON-LD. |
| View-source copy | Browser-rendered text from the "View source" command. | Stable for static markup; does not include markup injected by hydration scripts. |
| Rendered DOM export | The DOM tree after JavaScript has executed and frameworks have hydrated. | Includes injected JSON-LD that only exists after hydration; can drift between runs if the page uses dynamic timestamps or session data. |
| DevTools "Copy outerHTML" | DOM snapshot with live values. | Least stable for repeatability — values such as dates, IDs and counters may differ between visits. |
If the goal is to compare two runs, paste the same row of this table into the checker each time. Switching rows is a legitimate reason for the output to change.
Repeat a JSON-LD Checker Extraction in the Same Tool
- Save the source you intend to paste as a plain text or HTML file with a fixed name, UTF-8 encoding without BOM, and consistent line endings; this gives you a byte-identical copy you can re-paste later.
- Open the Structured Data Checker & Extractor and paste the full file contents into the input area — do not paste a URL, because the checker does not fetch.
- Run extraction, then review the displayed items in three separate passes: JSON-LD parse errors first, declared types and properties second, focused missing-property warnings third.
- Save or screenshot the displayed inventory exactly as shown, including the warning text, item count and ordering — the displayed text is the only run record you can compare against.
- To re-run, paste the same saved file into the same tool and compare the new displayed inventory against the saved one; identical inputs inside the same detached parser should produce an identical inventory.
- If the second run differs, the most likely cause is that the file bytes changed — re-check encoding, trailing whitespace and any template fragments the framework may have re-rendered between the two saves.
Capture a Run So the Next Run Can Match It
Repeatability is impossible to prove after the fact unless you kept a faithful record of the original run. The minimum record is three artefacts: the exact source file you pasted, the displayed checker output, and the date plus profile version you ran against. Save the source as a file rather than re-copying from the browser later, because the browser can normalise whitespace and encoding in ways that change the bytes without changing what the eye sees. Save the output as a text or screenshot capture so that the warning wording and item order survive the next browser refresh.
For longer projects, attach a one-sentence note about the page state — template source, build commit, or staging URL — so that future runs can be matched to a specific revision. The verification workflow for extracted data treats the displayed output as evidence about a specific document, not a promise about search appearance, which is the right framing for any repeatability comparison.
When Two Runs Differ — What to Check
If the second run produced a different inventory, work through the change list below before concluding that the parser is non-deterministic.
- Byte changes: re-encoding, BOM markers, line-ending changes, trailing whitespace, or invisible characters added by an editor.
- Template edits: a developer changed the source between runs, even for an unrelated field that shares the JSON-LD object.
- Rendered vs raw input: the first run used view-source text, and the second run pasted a post-hydration DOM that includes a different JSON-LD block.
- Multiple types or @graph expansion: a single block can expand into several displayed items, and a small change in nesting can re-order the displayed rows without changing the count.
- Profile set change: the tool only applies profiles where the product has a documented rule set; if a new profile was added between runs, the warning column can change for the same input.
If none of these explains the difference, the input bytes themselves were not the same. Treating repeatability as a contract on the bytes, rather than a parser feature, is what makes the workflow survive real-world edits.
Beyond Local Repeatability — Confirming Eligibility
A repeatable local extraction tells you only that the pasted markup parses consistently and matches the documented profile rules. It does not tell you whether Google will treat the deployed page as eligible for a rich result. The two questions are deliberately separate: syntax validity and search eligibility depend on visible content, feature-specific policy, deployment, indexing, and Google's own decisions. Google's structured data introduction lists the formats it supports and recommends JSON-LD for many features, but it is the official Rich Results Test on the deployed URL, not a local checker, that confirms whether a particular type qualifies.
The right division of work is: paste authorised source into the local checker, confirm the inventory is repeatable, fix any parse errors and structural gaps, then validate the public URL with the official validator for the feature you target. Local repeatability is the pre-flight; eligibility is the take-off.