A JSON-LD checker extraction fails most often when the source HTML is not what the crawler receives, when one malformed JSON block erases a reader's view of valid items around it, or when a profile assigns "missing" to a property that no documented rule set actually requires.
A JSON-LD checker extraction is built around one specific contract: it inspects the markup you paste into it and reports what is actually there. Most of what goes wrong shows up at the boundary between that contract and the assumptions people bring to it. The most common failure modes are: the source you paste isn't the source the crawler sees; one malformed script block silently erases your view of valid items in the same document; the "required properties" warning actually belongs to a profile that has no documented rule for your type; or the extraction is clean and you still assume that means a rich result is coming. Each of those is a category mistake, not a parser bug. The extraction step in a tool like the Structured Data Checker & Extractor is deliberately narrow: find every JSON-LD script block and every Microdata item that exists in the pasted document, expand @graph and array containers, and preserve declared @type values and visible properties. Anything outside that narrow job — fetching the live page, scoring eligibility, simulating search engines — is not part of the extraction result at all, and treating it as part of the result is the single biggest way people mislead themselves with JSON-LD checker output.
Where Extraction Actually Breaks
The boundary between the contract and the reader's assumption is where most failures cluster, and they fall into four recognizable categories. The first is the input itself: the checker looks at what you hand it, and you assemble that input. The second is parser isolation: a malformed JSON block can hide valid items in the same document from a less careful tool. The third is the profile gap: warnings that look authoritative for types the tool has no documented rules about. The fourth is the inference leap: a clean extraction becoming a synonym for eligibility. Each of these is a category mistake in how the result is read, not a flaw in the parser that produced it.
Why Pasted HTML Is Not the Same as a Live Page
Modern frameworks inject structured data after the initial HTML response, edit the DOM in the browser, or rely on JavaScript to render the JSON-LD block in the first place. If you copy the raw server response, the script tag may not be there yet. If you copy a fully rendered DOM through dev tools, you may capture markup that a text-based crawler never executes, or include client-only hydration that simply is not in the served document. The two outputs can disagree, and the extraction can only see whichever one you paste.
That is why a serious extraction workflow compares the original response, the rendered DOM and the actual crawler-visible output before drawing any conclusion. When those three inputs diverge, extraction cannot settle the question; only deployment and an official validator run against the deployed URL can. Pasting one of them and treating the extraction as the final word is a reliable way to convince yourself the markup is correct when the live page is something else entirely.
What a Profile Warning Does and Does Not Mean
Schema.org defines a broad vocabulary, but a search engine's required-property list for a specific feature is a much narrower set. A well-built checker reports warnings only where it has a documented rule set for the type; for any other type it extracts the object and leaves the validation question open. That split is on purpose. Inventing requirements for a type the tool doesn't truly know would generate warnings that look authoritative but mean nothing, and that is a more dangerous failure mode than silence.
A warning in this context means one thing only: a property the local profile expected for this @type was not found in the pasted object. It does not mean the search engine will reject the page, and the absence of a warning does not mean the page is eligible. The table below separates what each layer actually answers from the question people usually ask it.
| Layer of the report | What it actually tells you | What it cannot tell you |
|---|---|---|
| Extraction | Every JSON-LD object, @graph node, and Microdata item that exists in the pasted source. | Whether the live crawler sees the same source. |
| Profile warning | A property the local rule set expects for this type was not found in the pasted source. | Whether a search engine will reject, ignore, or surface the page. |
| No warning shown | The local profile found each expected property in the pasted source. | That any specific rich result, knowledge panel, or enhancement will appear. |
| Malformed JSON block | A specific script failed to parse according to JSON syntax rules. | Why it failed and whether the surrounding page is otherwise intact. |
For Microdata specifically, the values come from attributes on real HTML elements: itemscope, itemtype and itemprop define scope, declared type and property names, and the values are read from content attributes, links, media source attributes, date values and text content. The WHATWG Microdata specification describes how those attributes are intended to be consumed, and any extraction that disagrees with that model is extracting the wrong thing. Nested Microdata items stay visibly nested; a flat string of unrelated properties is a sign something has gone wrong inside the extraction step, not in the source.
How to Run Extraction Without Misleading Yourself
The narrowness of the extraction contract is a feature, not a limitation. Used deliberately, a tool like the Structured Data Checker & Extractor becomes a preflight check that protects you from assuming what hasn't been tested. The steps below treat it that way.
- Paste the delivered HTML source or a controlled rendered-DOM export. The checker never fetches or executes the page, and any script inside the pasted document does not run; this is why the boundary between what you paste and what crawlers see stays yours to manage.
- Run extraction and review three outputs separately: JSON-LD parse errors, Microdata items, and the focused missing-property warnings. A malformed JSON block is reported on its own so one broken script does not erase valid items found elsewhere in the same document.
- For each extracted item, confirm the declared @type and the visible properties match what you actually intend the page to describe. Nested items should remain visibly nested rather than flattening into unrelated strings.
- Read each profile warning against the linked documentation. A warning means the local profile did not find the property; it does not prove that any consumer will reject the page, and absence of a warning does not prove eligibility.
- Fix the source template, redeploy, then validate the deployed URL with the official tool for the search feature you actually target. A local extraction is evidence about the pasted document, not a promise about search appearance, so the official validator is the only test that closes the loop on the live page.
If extraction surfaces a problem the official validator doesn't reproduce, the disagreement usually traces back to those three HTML inputs diverging. Documenting that mismatch before further edits, as described in our walkthrough of JSON-LD checker steps for structured data, keeps the debugging anchored to facts instead of guesswork.
After Extraction, the Real Decisions Begin
A clean extraction result is the smallest possible win: it means the pasted markup parses, every script block and Microdata item has been accounted for, and the local profile — where it exists — has not found a gap. None of that is a ranking signal, an indexing promise, or evidence that the markup describes content a user can see on the page. If the markup is technically valid but inaccurate, hidden, irrelevant or fabricated, a clean extraction will still show "clean," because validity and usefulness are different questions.
That is why the right next move after extraction is never "ship it." It is to confirm the markup reflects visible page content with specific, accurate values; fewer complete and truthful properties are preferable to a large object filled with generic filler. After that, validators tied to the search feature you target — the official validator for a Google feature, plus Search Console enhancement reports after recrawl — decide whether anything actually surfaces. RDFa, if your template uses it, is outside the current extraction boundary of this tool and is never counted as absent or invalid structured data by it; if you depend on RDFa, the local extraction will not protect that work and you will need a different checker for that path. Finally, remember that input size and item counts are bounded by design so an accidental full-site dump cannot freeze the page, and the checker does not follow links, load images, submit forms or evaluate embedded JavaScript — all of those limits are part of the same contract that makes the extraction deterministic in the first place.
For a deeper look, see JSON-LD Checker Extraction: Details That Matter.