Documenting the steps you use to extract structured data with a JSON-LD checker means writing down the exact inputs, parser outputs, and observed warnings for each run so the workflow is repeatable, auditable, and easy to hand off. A useful record is more than a screenshot: it names the source you pasted, lists every JSON-LD block and Microdata item the tool surfaced, separates parse errors from profile warnings, and notes any properties that were missing or blank. Because structured data sits on top of content that can drift, the notes should also record which template or page revision was sampled. The Structured Data Checker & Extractor works entirely inside your browser on the HTML you paste, so the documented facts describe the pasted source without uploading it. Logging steps this way turns ad-hoc testing into a checklist you can re-run before each release, share in a pull request, or reference during an audit, instead of a one-off inspection whose reasoning is lost the moment the tab closes.
What "Documenting the Extraction Steps" Actually Means
Documentation is more than pasting a URL into a tool and saving a screenshot. When you document the extraction steps for a JSON-LD checker, you are writing a procedure that another person - or future-you - can follow against a new page and reach the same observations. Three elements have to be captured.
The first is the input. The checker never fetches the page; it only parses the HTML you provide. So the record must identify whether that input was a static HTML source export, a controlled rendered-DOM export, or a snippet pulled from one script tag. If the template injects markup after load, the documentation should say which export you used and why, because the same page can present different structured data in its original response versus its rendered DOM.
The second is the inventory. JSON-LD can appear as a single object, an array, or as an @graph containing several nodes, and the checker expands those containers into individual items while preserving declared @type values. Microdata lives in itemscope, itemtype and itemprop attributes inside ordinary HTML. A good log lists each item found, its declared type, and its observed properties, rather than collapsing the document into one shape. Nested items remain visibly nested in the extraction output, so your documentation can record the same hierarchy instead of silently flattening values.
The third is the result category. Parse errors, profile warnings, and informational observations should be recorded separately, because they answer different questions: a malformed script, a missing high-value property, or a note about an unsupported structure. Treating those buckets as one block hides the real reason a deployment might fail and makes the log hard to compare against the next run.
The Inputs You Need to Record for Each Run
Before you start writing the procedure, decide which fields the documentation must capture for every extraction. The exact list depends on the team's review process, but the structured-data contract below is a reliable minimum.
Record the source. Note the file name, page URL the HTML was taken from, and the export method (source response, rendered DOM, or framework-rendered output). This matters because a JSON-LD block generated client-side may not appear in the original response, while a static export can include markup a crawler never receives.
Record the run environment. Capture the checker version, browser, and date. The Structured Data Checker & Extractor runs entirely in a detached browser template, so the source is not requested from a remote URL, executed as a page, or sent off the device, and that boundary is worth recording so reviewers know the facts came from local parsing only.
Record the inventory. List each JSON-LD object, each @graph node, and each Microdata item with its declared @type. Nested items should remain visibly nested, not flattened into unrelated strings. Use the same terminology the tool uses so the log lines up with the on-screen sections.
Record the parse state. Note any JSON-LD parse errors separately so one broken script does not erase valid items found elsewhere in the same document. A malformed block is reported on its own, and the documentation should preserve that separation rather than rolling it into a generic "failed" verdict.
Record profile warnings. Where the type is supported, the checker surfaces focused missing-property warnings with evidence-linked guidance. A warning means the local profile did not find a property; it does not prove a search engine will reject the page. The log should mark these as gaps, not as failures.
Record observations. Note any informational limitation the tool reports, such as RDFa being outside the current product boundary, so a reviewer does not mistake the extraction for a universal semantic-web audit. If RDFa is present on the page, the log should say so explicitly.
How to Write the Extraction Steps Down
The procedure below reflects the verified operating steps for the Structured Data Checker & Extractor and is written so each run produces a self-contained log entry. Copy it into your runbook and adapt the field names to your team's review process.
- Open the Structured Data Checker & Extractor in a fresh browser tab. Confirm the input box is empty and that no prior paste is still visible from a previous run.
- Export the HTML you want to inspect. For a server-rendered page, use the original response from your local server or crawler export. For a client-rendered page, use a controlled rendered-DOM export so any post-load markup is captured. Note the export method in the run entry.
- Paste the HTML into the input area. Do not paste a URL; the checker does not fetch or execute the page, so a URL alone will not produce an inventory.
- Run the extraction. Review three sections in order: JSON-LD parse errors, Microdata items, and the declared types, properties, and focused missing-property warnings. Treat each section independently rather than scrolling for a single pass/fail summary.
- For each JSON-LD item, record its @type, the visible properties, and any nested structures. Confirm the container shape (single object, array, or @graph) matches what your template is meant to emit.
- For each Microdata item, record the itemtype, the itemprop values, and any nested items. Flag blank URLs or blank content attributes, because those often point to the wrong attribute being used.
- Note any RDFa present. The checker does not extract or grade RDFa; documenting its presence prevents a reviewer from reading an empty RDFa section as "missing structured data."
- Save the log entry with the source provenance, inventory, parse state, profile warnings, and observations attached to a ticket or commit. Then fix the source template and validate the deployed URL with the official tool for the search feature you target.
A Reusable Documentation Template
A consistent template prevents two runs from being logged with different shapes, which makes diffs and audits possible. The table below shows one way to structure a single extraction log. Adapt the field names to your team's review process, but keep the column structure stable across runs so the entries are comparable.
| Field | What to capture | Why it matters |
|---|---|---|
| Run ID | Unique identifier, date, reviewer | Ties notes back to a commit or ticket |
| Source | File name, page URL, export method | Distinguishes response vs. rendered DOM |
| Input size | Approximate HTML size, item count | Stays within bounded input limits |
| JSON-LD items | Each @type, container shape, properties | Baseline inventory per item |
| Microdata items | Each itemtype, itemprop values, nesting | Baseline inventory per item |
| Parse errors | Broken JSON blocks, location hint | Isolated from valid items elsewhere |
| Profile warnings | Type, missing property, evidence link | Focused gaps, not blocking verdicts |
| Observations | RDFa presence, unsupported structures | Prevents misreading the audit |
When the same template is used for every run, you can compare two extractions side by side and answer questions like "did the template start emitting duplicate items," "is one variant missing a required field," or "did a JSON-LD block fail to parse after a refactor." None of those questions are answerable from a single unstructured screenshot, and none depend on the search engine returning a particular result.
If you want to validate how the extracted inventory reads in practice, the guide on how to read JSON-LD checker results after extraction walks through the same buckets in a more narrative form.
Common Gaps When Logging JSON-LD Checker Runs
Even with a template, certain details tend to slip through. Watch for these gaps when reviewing someone else's documentation or auditing your own.
Missing source provenance. A log entry that lists "two JSON-LD items, both parse cleanly" cannot be reproduced. Always record what was pasted, including the export method.
Conflating parse errors with profile warnings. A malformed JSON block is a syntax problem; a missing property is a completeness problem. Mixing them makes it hard to know whether a fix belongs in the template's serializer or in the data feed.
Treating warnings as failures. The checker surfaces focused missing-property warnings only where the product has a documented rule set. An unfamiliar Schema.org type is still extracted, but it is not assigned invented requirements. Documentation should preserve that distinction so reviewers do not block releases on cosmetic gaps.
Forgetting renderer differences. If a framework injects markup after load, the original response, the rendered DOM, and the crawler-visible output can each show a different picture. The documentation should say which export was used so future runs can target the same artifact.
Inventing requirements. Adding fields just 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, and the log should reflect that.
Limits of Local Documentation vs. Real Eligibility
Even a meticulous log only describes the pasted HTML. The Structured Data Checker & Extractor reports facts about the source you provided; it does not simulate how a crawler will receive the page, what policies the search feature applies, or whether indexing will occur. The official guidance in Google's structured-data introduction treats syntax validity and search eligibility as separate questions, and your documentation should reflect that split.
A local log can answer whether the intended type is present, whether a template emitted duplicate items, whether a required field is missing from one variant, whether a JSON-LD block fails to parse, or whether Microdata exposes a blank URL because the wrong attribute was used. It cannot answer whether the markup agrees with visible content, whether a feature-specific policy is satisfied, or whether deployment, indexing, and feature eligibility will hold at search time. After updating the template, validate the public URL with the official validator for the search feature you actually target and inspect the enhancement reports after recrawling.
For a deeper look, see Schema Markup Generator for Beginners: Your First JSON-LD.