Why do two checker runs of the same page show different item counts?

The paste itself is the only variable, so the divergence comes from a different input. Confirm the same HTML source or controlled DOM export was pasted both times, that input-size limits were not hit, and that the page template did not change between runs.

Does a clean extract mean the page will earn a rich result?

No. The checker reports facts about the pasted markup; eligibility also depends on visible content, feature-specific policy, deployment, indexing, and Google's own decisions.

What does it mean when an unknown type is extracted without any warnings?

Extraction can be general, but required-property rules are consumer and feature specific. The tool avoids inventing a validation profile without a documented contract, so an unknown type appears in the items list with no focused warnings by design.

Why are nested Microdata items shown nested in the output?

Nested items are kept nested so a parent string does not silently absorb a child node. Flattening real Microdata into unrelated strings would mislead every later audit, so the checker preserves the tree.

Verify Your JSON-LD Checker Extracted Data Correctly

Correct extraction is the only verifiable part of a JSON-LD checker run — every warning, gap, and pass/fail decision downstream depends on the inventory being accurate. Three conditions decide whether an extract is correct: the input matches what a crawler actually receives, every JSON-LD container (single object, array, or @graph) is expanded into its own item with its declared @type preserved, and Microdata items are read from their itemprop and itemtype attributes instead of from visible text alone. A correct extract also separates malformed JSON blocks from the valid items in the same document and keeps nested Microdata items visibly nested. Whether you ship the JSON-LD straight or generate it from a template, the local checker can confirm those four behaviors on the pasted source. It cannot confirm whether Google's Rich Results Test, Search Console, or any other consumer will accept the deployed page, so the official validator still has to run after a fix.

how do i make sure i extract structured data checker correctly when using json ld checker — Verify Your JSON-LD Checker Extracted Data Correctly

Why correctness matters more than a clean score

A local JSON-LD checker works on what you paste, not on what gets indexed. Treating a green check or an empty warning list as proof that the page will earn a rich result overstates what the tool actually proves. The report is evidence about the pasted document, not a promise about search appearance. Treating the extract as the ground truth lets you use it for what it can do — catching template bugs, duplicate emissions, broken JSON, and blank property values — and stop at what it cannot do — predict indexing, ranking, or rich-result eligibility.

If the extractor silently flattens a nested Microdata item into an unrelated string, or hides a malformed JSON-LD block while still reporting the other items in the same document, every later decision is built on bad data. The correctness of the extract is the foundation of every warning or gap that follows. Every action after a run assumes the items list is faithful to the source you pasted.

Match the input to what a crawler sees

The checker's first correctness control is the paste itself. Three input shapes have different reliability profiles, and mixing them up is the most common reason a correct-looking extract disagrees with the deployed page.

Input source	What it contains	Risk
Source template (CMS, build output, raw HTML)	Authored JSON-LD and Microdata as written	Misses markup injected by JavaScript at runtime
Controlled rendered-DOM export	DOM after injection, before user interaction	Still missing async or event-driven markup
Live fetched response	What a crawler actually receives	Not produced locally; the checker does not fetch

For frameworks that inject markup after load, the safe approach is to compare the source response, the rendered DOM, and what a crawler-visible tool returns for the same URL. If those three diverge, the extract only audits one of them. Choosing the wrong shape makes the checker technically correct about the wrong input.

How to verify a JSON-LD checker extracts data correctly

Open the Structured Data Checker & Extractor in your browser. All parsing happens inside a detached browser template fragment — nothing is uploaded, no scripts in your HTML run.
Paste the same HTML the crawler receives. Prefer a controlled rendered-DOM export for client-rendered pages; the checker never fetches a URL on its own.
Run extraction and review the items in this order: JSON-LD parse errors, JSON-LD items, Microdata items, then focused missing-property warnings.
Confirm that JSON-LD containers are expanded. A single object should become one item; an array should become one item per element; an @graph should expand into individual nodes that each preserve their declared @type.
Check Microdata coverage. Each item should show its declared type via itemtype and its property values via itemprop, including values exposed through content attributes, links, media source attributes, date values, and text content.
Resolve parse errors before profile warnings. A malformed JSON-LD block is reported separately so it does not erase valid items, but it must still be repaired in the source template before shipping.
Cross-check by changing one property in your source, regenerating the paste, and confirming the same item now lists that property with the new value. If the extract is stable across that controlled change, the extraction path is correct.
Fix the source template, redeploy, then validate the public URL with Google's Rich Results Test for the search feature you actually target. A local extract cannot stand in for that final deployment step.

If an item count or property count drifts between two paste runs of the same source, the extract is not yet trustworthy. Repeat the run, paste fresh, or confirm no input was accidentally trimmed before drawing conclusions from the output.

Cross-checks that catch a wrong-looking extract

Five practical cross-checks turn a one-shot run into an honest correctness check. None of them require fetching the live page.

Duplicate item audit — the same @type appearing twice from one product template often signals a generator that runs per page and per block; deduplicate before judging property gaps.
Required-field spot check — open the source and pick a profile-required field; the extract should show a value or surface a focused warning. Silence on a required field is a red flag, not a green light.
Attribute-vs-text check — for Microdata, a blank URL where itemprop expects a link usually means the wrong attribute was used; the extract should expose the link target, not just the inner text.
Nested-item visibility — nested Microdata items should remain visibly nested; if a parent object's string value silently absorbed a child, the flat value is misleading.
Profile-limitation check — unknown types are extracted but not assigned invented requirements. If you see a non-supported type in the items list with no warning, that is by design, not a missing check.

Use these as documented controls, not generic suspicion. If a check fails, the issue lies in the source template or in the input shape, not in the extraction logic itself.

Parse errors and missing properties are not the same severity

Parse errors mean the JSON block cannot be read at all. Missing properties mean a block was read successfully but did not match a documented consumer profile. Correctness demands a strict ordering: parse errors first, profile warnings second, informational observations third.

Treating a missing-property warning as a parse error leads to fake fixes — adding fabricated values to silence the warning. The product contract is explicit that fewer complete and truthful properties are preferable to a large object filled with generic or fabricated values. A warning means the local profile did not find a property; it does not prove that a search engine will reject the page. Syntax validity and search eligibility are different questions, and the checker is built to keep them separated. For external grounding on what a search product considers required, see Google's introduction to structured data.

When the local extract is no longer a sufficient check

Three situations mean it is time to stop relying on the local result and move to the official validator.

The crawler-visible response differs from anything you can paste locally — for example, behind authentication, behind a private network, or generated by client-only logic that depends on runtime fetches the checker cannot replicate.
The product targets a feature-specific policy that the local profile does not encode — Google's documentation on spam policies, image requirements, or review-source rules apply at deployment time and not at paste time.
Search Console enhancement reports differ from the local extract — the deployed URL is the only test that can prove indexing state, not the extract itself.

For Microdata behaviour and attribute semantics outside the supported profiles, the WHATWG HTML Microdata specification describes what a valid node looks like; the local checker is not a substitute for that document when a type falls outside its documented contract.

A final correctness discipline

A trustworthy run has four parts: paste the right input, expand every JSON-LD container correctly, separate parse errors from property warnings, and confirm the deployed URL with the official tool before shipping. Anything less than that sequence produces a number, not a guarantee. Whether you are auditing one template, a hundred product pages, or a freshly built CMS, the discipline is the same. For readers whose extract looks wrong after all of this, see the fix a wrong-looking JSON-LD checker result walkthrough. For readers unsure whether the checker actually opens their page, see what a JSON-LD checker does with your page.