Three mistakes account for most failed JSON-LD checker extractions: pasting the wrong HTML source, treating a clean extract as a rich-result guarantee, and reading parse errors and missing-property warnings as a single signal. A paste-based checker such as the Structured Data Checker & Extractor only inspects what you hand it, so the input you choose is the entire foundation of the result. If the markup is generated client-side, the crawler never sees what the browser sees, and if you ship one template but check a different variant, the extraction describes a page Google does not index. Parse errors, Microdata blanks, and missing-property warnings belong to three separate evidence categories; fixing them in the wrong order is the second classic mistake. The third is treating a clean extraction as proof of eligibility. A JSON-LD object can parse perfectly, declare the right type, expose every property a feature wants, and still be disqualified for visible-content mismatch, hidden markup, or unsupported feature usage. Reading the extract on its own terms, against the policy and the template, is what turns the tool from a green checkmark into actual insight.
Where Extraction Goes Wrong Before You Paste
The first extraction mistakes happen before the tool ever runs. A paste-based checker inspects only what you hand it, so the choice of input is the entire foundation of the result. Three input-side problems show up repeatedly.
The most common is pasting rendered DOM instead of the delivered HTML response. Many templates inject JSON-LD or Microdata through a framework that runs after the initial HTML loads. The browser sees the injected markup; the crawler may not. If you paste what your browser shows, you audit a page the search engine never receives. The opposite is also a mistake. If your page renders markup client-side and you paste the empty delivered HTML, the extraction shows no items and you chase a phantom problem in the template.
The second input-side mistake is pasting from a different template variant than the one you ship. A category page, a tag archive, and a single record can share a layout but emit different structured data. Checking one variant and deploying another is a silent source of "works locally, fails in production" behavior.
The third is partial or oversized pastes. Truncating a template before the closing JSON-LD script erases valid items. Pasting a full-site dump can hit the tool's input-size guardrail and freeze the page. Both produce results that describe a document Google never sees.
To avoid these, paste the delivered HTML response for the exact URL you ship. When a framework injects markup after load, compare the original response, the rendered DOM, and the crawler-visible output before drawing conclusions.
Three Evidence Categories That Get Read as One
A second cluster of mistakes comes from treating the checker's output as one signal. The output actually splits into three evidence categories, and conflating them produces bad fixes.
| Evidence Category | What It Means | What to Do First |
|---|---|---|
| Parse error | A JSON-LD script failed to parse; other items in the same document may still extract. | Locate the malformed script, repair JSON, re-extract. |
| Missing property warning | A supported profile did not find a property the consumer documents as required or recommended. | Compare against the linked profile evidence before adding a value. |
| Informational observation | Behavior outside the tool's product boundary (for example RDFa, or an unknown type). | Treat as outside scope; do not invent rules to silence. |
Parse errors are common because JSON-LD is unforgiving. A trailing comma, mismatched braces, or a single unescaped quote inside a string breaks the whole script. The tool reports the malformed block separately so a broken script does not erase valid items found elsewhere in the same document. Skipping past that line and chasing property warnings is a fix-order mistake; repair the parse error first, then re-extract.
Missing property warnings are narrower than they look. Schema.org defines a broad vocabulary, while search products publish required and recommended properties for particular experiences. The checker applies explicit profiles only where it has a documented rule set. An unknown type is still extracted but is not assigned invented requirements. Treating a warning as proof that Google will reject the page reverses the actual relationship: a warning means the local profile did not find a property, not that a search engine will refuse the markup.
Informational observations cover cases the tool declines to grade. RDFa is one example; the tool extracts JSON-LD and Microdata only, and RDFa is outside the product boundary, never counted as absent or invalid structured data. Adding a JSON-LD block "to replace" an RDFa attribute silently duplicates the same fact and confuses the audit.
How to Use a JSON-LD Checker on Pasted HTML
A paste-based workflow works best when each step isolates a different question. The Structured Data Checker & Extractor runs in this order.
- Paste the delivered HTML source, or a controlled rendered-DOM export when a framework hydrates after load.
- Run extraction. All parsing happens inside a detached browser template fragment, so the source is not fetched, executed, or sent to Lizely.
- Review JSON-LD parse errors separately from the rest of the inventory. A malformed block does not erase valid items found in other scripts or in Microdata.
- Walk JSON-LD items and Microdata items separately. JSON-LD can contain one object, an array, or an @graph with several nodes; the tool expands those containers while preserving declared @type values. Microdata uses itemscope, itemtype, and itemprop on ordinary HTML, and nested items remain nested instead of being flattened into unrelated strings.
- Cross-check missing-property warnings against the linked profile evidence. Treat an unknown type as extracted, not as graded.
- Fix the source template, redeploy, then validate the deployed URL with the official tool for the search feature you actually target (Google's Rich Results Test for a Google feature, plus Search Console enhancement reports after recrawling).
This order keeps each step falsifiable. The paste answers "what does the source look like." The extract answers "what structured data is present." The warnings answer "what the local profile expects." The deployed URL validation answers "what the search engine actually receives." Mixing those questions is how the audit loses track of which layer is wrong.
Why a Clean Extract Does Not Guarantee a Rich Result
The single highest-impact mistake in any JSON-LD checker workflow is reading a green result as a rich-result guarantee. The tool reports facts about the pasted markup. Eligibility for a rich result is a separate question that depends on at least four layers the checker cannot inspect.
| Layer Outside the Checker | What Can Still Go Wrong | How to Catch It |
|---|---|---|
| Visible content | Markup represents content hidden by CSS, behind a closed tab, or rendered after user interaction. | Open the deployed page in a clean browser and compare the rendered content with the extracted properties. |
| Feature-specific policy | The type is correct but the feature is restricted by region, content category, or publisher status. | Read the feature's documentation before relying on a clean warning list. |
| Deployment | A build step, proxy, or CSP strips the script tag or rewrites the response. | Validate the deployed URL with the official tool, not the source template. |
| Indexing | The page was not recrawled, was demoted, or was excluded by a robots rule. | Inspect Search Console enhancement reports after a recrawl request. |
The honest read is: parse validity, then visible content, then feature policy, then deployment, then indexing, in that order. Treating the extract as the final word is the most expensive version of this mistake because it hides the next layer behind a green light.
Fixing the Template Beats Adding Fields to Silence Warnings
The last cluster of mistakes shows up after the extraction looks "almost right." The temptation is to add missing properties until the warning list shrinks. That fix often makes the implementation less trustworthy.
Required-property guidance is not a substitute for content review. A warning that the tool cannot find an author is a hint that the template does not emit an author, not a hint to invent one. A warning that the price is missing is a hint to either expose the price on the visible page or omit the property entirely. Adding a generic value, a placeholder, or a value that disagrees with the visible page creates a mismatch the search engine can spot independently.
Fewer complete and truthful properties are preferable to a large object filled with generic or fabricated values. Schema.org is a vocabulary, not a promise; search engines grade the page on what the values actually say. A Recipe with three truthful properties and no rating will outperform a Recipe with eight properties, four of which describe content that does not exist on the page.
This is also where the source-template fix matters. The checker inspects pasted HTML; it does not patch it. The actionable artifact is the template, not the warning list. Open the template that emits the JSON-LD block (or the Microdata attributes), correct the conditional that drops the property, regenerate the delivered HTML, re-extract, and only then move to the official validator for the public URL.
For a closer walkthrough of how parse errors and Microdata blanks are presented side by side, the extraction-problems guide covers the same tool from a troubleshooting angle. For the underlying introduction to what each format actually is, Google's structured-data introduction describes the formats search engines support, and the WHATWG HTML Microdata spec defines the attribute behavior the checker walks.
If you're weighing options, Canonical Tag Generator: Avoid These Input Mistakes covers this in detail.