Separate a JSON error from a content decision

A broken comma and a misleading description require different fixes. The first can stop a block from being parsed as JSON; the second can remain perfectly readable JSON while saying the wrong thing about a page. An inventory helps you see what you supplied, but it cannot decide whether the published content supports each statement.

Use the JSON-LD Inspector for a local syntax and literal-key review. It reports JSON parsing outcomes and inventories objects containing explicit @id or @type keys. It does not expand a JSON-LD context, resolve relative identifiers or validate a Schema.org vocabulary. A “JSON parsed” block is the start of the review.

Inspect a graph with seven visible objects

1. Open the inspector and choose Load connected graph.
2. Keep the input format set to Raw JSON.
3. Choose Inspect sample.
4. Download the CSV to keep both block outcomes and object locations.

The invented graph describes an organization, a website and a page. A fourth description adds the organization’s URL. The page points to the website and to a person who is not described in the sample. The website points to the organization. This creates seven inventoried objects: four descriptions and three reference-only objects.

{
  "@type": "WebPage",
  "@id": "https://example.com/guide/#page",
  "isPartOf": { "@id": "https://example.com/#site" },
  "author": { "@id": "https://example.com/team/#person" }
}

Review shared identifiers without deleting useful data

The organization ID occurs in two descriptions and one reference. Counting every occurrence as a duplicate entity would give a misleading result. The reference points to the organization; the two descriptions provide different properties about it. Compare their properties and source components before removing either block.

The W3C JSON-LD specification on node identifiers explains how identifiers connect descriptions. Multiple descriptions can concern the same resource. The inspector therefore calls this “same literal ID has multiple descriptions,” not an automatic error. A conflict such as two incompatible names for one organization needs an editorial decision that the occurrence count cannot make.

The person’s ID is not described elsewhere in these supplied blocks. That does not by itself make the reference invalid: the resource might be described outside the sample. Check what the page intends to claim and where that person is identified. Add an accurate description only when there is a reason for it; do not invent a biography just to clear a review note.

Literal matching also has a boundary. #org and https://example.com/#org are different text strings to this tool. It does not apply a base IRI, aliases or remote context definitions to determine semantic equivalence. When you need those operations, use a conforming JSON-LD processor and supply the correct document context.

Keep one malformed block visible

Choose Load mixed HTML example. This changes the input format to HTML with JSON-LD scripts and inserts two blocks. The first is the connected graph. The second deliberately contains a trailing comma:

{"@type":"Article",}

After inspection, the summary reports two blocks, one parsed and one syntax error. The successful block still contributes its seven inventory objects. The CSV includes a block-outcome row for the failure, so the working first block cannot conceal a broken second one. The precise parser error wording can vary by browser; the one-parsed, one-error result is the useful comparison.

Remove the comma in a copy of the sample and inspect again. Two parsed blocks should now appear, and the explicit Article type contributes one additional inventory object. This only fixes the deliberate JSON syntax problem. A type-only Article object is not a complete publishing implementation.

Choose the input format deliberately

Raw JSON mode accepts one complete JSON value. HTML mode looks for script elements whose trimmed type is application/ld+json. It reads their text in an inert template and never executes pasted scripts. Other script types and scripts inside nested template contents are outside that extraction. A page URL alone does not cause a fetch.

Contexts are not fetched or expanded. Objects inside literal @value content are not traversed. Aliased keywords and typed values may need interpretation beyond this inventory. JSON parsing also does not report duplicate JSON property names that have already been overwritten by the parser. Keep the source and use a suitable validator when those cases matter.

The input limit is 1 MB, with up to 100 script blocks, 5,000 visited objects or arrays and 60 levels of nesting. Exceeding a traversal limit stops the review and leaves exports disabled. Otherwise, the visible table shows the first 100 inventory objects, and the CSV includes all objects plus every block outcome. Formula-like exported cells receive an apostrophe prefix.

Verify the saved page and its claims

Use the Structured data review worksheet to assign follow-up work: locate the component that emitted a block, compare shared-ID properties, confirm the visible facts and record a dated live test. The sample rows begin as Not started; they are instructions for your review, not completed site findings.

Google’s structured data guidelines require relevant, accurate markup and feature-specific requirements. Google also says correct markup does not guarantee a rich result. After saving changes, test the published URL with the Rich Results Test and review the applicable feature documentation. Keep those results separate from this local inventory.

Finally, inspect the saved page rather than relying only on an editor preview. Confirm the expected blocks are present and that the claims still match what a visitor sees. Use the head tag checker for a separate supplied-metadata review. Neither local check establishes crawling, indexing or search appearance.