JSON-LD

1. What JSON-LD is

JSON-LD is “a lightweight syntax to serialize Linked Data in JSON” — a W3C Recommendation, version 1.0 since 2014 and version 1.1 since July 2020 (W3C, 2020). The name expands to JSON for Linked Data: it lets a JSON document describe a graph of typed entities with stable identifiers, suitable for ingestion by any consumer that speaks RDF or Linked Data.

In a Schema.org context, JSON-LD is one of three serialization formats — alongside Microdata and RDFa — that carry the vocabulary. The vocabulary itself (Organization, Person, Article, sameAs, mainEntity) is defined at schema.org regardless of which serialization a page uses; JSON-LD is just the wrapper. Schema.org’s own getting-started page states it plainly: “You use the schema.org vocabulary along with the Microdata, RDFa, or JSON-LD formats to add information to your Web content” (Schema.org Getting Started). What each Schema.org type and property signals to an AI engine — why sameAs matters more than FAQPage for citation work, for example — is the subject of Schema.org for AI.

2. The three Schema.org serialization formats

The three formats all describe the same graph; they differ only in how the markup is woven into the page.

The same Organization declaration in each format, for the same minimal entity:

<!-- Microdata -->
<div itemscope itemtype="https://schema.org/Organization">
  <span itemprop="name">Example Co</span>
  <link itemprop="url" href="https://example.com">
  <link itemprop="sameAs" href="https://en.wikipedia.org/wiki/Example_Co">
  <link itemprop="sameAs" href="https://www.wikidata.org/wiki/Q000000">
</div>

<!-- RDFa -->
<div vocab="https://schema.org/" typeof="Organization">
  <span property="name">Example Co</span>
  <link property="url" href="https://example.com">
  <link property="sameAs" href="https://en.wikipedia.org/wiki/Example_Co">
  <link property="sameAs" href="https://www.wikidata.org/wiki/Q000000">
</div>

<!-- JSON-LD -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Co",
  "url": "https://example.com",
  "sameAs": [
    "https://en.wikipedia.org/wiki/Example_Co",
    "https://www.wikidata.org/wiki/Q000000"
  ]
}
</script>

Read at a glance: Microdata and RDFa are woven into the visible HTML — every property has to be attached to an element a user sees. JSON-LD is one self-contained block the page renders separately. That separation is what drives Google’s recommendation, treated next.

3. Why JSON-LD is the recommended format

Google’s Intro to How Structured Data Markup Works states the recommendation directly:

“In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale.”

The same page is equally clear that the recommendation is operational, not technical: “all 3 formats are equally fine for Google, as long as they are valid and implemented properly per the feature’s documentation.” JSON-LD is not preferred because Google parses it better — it’s preferred because of how it interacts with the page you maintain.

Four concrete reasons, in order of practical impact:

1. Decoupled from visible HTML. Markup changes never touch templates and never risk breaking visible layout. A pricing display refactor cannot accidentally invalidate the Product markup, because the two are not the same elements.
2. Easy to inject at any layer. A CMS, a build step, or a server middleware can emit the <script> block as a string. Microdata and RDFa, by contrast, require the templating engine to interleave attributes with the elements being rendered.
3. Standard JSON parsing. Any consumer with a JSON parser can read the graph; no DOM traversal or attribute-resolution logic is needed. This matters most for downstream tooling, less for Google itself.
4. Failure modes are bounded. A syntactically invalid JSON-LD block fails as markup but leaves the page intact. A malformed Microdata or RDFa attribute can co-occur with HTML rendering bugs.

The cases where the other two formats still earn their place are narrow. Sites with extensive existing Microdata where migration cost exceeds the benefit can keep what they have — Google parses all three equally. RDFa remains common in government and academic linked-data publishing, where its multi-vocabulary support (via prefix declarations) is genuinely useful. For a new deployment, JSON-LD is the answer.

4. JSON-LD anatomy — the four keywords that carry the load

JSON-LD has a richer keyword surface than most pages need — @id, @graph, @vocab, @reverse, @container, framing, contexts that override contexts. For AI-citation work, four keywords carry essentially all the weight.

A minimal Organization block exercising all four:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#org",
  "name": "Example Co",
  "url": "https://example.com",
  "sameAs": [
    "https://en.wikipedia.org/wiki/Example_Co",
    "https://www.wikidata.org/wiki/Q000000",
    "https://www.linkedin.com/company/example-co"
  ]
}

sameAs is the entity-resolution join key — the part of JSON-LD that does the work AI engines actually consume, even when they don’t parse the markup directly (see §6). For how a sameAs link actually resolves into a knowledge-graph entity, see Entity Recognition and Knowledge Graph Presence. Pages with multiple entities (an Organization and a Person author and an Article) can either emit one <script> block per entity or wrap them all in a single block under @graph; for per-type templates and validation steps, see the Schema Implementation playbook.

5. Placement and delivery — where the block goes, what crawlers see

Three placement questions matter, each with a short answer.

