Pages with invalid JSON-LD

A per-URL report: one row per page that matches, over the pages a crawl reached.

What this report returns

JSON-LD script blocks are how a page describes itself to search engines and AI agents in machine-readable form.

A row appears here when any of these is wrong, worst first:

Invalid JSONAn ld+json block doesn't parse as JSON (a trailing comma is enough; an empty block also counts), so every consumer drops the entire block.Fix Make the block valid JSON; validate with a JSON linter or Google's Rich Results Test.
Missing ContextA top-level entity declares no "@context", so a consumer reading the common inline form cannot map its short property names onto schema.org.Fix Add "@context": "https://schema.org" to each top-level entity.
Missing TypeA top-level entity has no "@type", so an agent cannot tell what the block describes. The JSON-LD is still legal, but it is not usable schema.org markup.Fix Declare a schema.org type on the entity, for example "@type": "Article".
Missing Required PropertyAn entity is missing a property Google requires for its type's rich-result eligibility (e.g. Recipe needs name + image; Event needs name, startDate and a located location), so the entity may be ignored.Fix Add the required properties for that type per Google's structured-data reference.
Invalid Value FormatA property value has the wrong format (e.g. a date that isn't ISO 8601), so consumers reject it.Fix Use the format schema.org expects; dates as YYYY-MM-DD or a full ISO 8601 timestamp.
Non-Schema ContextThe "@context" does not reference schema.org, so search engines and AI agents do not recognise the vocabulary.Fix Use "@context": "https://schema.org" (a custom vocabulary can sit alongside it, not instead of it).

The Conformance Issue Detected column is true only for unparseable JSON, which JSON-LD 1.1 requires (a JSON-LD document must be valid JSON); a missing @context, @type or vocabulary is Lumar's readiness bar, and required properties and value formats follow Google Search and Schema.org guidance rather than a specification rule, so those rows read as usable-by-agents problems and not as spec violations.

The columns it shows

Every defect this technology can carry is a column in the grid, worst first, so nothing is hidden behind a filter you have to know to apply.

JSON-LD ValidjsonLdValid
JSON-LD Conformance Issue DetectedjsonLdConformanceIssueDetected
JSON-LD FindingsjsonLdFindings
JSON-LD Block CountjsonLdBlockCount
JSON-LD Entity TypesjsonLdEntityTypes
JSON-LD Parse Error SamplesjsonLdParseErrorSamples
JSON-LD Missing Required Property SamplesjsonLdMissingRequiredPropSamples
JSON-LD Invalid Value SamplesjsonLdInvalidValueSamples
JSON-LD Invalid JSONjsonLdInvalidJson
JSON-LD Missing ContextjsonLdMissingContext
JSON-LD Missing TypejsonLdMissingType
JSON-LD Missing Required PropertyjsonLdMissingRequiredProp
JSON-LD Invalid Value FormatjsonLdInvalidValueFormat
JSON-LD Non-Schema ContextjsonLdNonSchemaContext

About JSON-LD

Structured data describing what this page is about.

Read how JSON-LD is checked, including the specification it is validated against and a worked correct and broken example.

Running it

This report comes with Agentic Readiness in Lumar and appears on every crawl of any project that has it turned on. See the whole set, or check a single URL with the scanner on this site, which runs the same code with no account.

Get Lumar pricing