After running a JSON-LD or Microdata checker, "checking the result" means reading an inventory of every structured-data item the extractor found in your source, not waiting for a single green tick. The output lists each JSON-LD script and each Microdata item separately, shows the declared @type or itemtype, surfaces the properties the extractor could read, and flags focused gaps against profiles the tool supports. Parse failures sit apart from missing-property warnings, and informational notes stay separate from both. Reading the result well is the step where most implementations either move forward or quietly ship markup that does not match what the page actually shows. Treat the inventory as evidence about the pasted document, then use that evidence to decide whether the source template needs to change, whether a different export of the same page tells a different story, and whether the deployed URL is ready for the official validator tied to the search feature you actually target.
What the Extractor Actually Returns
The Structured Data Checker & Extractor is built around extraction first, so the result you read after a run is an inventory rather than a scorecard. For every JSON-LD script block it finds, the checker expands one object, an array of objects, and an @graph wrapper into individual items while preserving each declared @type. A malformed JSON block is reported on its own line, so one broken script does not erase valid items found elsewhere in the same document. For every Microdata item it walks, the checker reports the itemscope root, the itemtype, and a bounded list of itemprop values it could read from content attributes, links, media source attributes, date values, and text content. Nested items remain visibly nested rather than being silently flattened into unrelated strings. The result is therefore something you read item by item, type by type, and property by property, and the structure of that read is the main thing that distinguishes a useful extraction from a generic syntax pass.
Walking Through the Result, Top to Bottom
- Open the Structured Data Checker & Extractor and paste the delivered HTML source or a controlled rendered-DOM export of the page you want to audit. The checker does not fetch your URL, run scripts, or load resources.
- Run extraction and let the parser expand JSON-LD containers and walk top-level Microdata items.
- Read any JSON-LD parse errors first, on their own. An error here means one script failed to parse and is excluded from the item list, while the rest of the document is still scanned.
- Review the JSON-LD items list. For each item, confirm the declared @type matches the page, scan the visible properties, and note the focused missing-property warnings.
- Review the Microdata items list. For each top-level itemscope, confirm the itemtype and read the bounded property view.
- If your framework injects markup after load, compare the original response, the rendered DOM, and the crawler-visible export before drawing conclusions.
- Fix the source template, redeploy, then validate the deployed URL with the official tool for the search feature you target before you ship.
The reason the order matters is that a parse error is a syntax problem you cannot fix by adding more properties, while a missing-property warning is a content question. Reading them in this sequence keeps the two kinds of fix separate and stops the audit from collapsing into a single pass/fail verdict.
Parse Errors, Missing Properties, and Observations
The result deliberately separates three kinds of finding so you can act on each correctly. The same page can carry all three at once, and the lines are labelled so you never have to guess which is which.
| Result line | What it indicates | What to do with it |
|---|---|---|
| JSON-LD parse error | One script block did not parse as JSON | Fix the syntax in the template, then re-extract |
| Missing required property | Profile did not find a documented required field | Add the field only if it represents content users can actually see |
| Missing recommended property | Profile did not find a documented recommended field | Decide based on visible content and the feature you target |
| Unknown type extracted | Type recognized but no documented profile applies | Treat as informational; do not invent requirements |
| Informational observation | A boundary or limit that did not block extraction | Note it, then continue |
Understanding that separation is the point of checking the result at all. A clean run with zero missing-property warnings still leaves content accuracy, feature-specific policy, indexing, and rendering untested. A run with one informational note can still be a complete, ship-ready extraction. The lines tell you what is in the source, not whether the page will earn a rich result on a search engine.
Comparing the Same Page Across Three Sources
Many frameworks inject structured data after the initial HTML response, which is why a single paste is often not enough. Before you conclude anything from the inventory, paste three versions of the same URL side by side: the original response the server emits, a controlled rendered-DOM export captured after the framework has had a chance to inject, and the crawler-visible output you can obtain from your own headless fetch with scripts disabled. If the three inventories match, the result you read describes the page as deployed. If they diverge, the divergence is itself the finding, and it usually means a template loads a partial schema in the initial HTML and the framework fills in fields later, or that one variant emits a duplicate item your single-page audit would miss. Treating the post-extraction step as a comparison, not as a single read, is what turns the checker from a syntax tool into a debugging surface that catches real production bugs.
Acting on the Result: Template Fixes and Official Validation
Once the inventory is in front of you, the next move is in the source template, not in the markup editor. Required-property warnings deserve a content check first: does the visible page actually expose what the field would describe? If yes, add it; if no, the warning is correctly highlighting an absent fact, and adding a fabricated value to silence it makes the implementation less trustworthy. Microdata blank URLs almost always mean the wrong attribute was used, so cross-check itemprop against the rendered href before chasing the broader schema. After fixing the template, redeploy, then validate the public URL with the official tool for the search feature you target. For most Google features that is the Rich Results Test, and for general Schema.org shape that is the Schema.org validator. Read the Search Console enhancement reports after a recrawl to see what the crawler actually received. For a broader grounding on how search engines consume structured data, Google's structured data introduction covers the policy side, and the related guide Does a Clean JSON-LD Check Guarantee a Google Rich Result? walks through the gap between a clean local extraction and the search-engine decision that follows it.
What the Result Does Not Tell You
The result describes the pasted document. It does not describe what a search engine will do with that document. A warning in the output means the local profile did not find a property; it does not prove that a search engine will reject the page. Valid JSON can describe inaccurate, hidden, or irrelevant content, and a complete-looking object can still violate a search policy, disagree with the visible page, use an unsupported feature, or fail a deployment test. Conversely, Schema.org properties that are not part of a Google feature can still be meaningful to other consumers. The tool therefore separates parse errors, missing focused properties, and informational observations, and it does not collapse them into a single eligibility verdict. Required-property guidance is also not a substitute for content review. Markup should represent content users can actually see and should use specific, accurate values. 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. Search engines decide whether and when enhanced presentation appears, and no local checker can guarantee indexing, ranking, or a rich result.