# 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 JSON**An 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 Context**A 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 Type**A 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 Property**An 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 Format**A 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 Context**The `"@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 Valid`jsonLdValid`
-   JSON-LD Conformance Issue Detected`jsonLdConformanceIssueDetected`
-   JSON-LD Findings`jsonLdFindings`
-   JSON-LD Block Count`jsonLdBlockCount`
-   JSON-LD Entity Types`jsonLdEntityTypes`
-   JSON-LD Parse Error Samples`jsonLdParseErrorSamples`
-   JSON-LD Missing Required Property Samples`jsonLdMissingRequiredPropSamples`
-   JSON-LD Invalid Value Samples`jsonLdInvalidValueSamples`
-   JSON-LD Invalid JSON`jsonLdInvalidJson`
-   JSON-LD Missing Context`jsonLdMissingContext`
-   JSON-LD Missing Type`jsonLdMissingType`
-   JSON-LD Missing Required Property`jsonLdMissingRequiredProp`
-   JSON-LD Invalid Value Format`jsonLdInvalidValueFormat`
-   JSON-LD Non-Schema Context`jsonLdNonSchemaContext`

## About JSON-LD

Structured data describing what this page is about.

[Read how JSON-LD is checked](https://agentic-readiness.lumar.io/docs/content/json-ld), 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](https://agentic-readiness.lumar.io/scan-at-scale), or check a single URL with the [scanner on this site](https://agentic-readiness.lumar.io/), which runs the same code with no account.

[Get Lumar pricing →](https://www.lumar.io/pricing/)