When a JSON-LD checker returns output that looks wrong, the fix almost always lives in the source HTML rather than in the extraction tool itself, because the Structured Data Checker & Extractor only reports what is already present in the pasted document and every misaligned item it surfaces points back to a specific line of markup. Readers frequently treat a surprising extracted value as a tool bug, when it is in fact a faithful reflection of a real problem: a parse error in one script block, a duplicate @type, a property the template never emits, or a Microdata item that uses the wrong attribute for its URL. Knowing which of those four categories a wrong-looking result belongs to is the difference between chasing a phantom and producing a clean extraction on the next paste.
Why Extractor Output Sometimes Looks Wrong
The structured data on a real page is generated by templates, plugins, themes, and content fields that were assembled at different times and that may disagree with one another. When that assembled HTML is pasted into the checker, the inventory you see is the combined result of every contributor. A "wrong" result is rarely a single defect; it is usually the visible symptom of one of a small set of structural problems that the checker surfaces by design. Once you recognize the category, the repair becomes mechanical.
Four root causes cover most wrong-looking output:
- A JSON-LD script block that fails to parse. A missing comma, an unclosed bracket, or a trailing comma in strict JSON mode will invalidate the entire script, not just the property near the typo.
- A template that emits duplicate items. Two JSON documents concatenated into one <script> tag, or a theme plus an app both writing the same Product object, produces two competing blocks that confuse downstream consumers.
- A declared type with a property the template never fills. The checker flags the missing field against a documented profile, but the warning is informational; the absence may be intentional, or it may indicate that the template needs a new field.
- Microdata items using the wrong attribute. A link's href is read from the href attribute, not from its text, so a Microdata URL may appear blank even when the page renders the right destination.
Diagnose What the Extractor Actually Saw
Before changing anything, separate what you expected from what the checker actually read. The Structured Data Checker & Extractor parses the pasted HTML inside a detached browser template fragment, never fetches or executes the source page, and reports parse errors, focused missing-property warnings, and informational observations in three separate sections. A wrong-looking result that mixes all three signals into one impression is usually a reading problem, not an extraction problem.
Two practical checks keep diagnosis grounded:
- Confirm you pasted the response the crawler receives. Browser "Inspect element" shows the DOM after JavaScript runs, which may differ from the raw HTML delivered to a search bot. If a framework injects markup after load, compare the original response, the rendered DOM, and the crawler-visible output before drawing conclusions.
- Read each extracted item, not just the count. The checker expands @graph nodes, top-level arrays, and nested Microdata into individually visible items while preserving declared @type values, so a count of "three items" should correspond to three separately reviewable blocks.
Fix a JSON-LD Checker Result That Looks Wrong
This is the core repair workflow. Each step is taken in order, and each one changes what the next step can confirm.
- Paste the delivered HTML source or a controlled rendered-DOM export into the Structured Data Checker & Extractor. Do not paste from a live browser tab whose JavaScript has rewritten the markup, because the checker never fetches or executes the page and works only with what you give it.
- Run extraction, then open the JSON-LD parse errors section first. A malformed JSON block is reported separately so one broken script does not erase valid items found elsewhere in the same document, but the broken block still needs to be fixed before any other warning is meaningful.
- Review each Microdata item, declared type, and property in the extracted inventory. Confirm that the intended type is present, that the template has not emitted duplicates, and that no required field is missing from a specific variant. Look for nested Microdata items that the checker kept nested rather than silently flattening.
- Read the focused missing-property warnings against the linked documentation for each supported profile. A warning means the local profile did not find a property; it does not prove that a search engine will reject the page, and a strange-looking "missing" entry may simply reflect a type outside the checker's documented rule set.
- Fix the source template that generated the markup, not the extracted output. The correction must land in the template, the plugin configuration, or the content field that emitted the wrong value.
- Re-extract after each template change. Paste the new HTML, confirm the parse errors are gone, and confirm that the property inventory now matches what the page renders to a visitor.
- Validate the deployed URL with the official tool for the search feature you target, such as Google's Rich Results Test for Google-targeted types, and inspect Search Console enhancement reports after recrawling to confirm the deployed response agrees with the local extraction.
JSON-LD Versus Microdata: Different Reasons the Result Looks Wrong
JSON-LD and Microdata fail in different ways, so the diagnostic path depends on which syntax the page actually emits. JSON-LD lives inside <script type="application/ld+json"> tags and can contain one object, an array of objects, or an @graph containing several nodes. The checker expands those containers into individual items while preserving their declared @type values, so a JSON-LD "wrong" result usually traces to a syntax error, a container the template forgot to expand, or a property the JSON never contained.
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, recognizing values exposed through content attributes, links, media source attributes, date values, and text content. A Microdata "wrong" result usually traces to a missing itemscope on a parent element, an itemprop placed on a tag whose attribute the checker does not read (for example, a data- attribute when the page intends the href), or a nested item that the browser flattened visually but the parser kept nested.
If the page mixes both, treat them as separate inventories. A clean JSON-LD block does not rescue a broken Microdata block and vice versa.
Common Reasons the Output Looks Wrong
The table below maps the most frequent symptoms readers report to the structural cause and to the direction of the fix. It is qualitative; the precise property list for each type comes from the checker's profile and from the linked documentation, not from this article.
| What you see in the result | Likely structural cause | Direction of the fix |
|---|---|---|
| JSON-LD block listed as a parse error, other items still present | Trailing comma, missing bracket, or stray character in one script block | Repair the JSON in the source template; re-extract |
| Two Product or Article items where you expected one | Theme and app both emitting the same type into the same script | Remove one emitter or wrap both in an @graph |
| Type extracted but no property profile applied | Unfamiliar Schema.org type outside documented profile | Confirm the type is intentional; review against the search feature you target |
| Microdata URL shown as blank | itemprop placed on the wrong attribute or on a child element | Move itemprop to the element whose href or src should be read |
| Required property flagged as missing even though the field is filled | Template emits the value into the wrong property name | Rename the property in the template to match the documented name |
| Count of items differs from what you pasted | @graph or array containing multiple nodes | Verify each node is intentional; nested items remain nested in the inventory |
When the Fix Goes Beyond the Template
Sometimes a wrong-looking result is not a structural defect at all. The checker separates parse errors, focused property gaps, and informational observations precisely so this distinction is visible: valid JSON can describe inaccurate, hidden, or irrelevant content; a complete-looking object can still violate a search policy, disagree with the visible page, use an unsupported feature, or fail a deployment test. If the inventory is clean but the page still does not earn the rich result you expected, the problem is content or policy, not markup. Required-property guidance is not a substitute for content review, and adding fields merely to silence a warning can make the implementation less trustworthy. Fewer complete and truthful properties are preferable to a large object filled with generic or fabricated values.
After the Fix: Validate Against Official Tools
A clean local extraction is a preflight, not a verdict. Search engines decide whether and when enhanced presentation appears, and no local checker can guarantee indexing, ranking, or a rich result. Once the source template change is deployed, run the public URL through the official validator for the feature you actually target — Google's Rich Results Test for Google-targeted types — and inspect Search Console enhancement reports after recrawling to confirm that the deployed response agrees with the local extraction. If the deployed response differs from the pasted source, the deployed response is the one that matters, and the local extraction should be re-run against a fresh paste of that deployed HTML before drawing further conclusions.
For a deeper look, see How to Get Started With a JSON-LD Structured Data Checker.
For a deeper look, see Verify Your JSON-LD Checker Extracted Data Correctly.