Where in the document. Google’s intro page describes JSON-LD as “a JavaScript notation embedded in a <script> tag in the <head> and <body> elements of an HTML page” — both are valid. The General Structured Data Guidelines add only that the markup should be “on the page that it describes”. In practice, <head> is the common default because it places the markup before the body and makes it easy to find in view-source; <body> is fine and is what many CMS plugins emit.

Multiple blocks. Google’s documentation does not impose a per-page limit on JSON-LD blocks, and emitting one block per entity (Organization in one, Article in another, BreadcrumbList in a third) is widely seen in production. The alternative — wrapping multiple entities in a single block under @graph — is a stylistic choice rather than a correctness one.

JS-injected JSON-LD. Markup written into the DOM by client-side JavaScript will only reach a consumer that executes JavaScript. Google’s JavaScript SEO basics confirms Googlebot does so: “Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript.” AI crawlers behave very differently, and the empirical picture is what matters more than the vendor docs (which mostly don’t address rendering directly):

Server-rendered or build-time-injected JSON-LD reaches every row of that table. Client-injected JSON-LD reaches only Googlebot reliably. For AI visibility, render the markup at the same layer that serves the visible content; see SSR for AI Crawlers for the wider rendering trade-off.

6. How AI engines actually consume JSON-LD

The honest mechanism splits hard by surface, and the evidence now exists to say so rather than hedge.

Google’s AI features and your website page is direct on the index-integrated side: “You don’t need to create new machine readable files, AI text files, or markup to appear in these features. There’s also no special schema.org structured data that you need to add.” JSON-LD reaches Google AIO via the same index path it has always reached Google Search.

The live-fetch finding is the surprising one. A December 2025 controlled test by searchVIU placed a price only inside JSON-LD on a test page and queried five AI systems; none of the live-fetch chatbots extracted it. Their summary is unambiguous: “Current AI chatbots do NOT use JSON-LD Schema Markup during direct retrieval. Instead, they exclusively extract visible HTML content.” An independent observation from February 2026 (Search Engine Roundtable) found ChatGPT and Perplexity will surface values even from fabricated, syntactically invalid JSON-LD — they are reading the markup as text on the page, not as a parsed structure.

The implication is bounded, and worth keeping bounded. JSON-LD on live-fetched pages doesn’t hurt — it just doesn’t deliver the parsing advantage its format suggests it should. The entity benefit still reaches these models, but through the model’s prior and the knowledge graph rather than through your <script> block. Search Engine Land summarises the balance well: “Schema markup is infrastructure, not a magic bullet. It won’t necessarily get you cited more, but it’s one of the few things you can control that platforms such as Bing and Google AI Overviews explicitly use” (Jurenka, 2026). Render JSON-LD because it earns its keep on the index side and costs nothing on the live-fetch side — not because chatbots will parse it.

7. Validation, errors, and anti-patterns

Two validators, two distinct semantics. The Rich Results Test checks whether markup is eligible for one of Google’s rich-result features — passing it does not mean the markup is technically correct, only that Google will consider it for a specific surface. The Schema Markup Validator checks vocabulary conformance against the Schema.org spec — passing it does not mean Google will render anything. Use both in series: SMV for “is my markup well-formed Schema.org?”, RRT for “will Google show a rich result?”.

JSON-LD-specific failure modes, distinct from the vocabulary-level anti-patterns in Schema.org for AI:

The load-bearing anti-pattern, restated as the operational equivalent of Schema.org for AI §7’s vocabulary-level rule: invalid or content-mismatched JSON-LD is worse than none. Markup-versus-visible contradictions trip Google’s structured-data manual actions and trip AI text-readers simultaneously, because the live-fetch surfaces read the JSON-LD as page text and now have two contradictory facts to choose from.

8. Where to go next

For the term and its neighbors, see the GEO glossary.

References

W3C and Schema.org:

• W3C — JSON-LD 1.1: A JSON-based Serialization for Linked Data (Recommendation, 2020-07-16)
• Schema.org — Getting Started · Schema.org vocabulary · Schema Markup Validator

Google Search Central:

• Intro to How Structured Data Markup Works — JSON-LD recommendation, placement, format parity
• General Structured Data Guidelines — ranking impact, manual actions
• AI features and your website — no AI-specific schema required
• Understand the JavaScript SEO basics — Googlebot WRS rendering
• Rich Results Test

AI crawler documentation:

• OpenAI — Overview of OpenAI Crawlers
• Anthropic — Does Anthropic crawl data from the web?
• Perplexity AI — Perplexity Crawlers

Independent / industry:

• searchVIU — Schema Markup and AI in 2025: What ChatGPT, Claude, Perplexity & Gemini Really See (2025-12-02) — controlled test of live-fetch JSON-LD consumption
• Search Engine Land — How schema markup fits into AI search — without the hype (2026-03-25)
• Search Engine Roundtable — ChatGPT & Perplexity Treat Structured Data As Text On A Page [observation] (2026-02-03)