JSON-LD Checker Extraction: Details That Matter

The details that matter when using a JSON-LD checker are the source boundary, item boundaries, declared @type values, property values, parse errors, and agreement between the markup and the page users can see. Treat extraction as an inventory, not a verdict. The Structured Data Checker & Extractor gives you a local way to inspect JSON-LD and Microdata already present in pasted HTML. It expands JSON-LD containers, lists each discovered type and property, preserves nested item relationships in its bounded view, and reports malformed blocks separately. Its focused missing-property warnings apply only to explicit supported profiles, so an unfamiliar type can still be extracted without receiving invented requirements. This distinction protects the audit from overclaiming: valid syntax can still describe content that is inaccurate, hidden, irrelevant, or inconsistent with the page. Likewise, a local warning does not prove that a search engine will reject the markup. For a Google feature, the local inventory is a preflight checkpoint before testing the deployed URL with Google’s official validator.

Establish which HTML layer you are testing

An extraction can describe only the source placed in the checker. Identify that source before interpreting any result:

• Delivered HTML: Use the response returned by the server when that response contains the structured data. This is the most relevant evidence for markup embedded in the initial page.
• Controlled rendered-DOM export: Use an exported DOM snapshot when a framework adds structured data after loading. The export must represent the stage you actually intend to inspect.
• Several stages: If client-side code may alter the markup, compare the original response, rendered DOM, and crawler-visible output. A clean result from one stage cannot prove that another stage contains the same data.

The checker deliberately does not request a remote URL or execute the pasted page. It parses the source in a detached browser template fragment, renders bounded extracted values as text, and does not run scripts, follow links, load images, submit forms, or send the source to Lizely. Parsing happens in the browser. Input size and item counts are bounded, so use an authorized, representative page or template fragment instead of pasting an accidental full-site dump.

Read parse errors, inventory, and warnings separately

The useful question is not whether the page receives one green or red result. It is what each part of the output proves about the pasted document. Keep these signals distinct:

Signal	What it establishes	What it does not establish
JSON-LD parse error	A particular script block contains malformed JSON and could not be read as intended.	It does not invalidate valid items found in other blocks.
Extracted item	The checker found an item and can display its declared type and visible properties.	Its presence alone does not establish search eligibility.
Missing-property warning	An explicit local profile did not find a property covered by that profile.	It does not prove that a search engine will reject the page.
Informational observation	There is a boundary or structural detail worth reviewing.	It is not automatically a validation failure.
Official feature validation	A deployed URL has been tested against the current rules for a particular search feature.	It cannot guarantee indexing, ranking, or a rich result.

This separation prevents a common category error: treating syntax validity as content accuracy or search approval. Schema.org defines a broad vocabulary, while individual search products define their own required and recommended properties. The checker therefore applies only inspectable profiles backed by a documented rule set. An unknown type remains extractable, but the tool does not invent requirements for it. Its first job is extraction rather than a rich-result eligibility score.

Preserve containers and item boundaries

JSON-LD may appear as one object, a top-level array of objects, or an object containing an @graph with several nodes. The checker expands those containers into individual inventory items while preserving declared @type values and visible properties. Review the expanded items against the original container so that a node buried inside an @graph is not overlooked. A malformed script is reported on its own, allowing valid objects elsewhere in the same document to remain visible.

Microdata follows a different path through ordinary HTML. Attributes such as itemscope, itemtype, and itemprop establish items and properties. The checker builds a bounded view of top-level items and recognizes values exposed through content attributes, links, media source attributes, date values, and text content. Nested Microdata items remain visibly nested rather than being flattened into unrelated strings. The underlying attributes and processing model are described in the WHATWG HTML Microdata specification.

Format	Details to inspect	Boundary
JSON-LD	Single objects, arrays, @graph nodes, declared types, properties, and malformed script blocks.	Valid items remain reportable when another script block fails to parse.
Microdata	Item scopes, item types, property attributes, attribute-derived values, text, dates, links, and nested items.	The displayed property view is bounded, particularly for top-level inventory items.
RDFa	No extraction or profile assessment is performed.	RDFa is outside the product boundary and is never counted as absent or invalid structured data.

