JSON-LD

What is JSON-LD?

JSON-LD (JavaScript Object Notation for Linked Data) is a W3C-standard syntax¹ for embedding structured data in web pages. It serializes schema.org vocabulary into self-contained JSON blocks, separate from visible HTML. Engines parse these blocks to identify entities, relationships, and metadata that prose alone leaves ambiguous.

The format pairs each piece of data with a @context (pointing to schema.org's vocabulary) and a @type declaring what kind of thing this is, such as Organization, DefinedTerm, FAQPage, or Article. A single page can ship multiple JSON-LD blocks for different schema types, or one block with a @graph container holding multiple typed objects.

Minimum viable JSON-LD wrapper

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "DefinedTerm",
  "name": "Example",
  "description": "Short definition here."
}
</script>

The <script type="application/ld+json"> wrapper is what tells browsers to ignore the block (it is not executable JavaScript) while signaling to crawlers that the JSON inside is structured data.

Status in 2026

The dominant structured-data format on the web. Google recommends JSON-LD² "if your site's setup allows it" as the format easiest to implement and maintain at scale, while noting that all three structured-data formats (JSON-LD, Microdata, RDFa) are valid as long as the markup is correct. JSON-LD has become the de facto choice in new implementations. Major AI search surfaces (ChatGPT, Perplexity, Claude, Microsoft Copilot, Gemini chat, Google AI Mode, and Google AI Overview) have observable behavior consistent with parsing JSON-LD when present: engines surface schema-derived information in responses. The specific parsing details (weighting JSON-LD versus prose, handling conflicts between JSON-LD and visible HTML, parsing-failure fallback behavior) vary per engine and are generally not vendor-documented beyond Google's structured-data documentation. Microdata and RDFa remain valid but are increasingly rare in new code; legacy sites that still use them parse fine.

Note on FAQPage: FAQPage schema is still valid JSON-LD vocabulary and remains parsed by AI engines for question-answer extraction, but Google fully deprecated FAQ rich results on May 7, 2026, so FAQPage markup no longer triggers in-SERP visual treatment. See the FAQ schema entry for the full deprecation context. This entry's How-to-apply examples using FAQPage remain syntactically valid; the markup is just no longer a SERP rich-result lever.

Note on this entry's territory (paired with the FAQ schema entry's mirror observation on vendor-canonical territory): JSON-LD sits in strongly vendor-canonical territory. The W3C Recommendation (JSON-LD 1.1, 2020) and json-ld.org spec define the format formally; Google Search Central documentation explicitly recommends it as the preferred structured-data format; schema.org maintains the vocabulary it serializes. Google AI search surfaces (AI Mode, AI Overview) leverage JSON-LD as documented in their structured-data docs. Other major AI engines (ChatGPT, Perplexity, Claude, Microsoft Copilot) have observable behavior consistent with parsing JSON-LD but do not publish parsing details. For glossary readers: this entry's strategic position differs from non-vendor-canonical GEO concepts (such as LLMO and cite-ability) because vendor documentation on JSON-LD is comprehensive; the entry's added value is implementation guidance (generator helpers, validator workflow, schema-type separation) rather than concept definition. Paired with the FAQ Schema entry: that entry covers a specific schema.org type (with its May 7, 2026 deprecation context); this entry covers the JSON-LD syntax all schema types share.

How to apply

JSON-LD is the syntax; schema.org types are what you fill it with. Three operational moves:

• Use a JSON-LD generator helper, not hand-authored markup: build a small server-side function that takes typed input ({ name, description, ... }) and emits valid JSON-LD via your framework's metadata API (Next.js metadata, Astro <head> slot). Hand-authored payloads accumulate copy-paste errors across pages.
• Validate every payload before deploy with both validators: paste rendered output into Schema.org's validator (broader spec compliance across all schema.org types, including types Google does not surface as rich results) and Google's Rich Results Tester (eligibility check only for Google's supported rich-result types). Both flag the same payload differently; running both catches errors that either alone would miss.
• Choose a consistent pattern: separate <script> blocks per schema type, or one block with a @graph container: ship DefinedTerm, FAQPage, and BreadcrumbList either as three separate <script type="application/ld+json"> blocks or as one block whose top-level @graph array contains the three typed objects. Engines parse both patterns. Pick one and use it consistently. Separate blocks give independent validation surface area (easier to debug); @graph is more compact for entity-heavy pages. Avoid one giant untyped payload.

What to skip: hand-converting Microdata or RDFa markup on legacy pages. If a section uses them and validates fine, leave it; rewrite to JSON-LD only when you are editing that section for other reasons.

How it relates to other concepts

• The syntax layer underneath DefinedTerm schema, FAQ schema, and dozens of other schema.org types.
• A useful technical hygiene layer for GEO, especially where structured data accurately mirrors visible content. GEO also depends on content quality, crawlability, authority signals, retrieval fit, and citation behavior beyond schema syntax.
• Companion to Knowledge Graph signals. JSON-LD sameAs is the standard schema.org property for pointing to authoritative profiles representing the same entity (Wikipedia, Wikidata, Crunchbase, LinkedIn); engines may corroborate or ignore it depending on trust signals and consistency across the linked profiles.