JSON-LD — agent readiness

Why an agent cares

It is the one part of a page an agent can read without interpreting prose, so a syntax error or a missing required property costs the whole block. We check the shapes with published required properties, not everything a vocabulary permits.

Adoption

Web baseline. Standard equipment on the web. Its absence is the exception rather than its presence.

Direction of travel: ► flat, as at 2026-07-28.

JSON-LD is on roughly 41% of pages (Web Almanac 2024, HTTP Archive, about 16M sites).

What we check

Absence is never a finding. Every check below runs only once jsonLdPresent is true, so a site that has not adopted this is not assessed on it and appears in no report. 6 of these 6 can fail it. In a Lumar crawl these land on the page's own row.

Check	Severity	Raises	On whose authority
`jsonLdInvalidJson`	high	conformance, usability	specification (JSON-LD 1.1)
`jsonLdMissingContext`	medium	usability	Lumar readiness profile
`jsonLdMissingType`	medium	usability	Lumar readiness profile
`jsonLdMissingRequiredProp`	medium	usability	Google Search profile
`jsonLdInvalidValueFormat`	medium	usability	Schema.org profile
`jsonLdNonSchemaContext`	low	usability	Lumar readiness profile

Examples

Both of these are fixtures the test suite runs through the real collector, not snippets written for a document: the first is a shape we score as valid, the second is one we flag.

correcthtmltest/e2e/test-pages/content/correct.html

<!-- jsonLdPresent + correct: valid schema.org Article — parseable, schema.org @context, an @type,
         and an ISO-8601 datePublished. (Article has no *required* props per Google, so none are demanded.) -->
    <script type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@type": "Article",
        "headline": "How agent-readiness works",
        "author": { "@type": "Person", "name": "Ada Lovelace" },
        "datePublished": "2026-06-01",
        "publisher": {
          "@type": "Organization",
          "name": "Example",
          "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }
        }
      }
    </script>

<!-- jsonLd + correct: a schema.org Event with every Google-required prop — name, an ISO-8601
         startDate, and a physical Place location carrying the required location.address
         (re-verified 2026-07-28; location.name is recommended, not required). -->
    <script type="application/ld+json">
      {
        "@context": "https://schema.org",
        "@type": "Event",
        "name": "Agent Readiness Summit",
        "startDate": "2026-09-01T18:00:00Z",
        "location": {
          "@type": "Place",
          "name": "Example HQ",
          "address": { "@type": "PostalAddress", "streetAddress": "1 Main St", "addressLocality": "London" }
        }
      }
    </script>

present but wronghtmltest/e2e/test-pages/content/issues.html (excerpt)

<!-- jsonLdPresent: yes. jsonLdInvalidJson: the trailing comma makes this block unparseable, so every
         consumer drops it wholesale and no other defect can be evaluated on it. -->
    <script type="application/ld+json">
      {
        "@type": "Article",
        "author": "Ada Lovelace",
        "datePublished": "not-a-date",
      }
    </script>

<!-- jsonLdNonSchemaContext + jsonLdMissingType: parseable, but @context is not
         schema.org and @type is absent. -->
    <script type="application/ld+json">
      { "@context": "https://example.com/ns", "name": "Untyped Thing" }
    </script>

Specifications

Document	Revision	Kind
JSON-LD 1.1	`W3C Recommendation`	specification
Schema.org	`v30.0`	specification
Google Search: Recipe structured data	`living`	vendor profile
Google Search: Event structured data	`living`	vendor profile
Schema.org Date and DateTime (ISO 8601)	`v30.0`	specification
Google Search: Article structured data (states no required properties, which is why we check none)	`living`	vendor profile

Last re-read against the published documents: 2026-08-12.