Item boundaries matter because a property can be meaningful only when attached to the correct entity. Before acting on a warning, confirm that the value belongs to the intended object, graph node, or Microdata scope and has not been pulled into an unrelated item.

Judge each property against the entity and target

There is no universal list of properties that matters for every consumer. Review the details that determine whether each extracted item accurately represents the intended page:

• Entity identity: Confirm that the intended item is present and that its declared @type or itemtype matches the entity described by the page.
• Property relevance: Decide whether each value is specific, current, and useful for the entity rather than present only to make the object look complete.
• Source mapping: Trace the value to the exact JSON field or HTML attribute. This helps explain a blank URL caused by the wrong attribute instead of an actually missing page address.
• Visible agreement: Compare names, descriptions, dates, images, prices, identities, and other extracted claims with the content users can actually see. Hidden, fabricated, or irrelevant values remain a content problem even when the JSON parses.
• Feature requirements: Consult the current documentation for the exact search feature. Required and recommended properties can differ between consumers even when they use the same Schema.org vocabulary.
• Duplicates and variants: Check whether the template emitted the same entity twice, omitted a field in one record type, or combined values from different page states.

Use Google’s structured data introduction as the starting point for the broader role of structured data, then follow the documentation for the feature you are targeting. A focused warning should prompt a source review, not an automatic field insertion. Fewer complete and truthful properties are preferable to a large object filled with generic values added merely to silence a warning.

Extract and review the supplied HTML

1. Collect the correct source. Start with authorized delivered HTML or a controlled rendered-DOM export. Record which page state and rendering stage the source represents.
2. Paste the source into the checker. Do not paste a URL expecting a live fetch. The tool analyzes the supplied HTML locally and never requests or executes that page.
3. Run the extraction. Let the checker discover JSON-LD script blocks and Microdata items before reviewing the resulting inventory.
4. Resolve parse errors first. Review malformed JSON separately and repair the affected source block. Do not assume that this error removed otherwise valid items elsewhere in the document.
5. Inspect every discovered item. Check its declared type, properties, and container. For JSON-LD, account for objects, top-level arrays, and @graph nodes. For Microdata, verify scopes, property attributes, and nested relationships.
6. Read focused warnings in context. Confirm that the item has a documented profile, inspect the missing property in the source, and compare it with visible content and current feature guidance. Do not invent rules for an unfamiliar type.
7. Fix the source template. Correct the template or record variant that emits the problem, remove duplicate or inaccurate markup, and test representative examples rather than one unusually complete record.
8. Move to deployed validation. After the corrected response is public, test the deployed URL with the official validator for the search feature you actually target.

Confirm what the deployed response contains

A local clean result is evidence about one pasted document, not proof of the public response. After deployment, inspect the actual URL because server configuration, rendering, redirects, or framework behavior can change what a crawler receives. If the type targets a Google feature, use Google’s Rich Results Test on the deployed page and inspect Search Console enhancement reports after recrawling. For another search feature, use that consumer’s official validation process.

Test representative records across the page template, including records likely to have optional fields, long values, nested entities, or missing data. Search engines decide whether and when enhanced presentation appears. No local checker can guarantee indexing, ranking, or a rich result.

Sign off on the final evidence

Before deployment, confirm that you can answer these extraction questions:

• Which HTML source and rendering stage were tested?
• Did every JSON-LD block parse, and were valid items preserved elsewhere?
• Do object, array, @graph, and Microdata boundaries match the intended entities?
• Are declared types and properties present, specific, and correctly nested?
• Does every focused warning have a documented profile and a source-level explanation?
• Do the extracted claims match content users can see?
• Are duplicates, blank values, and record-specific omissions resolved in the template?
• Has the corrected deployed response passed the official test for the intended feature?

That evidence provides a transparent preflight for the markup you supplied. It keeps extraction facts, profile warnings, content review, and search eligibility as separate decisions.

If you're weighing options, Details That Matter for GEO Brand Awareness Questions covers this in detail.