What "Choosing" Really Means With a JSON-LD Checker
Choosing the right approach to a structured data checker when you are already using a JSON-LD checker is a question of what you need the tool to reveal: the items actually embedded in your HTML, the types and properties each item declares, and the focused property gaps that prevent a search feature from recognizing the page. Extraction-first tools inspect a copy of your source inside the browser, expand every JSON-LD object, array and @graph node into individual items, walk bounded Microdata structures, and separate parse errors from profile warnings so one broken script cannot mask a valid one elsewhere in the document. The Structured Data Checker & Extractor follows that extraction-first contract: paste authorized HTML, review the inventory, then validate the deployed URL with the official tool for the search feature you target. Syntax validity and rich-result eligibility are different questions, so the checker reports evidence about the pasted document rather than predicting search appearance.
The phrase "right approach" usually hides three smaller decisions: which structured-data format the tool reads, whether the tool fetches your page or only parses what you paste, and whether the tool grades your markup against an explicit rule set or only inventories it. Each decision changes what the result can prove about your template and what it cannot.
The Three Real Approaches to Extraction
Most tools that bill themselves as JSON-LD checkers fall into one of three approaches, and the trade-off matters more than the marketing copy suggests.
JSON-LD-only checkers focus on the script blocks inside the document. They parse each script with standard browser JSON handling, expand @graph containers and arrays into a list of nodes, and report parse errors per block. They skip Microdata and RDFa entirely, which is fine if your template emits only JSON-LD but blind to the markup if your CMS also embeds Microdata on a different template. A pure JSON-LD focus matches Google's recommended format for many structured-data features, but it is not a complete audit of every format the document may contain.
Microdata-only checkers walk the parsed DOM looking for itemscope, itemtype and itemprop attributes. They read values from content attributes, links, media sources, date attributes and text nodes, and they keep nested items visibly nested rather than flattening them. They skip JSON-LD and RDFa, so a Microdata-only tool leaves any script-block markup uninspected.
Combined local extractors handle both formats in one pass. The Structured Data Checker & Extractor finds JSON-LD script blocks and Microdata items in the same document, expands JSON-LD containers into individual items, walks bounded top-level Microdata structures, and keeps the output separated by format. A malformed JSON block is reported separately, so one broken script does not erase valid items found elsewhere in the same document. RDFa remains outside the current product boundary; the limitation is shown rather than counted as absent structured data.
Comparing Extraction Approaches by Use Case
The right choice depends on what your template actually emits, not on which tool has the most recognizable brand. The table below summarizes the practical trade-offs.
| Approach | What it inspects | What it skips | Best fit |
|---|---|---|---|
| JSON-LD-only checker | Script blocks, @graph nodes, top-level arrays | Microdata, RDFa, in-page itemprop | Templates that emit only JSON-LD |
| Microdata-only checker | itemscope, itemtype, itemprop, nested scope | JSON-LD scripts, RDFa attributes | HTML-native templates without script blocks |
| Combined local extractor | Both formats, nested items, bounded counts | RDFa, live page fetch, script execution | Mixed templates and pre-flight reviews |
If your CMS or framework switches formats between templates (a Product page emitting JSON-LD, an Article page emitting Microdata, a legacy FAQ block emitting RDFa), only the combined approach audits the formats that exist; it cannot tell you about a format that does not exist in your paste.
Run a Structured Data Checker the Right Way
An extraction-first checker is most useful when you treat it as a structured preflight rather than a yes/no gate. The exact sequence below mirrors the verified operating steps for paste-based extraction.
- Copy the delivered HTML source for the page, or export a controlled rendered-DOM snapshot if a framework injects markup after load. The checker never fetches or executes the page, so what you paste is what gets parsed.
- Paste the HTML into the Structured Data Checker & Extractor. Parsing happens inside a detached browser template fragment, so no script from your document runs and no resource is requested.
- Run extraction, then read the result in this order: JSON-LD parse errors first, Microdata items next, declared types and properties third, and focused missing-property warnings last. Keeping those layers separate stops one malformed script from masking valid items elsewhere.
- Compare the extracted inventory against what the page should expose. Did the intended type appear? Did a template emit duplicate items? Is a required field missing from one variant only? Does a JSON-LD block fail to parse while Microdata covers the same entity?
- Fix the source template so the change is reproducible across records. Adding fields merely to silence a warning can make the implementation less trustworthy, so prefer fewer complete and truthful properties over a larger object filled with generic or fabricated values.
- Validate the deployed URL with the official tool tied to the specific search feature you target, then inspect the enhancement report in Search Console after recrawling.
Reading What the Checker Returns Without Overpromising
A result with no parse errors and no profile warnings is evidence that the pasted HTML contains the expected items with the expected properties, not a guarantee that a search engine will display a rich result. Syntax validity, content accuracy, deployment, indexing and consumer-specific policy are separate questions. Valid JSON can describe inaccurate, hidden or irrelevant content; a complete-looking object can still violate a search policy, disagree with the visible page, or fail a deployment test. Schema.org properties that are not part of a Google feature can still be meaningful to other consumers.
An unfamiliar Schema.org type may appear in the extracted list without being graded. Extraction is general, but required-property rules are consumer and feature specific, so the checker avoids inventing a validation profile without a documented contract. A warning therefore means the local profile did not find a property; it does not prove that a search engine will reject the page, and it does not block publishing. Treat the warnings as focused starting points for a manual review against the linked documentation rather than as a verdict.
The result also cannot promise that what you pasted matches what a crawler sees. If a framework injects markup after load, the original HTTP response, the rendered DOM and the crawler-visible output can differ. The pasted HTML is the source of truth for that one extraction; reconcile the differences before drawing conclusions about deployment.
After the Local Check: Validate the Deployed URL
A local paste-based checker is a transparent preflight, not the final word. The structured data on the page must still match the visible content, follow the consumer's content policy, and survive deployment. After the source template is fixed, run the official validator for the search feature you target — Google's Rich Results Test when the type targets a Google feature — against the deployed URL, not the local paste.
For Microdata specifically, the WHATWG HTML Microdata specification defines how itemscope, itemtype and itemprop combine; reading your extraction against that spec tells you whether a blank URL was caused by the wrong attribute, a missed content attribute, or a nested scope that was silently flattened. For JSON-LD, confirm the deployed script is delivered inside a non-JS-dependent path and that a framework is not stripping it server-side. After recrawling, inspect Search Console enhancement reports to see whether the consumer agrees with your local analysis.
Search engines decide whether and when enhanced presentation appears. No local checker can guarantee indexing, ranking or a rich result, so the right approach is one that gives you a transparent inventory of what your paste contains, a clean separation between parse errors and profile warnings, and a clear handoff to the official validator for the specific feature you target.