A JSON-LD checker that extracts structured data turns pasted HTML into a readable inventory of every JSON-LD script block and Microdata item already present in the document, with parse errors and missing-property warnings reported as separate categories. Extraction happens inside a detached browser template, so the deployed page is never fetched, executed, or transmitted to a third party. The output expands JSON-LD containers such as top-level objects, arrays, and @graph nodes into individual items, while preserving each item's declared @type and visible properties. Microdata is read by walking itemscope, itemtype, and itemprop attributes across the parsed DOM and keeping nested items visibly nested rather than silently flattened. What you get is an evidence report about the markup you pasted in, not a promise that the page will earn a rich result or be treated as eligible by any particular search engine.
What Extraction Actually Produces Inside a JSON-LD Checker
Most "JSON-LD checker" tools start with parsing, but the extraction phase is what makes the output useful for template debugging. A genuine extractor walks the document looking for two things: <script type="application/ld+json"> blocks and HTML elements carrying Microdata attributes. Everything it finds is normalized into a list of items, each one carrying its declared @type and the properties that are actually present in the source. Missing or blank values stay blank instead of being silently filled in, which is what lets you spot a template that is emitting the right field name with no useful value.
That inventory answers the questions you cannot answer by reading raw HTML in your editor. Did the template emit the JSON-LD block at all? Did it emit one block, several, or one with multiple nodes inside an @graph? Did the Microdata version of the same page carry a different URL because the wrong attribute was used for the link? Did a content field come out blank? These are extraction findings, not validation verdicts. The Structured Data Checker & Extractor is built around this distinction. Its first job is extraction. It finds both JSON-LD and Microdata, expands containers, surfaces parse errors separately from property warnings, and applies required-property profiles only where the tool has a documented rule set. Everything else is shown as an informational observation rather than a defect.
How JSON-LD Containers Are Expanded During Extraction
JSON-LD rarely ships as a single flat object. Three shapes are common in delivered HTML, and each has to be handled during extraction so that downstream property checks see real items rather than a string they have to guess about.
| Container shape | What it looks like in source | How the extractor treats it |
|---|---|---|
| Single object | One {"@context":..., "@type":"Recipe", ...} at the top level | Reported as one item with that @type and its properties |
| Top-level array | [{"@type":...}, {"@type":...}] at the top level | Each array entry reported as its own item with its own @type |
| @graph container | {"@graph":[{"@type":...},{"@type":...}]} | Each node inside the @graph reported as a separate item with its own @type |
Expanding these shapes during extraction matters because required-property checks need a real @type to look up. If an array is treated as one opaque blob, the tool cannot tell whether Recipe and FAQPage are both present or whether a missing field belongs to the wrong item. The same logic applies to a broken JSON block: when one script fails to parse, the malformed block is reported on its own so that valid items found elsewhere in the same document are not erased. That separation is part of what makes extraction useful for template debugging rather than just a final pass before deployment.
Reading Microdata Items Through itemscope and itemprop
Microdata lives in ordinary HTML rather than in a script tag. The extractor walks the parsed DOM for elements carrying itemscope and itemtype, then collects the values exposed through itemprop, content attributes, link href values, media source attributes, date values, and text content. Per the WHATWG HTML Microdata specification, each itemscope establishes a new item, and nested itemscopes form a tree rather than a flat list.
The Structured Data Checker & Extractor keeps that nesting visible. A Product item containing a nested Offer item does not collapse into a flat string of properties; the Offer remains nested so you can see exactly which URL, price, or availability value belongs to which scope. That is also why an item with a missing or blank value shows up as blank instead of being silently filled in: the extractor reports what the source actually contains, not what it might have meant. If the template is emitting the wrong attribute for a link, the inventory makes that visible immediately.
Extracting Structured Data With the Lizely Checker: A Practical Workflow
- Copy the delivered HTML source for the template you want to inspect. If a framework injects markup after the initial response, also export a controlled rendered-DOM snapshot so you can compare what the server sent against what a crawler would actually receive.
- Paste the HTML into the Structured Data Checker & Extractor. The tool never fetches the page, runs its scripts, or loads its resources, so this step stays inside your browser and does not transmit the source anywhere.
- Run extraction and separate the categories the tool returns: JSON-LD parse errors, Microdata items, declared types and properties, and focused missing-property warnings. Review each category on its own so a single broken block does not hide valid items elsewhere in the same document.
- For every JSON-LD item, confirm that the declared @type matches what the template was meant to emit and that each property carries a real value rather than a blank string. For every Microdata item, confirm that itemscope covers the visible element and that itemprop values actually resolve to text, links, or dates.
- Resolve parse errors first, since the rest of the inventory cannot be trusted until the JSON parses cleanly. Then review profile warnings against the linked documentation, and decide which ones reflect a real gap versus a property that is genuinely optional for your page.
- Edit the source template, re-extract, and confirm the warnings are gone. Only after the pasted markup is clean should you validate the deployed URL with the official tool for the search feature you target.
Parse Errors, Profile Warnings, and Informational Notes
One of the easier mistakes to make with a JSON-LD checker is treating every warning as a blocking error. The Lizely extractor keeps three categories visually separate, and each one means something different for what you should do next.
| Category | What it signals | Action it implies |
|---|---|---|
| Parse error | The JSON block could not be parsed, so properties cannot be read | Fix the template until the block parses; downstream checks are unreliable until this is resolved |
| Profile warning | The item parsed cleanly but a documented required or recommended property is missing | Compare against the linked documentation; either add the property or confirm it is genuinely out of scope for the page |
| Informational note | A type or property is present but no documented profile applies, or a known limitation of the tool is relevant | Use as context, not as a defect list to work through |
That separation matters because it stops you from "fixing" something that is not broken. A property warning for an unfamiliar Schema.org type does not mean the page is invalid; it means the tool deliberately did not invent a profile for it. The right response is to read the extracted values and decide whether the page actually needs that field, rather than padding the object with fabricated values to silence the warning. Fewer complete and truthful properties are preferable to a large object filled with generic placeholders, and the extraction report is meant to make that distinction obvious.
What to Do After Extraction: Fix the Template, Then Validate the Live URL
Extraction tells you what is in the markup. It does not tell you whether the page will rank, be indexed, or earn a rich result. Once the pasted-HTML inventory is clean, the next step is to validate the deployed URL with the official validator for the feature you actually target. Google documents JSON-LD, Microdata, and RDFa support for specific features in its structured data introduction; the right tool to follow is the one tied to that feature, not a general-purpose checker.
Three checks after deployment are worth keeping in a routine, and each one answers a different question than the extractor:
- Run the deployed URL through Google's Rich Results Test for any type that targets a Google feature, to confirm the response the crawler receives parses and matches the feature's expectations.
- Watch Search Console enhancement reports after the next recrawl; persistent drops there usually mean template drift, not extraction issues.
- Test the actual page template across representative records, not just one example, so a missing field on one variant does not slip through unnoticed.
This is also where the no-fetch boundary of the Lizely extractor pays off. Because the tool never requests the live URL, you can paste authorized HTML from a staging environment, an export, or a local build without crossing into cross-origin failures or private-network requests. The extraction result is evidence about what you pasted; the validator result is evidence about what a crawler receives, and both are worth keeping separate.
Limits the Extractor Will Not Cross
The Structured Data Checker & Extractor works inside a clearly drawn perimeter, and that perimeter is part of why its output is trustworthy. A few limits are worth keeping in mind so the inventory is not mistaken for a universal semantic-web verdict.
- It extracts JSON-LD and Microdata only. RDFa is outside the current product boundary and is shown as out of scope rather than counted as absent or invalid.
- It never fetches or runs a webpage. No script from the pasted document executes, links are not followed, images are not loaded, and forms are not submitted.
- Input size and item counts are bounded, so an accidental full-site dump cannot freeze the page; if you need to inspect a large set, batch the templates.
- Required-property guidance applies only where the tool has a documented profile. Unknown types are still extracted but are not assigned invented requirements.
- A clean extraction is evidence about the pasted document, not a guarantee of search appearance. Search engines decide whether and when enhanced presentation is shown.
Used that way, extraction becomes the transparent preflight step it is meant to be: paste authorized HTML, inspect every extracted item, resolve parse errors first, review profile warnings against the linked documentation, and then verify the deployed response with the official tool. The output is evidence about the pasted document, and a strong evidence base is what makes the rest of the workflow worth trusting.
For a deeper look, see Extract URLs From a Sitemap: A Quick Cheat Sheet.