Troubleshooting a JSON-LD checker extraction problem means isolating the failure layer — JSON-LD parse, Microdata walk, or profile warning — before changing any template. Most extraction complaints fall into a small set of patterns: a valid-looking JSON-LD block that the parser still rejects, a Microdata item that never appears in the output, an unfamiliar Schema.org type that shows up without any required-property feedback, or a warning that looks authoritative but does not predict Google behavior. The Structured Data Checker & Extractor separates those layers so each problem can be matched to a different first question. Parse errors point at the script block itself. Microdata gaps point at the HTML tree and attribute placement. Profile warnings point at the consumer's documentation, not at the markup's syntactic validity. A clean local result is evidence about the pasted document — not a promise about search appearance — and a failing local result is evidence about pasted markup, which may still differ from the live page that a crawler receives.
Common Symptoms That Look Like Checker Problems
Before reaching for a fix, it helps to name the symptom precisely. The same complaint — "the checker is broken" — usually hides one of four recognisable failure shapes, and each shape belongs to a different layer of the extraction pipeline.
The first shape is a parse error reported inside an otherwise reasonable JSON-LD block, often caused by a trailing comma, an unquoted key, or a single stray character at the end of the script. The second shape is a missing item: the page clearly contains a JSON-LD script or Microdata attributes, but extraction returns nothing for that block. The third shape is an empty or blank property value on an item that did appear, which usually means the wrong attribute was used (for example, an href value sitting on a non-link element). The fourth shape is a warning that the checker flags as "missing required property" for a type you believe is fully populated.
| Symptom you see | Likely failure layer | First check |
|---|---|---|
| "Parse error" on a JSON-LD block you think is valid | JSON-LD parse | Re-run extraction; paste the script alone to isolate |
| Zero items extracted from a page you marked up | Microdata walk or script placement | Confirm itemscope or itemtype, or the script's location in the document |
| Item appears but listed properties are blank | Microdata attribute mapping | Check itemprop spelling and parent scope |
| Warning about a missing "required" property | Profile rule, not syntax | Confirm the type against the feature's documentation |
| Local checker and live page disagree | Input mismatch | Compare pasted HTML against crawler-visible output |
Recognising which row describes your symptom determines the next move. If the symptom lives in row one, the fix is in the script text. If it lives in row two or three, the fix is in the HTML tree. If it lives in row four, the fix is in the consumer's documentation, not in your markup.
Troubleshoot a JSON-LD Checker Extraction Problem
A short diagnostic flow keeps the work bounded. Each step answers a single question, and the answers narrow the search until the cause is obvious.
- Confirm what you pasted. The checker works on the HTML or controlled DOM export you provide, not on a live URL. If a framework injects markup after load, the rendered DOM may differ from the original server response. Decide which version you intend to audit before reading any result.
- Separate parse errors from extraction results. A malformed JSON-LD block is reported on its own, so one broken script does not erase valid items found elsewhere. Note every parse error and every successfully extracted item separately before deciding what to fix.
- For each missing item, ask whether it lives in JSON-LD or Microdata. JSON-LD items go missing because the script failed to parse or was never present in the pasted document. Microdata items go missing because the walker never reached the elements, usually because of an itemscope or itemtype typo, or because the markup sits outside the pasted fragment.
- For each blank property, ask which attribute was expected. Microdata exposes values through content attributes, links, media sources, date values, or text content. If the wrong attribute carries the value, the property will read empty in the extracted view.
- For each profile warning, ask which consumer it applies to. The checker applies explicit, documented profiles only. A warning means the local profile did not find the property in the pasted markup; it does not prove that a search engine will reject the page.
- Fix the template, then re-run. Edit the source template, not a one-off page. Re-extract until parse errors are gone, every intended item appears, and warnings are either resolved or understood.
JSON-LD Parse Errors and What They Actually Mean
A parse error message points at a position inside the script. Reading it as "the JSON is wrong at character N" is more useful than reading it as "the checker is broken." Common patterns repeat across templates, and each pattern has a typical cause.
| Pattern | Typical cause | Where to look |
|---|---|---|
| Unexpected token | Trailing comma, unquoted key, or stray character | The last property before the error position |
| Unterminated string | Missing closing quote inside a value | Long URLs or descriptions copied from a CMS |
| Unexpected end of JSON | Missing closing brace or bracket | Overall brace and bracket balance |
| Invalid escape | Bad backslash sequence in a value | URLs and rich-text descriptions |
JSON-LD can carry one object, an array of objects, or an @graph containing several nodes. The checker expands those containers into individual items while preserving each declared @type and visible property, so the shape of the script does not by itself cause extraction to fail. A malformed block, however, is reported separately and never silently merged with valid neighbours.
When a script returns no items despite looking correct, the most common cause is that the script was loaded by a framework after page load and was not present in the pasted fragment. The next most common cause is a value pair that the surrounding HTML engine stripped during minification. The fix in both cases is to compare the original server response, the rendered DOM, and the crawler-visible output, then paste the version that contains the markup you intend to audit.
Microdata Items That Disappear or Show Empty Values
Microdata uses itemscope, itemtype, and itemprop attributes inside ordinary HTML. The checker walks the parsed document and builds a bounded property view for top-level items, which means missing items usually come from a broken scope, not from a broken parser.
The first thing to confirm is that itemscope is on the element you think it is. A typo on the attribute (itemscopee, item-scope, itemscope="false") silently turns the element into an ordinary tag. The second thing to confirm is that itemtype points to a valid Schema.org URL; an unreachable or misspelt type does not stop extraction, but it does mean the resulting item will not match any documented profile. The third thing to confirm is that nested items remain visibly nested: a child itemprop that lives inside a child itemscope should not be flattened into the parent's property list.
Empty values usually mean the wrong attribute carried the data. A product URL placed in a data-* attribute, an image URL placed in alt text, or a date placed in a span without a machine-readable attribute will all read as blank in the extracted view. Confirming which attribute exposes the value, then aligning itemprop with that attribute, is the standard fix. For more on how to interpret the extracted property list once these fixes are in, see how to read JSON-LD checker results after extraction.
When the Local Checker Looks Clean but Something Is Still Wrong
A clean local result is a statement about the pasted document, not about the page. Three mismatches commonly explain "the checker says fine, but the live page still does not behave the way I expect."
The first mismatch is between server response and rendered DOM. A static HTML file pasted directly may contain the JSON-LD; a single-page application rendered in a browser may not, because the markup is injected after load. The second mismatch is between the browser and the crawler. Cloudflare challenges, geo-targeted redirects, IP-aware variants, and language selectors can all change the response a crawler receives. The third mismatch is between the consumer's profile and the page's actual content. The checker applies explicit, inspectable profiles only where a documented rule set exists; an unknown type is still extracted, but it is not assigned invented requirements.
The practical conclusion is that a clean local run earns you the right to run the official test on the deployed URL. It does not, by itself, replace that step. For Google's rich-result features, the official structured data guidance describes which formats and properties each feature accepts; the WHATWG HTML Microdata specification defines how Microdata attributes are interpreted by parsers.
After Troubleshooting: Validate the Deployed URL
Once the local checker reports the markup you expected — parse errors resolved, intended items present, warnings understood — the next step is to validate the deployed URL with the official tool for the search feature you actually target. Google's Rich Results Test is appropriate when the type targets a Google feature. For features outside that scope, the relevant consumer's own validator or documentation is the appropriate reference.
After a change reaches production, Search Console enhancement reports, recrawl requests, and representative template tests confirm behaviour over time. Search engines decide whether and when enhanced presentation appears, so no local checker can guarantee indexing, ranking, or a rich result. The local checker's job is narrower and more useful than that: it tells you, with evidence about the pasted document, whether the markup is internally consistent and matches the profile you are trying to satisfy.