JSON-LD

What JSON-LD really is, past the script tag

JSON-LD stands for JSON for Linking Data, a W3C recommendation, and in a working SEO context it is the block of machine-readable data you drop inside a <script type='application/ld+json'> tag to tell Google, Bing and now the generative engines what the entities on a page are and how they relate. To settle the question every developer asks first: yes, it is valid JSON, so any parser reads it without complaint. The interesting part is the LD.

Ordinary JSON is a bag of keys and values with no shared meaning. The @context key is what turns that bag into linked data: it maps your property names to a public vocabulary, in practice almost always schema.org, so that name, author or datePublished resolve to a definition a search engine already holds. That is also the honest answer to the JSON-LD versus RDF question. JSON-LD is a concrete serialization of the RDF data model. It carries the same subject, predicate, object graph semantics, but in a syntax a JavaScript developer reads on sight instead of the angle-bracket soup of RDF/XML.

This short explainer frames the concept cleanly before we get operational:

The practical mental model: a web page carries content for humans in HTML and a parallel description of the same facts for machines in JSON-LD. The two must agree. When they do, the format quietly does its job across regular Search, Discover, Bing, and the answer engines. When they disagree, you have built a liability, not an asset.

Why JSON-LD matters more in 2026, not less

The legacy assumption is that schema equals rich snippets, so if a snippet disappears, the markup was wasted effort. That framing is now wrong. Google fully retired FAQ rich results from the main Search results on May 7, 2026, with support in the Rich Result Test and Search Console reporting removed through early 2026 (Google Search Central). Practice problem structured data was deprecated effective January 2026. If your only reason for schema was the visual snippet, half your library just lost its point.

Yet Google still recommends keeping FAQPage JSON-LD for semantic understanding, and that phrasing is the whole story. The value migrated from decorating the SERP to helping machines understand and cite your content. A Search Engine Land controlled test in September 2025 put three near-identical pages online: only the one with well-implemented JSON-LD was included in a Google AI Overview, and the page with no schema did not even index. That single result is why 2026 schema playbooks treat structured data as an AI visibility input, not a snippet lottery ticket.

The distribution shift backs it up. An Ahrefs study of 863,000 SERPs and 4 million AI Overview URLs (February 2026) found only 38% of AI Overview citations came from pages ranking in the top-10 organic results, down from 76% in mid-2025. Read that carefully: classic authority is losing its grip on who gets cited, and machine-readable entity data is one of the levers filling the gap. On the volume side, a Semrush study of 10 million URLs found pages using Article and FAQPage schema appeared in 2.3 times more featured snippets and AI Overview citations than pages without them, and a Milestone analysis of 4.5 million queries recorded a rich result being clicked 58% of the time versus 41% for a standard result. None of those are guarantees, but they are the numbers you cite when someone asks whether the format still earns its keep. This is exactly why we treat structured data as part of the same job as making a page legible to the engines that now write the answers, not a separate technical chore bolted on at the end.

The syntax that actually matters: @context, @type, properties

Strip a JSON-LD block to its skeleton and there are two keys that carry the weight. @context declares the vocabulary, usually https://schema.org. @type declares what kind of thing you are describing, an Article, a Product, an Organization. Everything after that is properties: headline, author, image, offers, and their expected data types. The format supports nested objects, so an Article can hold an author object that is itself a Person, and a Person can hold their own properties. That nesting is where the graph lives.

This walkthrough reinforces the structure with visual examples:

The operational depth that separates a clean implementation from a messy one lives in three habits. First, use @graph to place several entities in one block and connect them by @id instead of repeating the same Organization object on every template. Second, define your Organization and WebSite entities once, reference them everywhere by @id, and let the graph resolve. Third, match every property to real, visible content. Google reads JSON-LD as claims about the page, and a claim with no on-page evidence is at best ignored. If you want the underlying concept in depth, our entry on the broader family of structured data formats covers how these signals feed the knowledge graph beyond a single markup type. Validate templates, not individual URLs, with the Rich Results Test and the Schema Markup Validator: one bad template poisons thousands of pages, one bad page rarely matters.

JSON-LD vs Microdata vs RDFa: the argument is over

Three formats can express schema.org: Microdata and RDFa weave attributes directly into your HTML tags, while JSON-LD sits in its own script block, decoupled from the markup. Google recommends JSON-LD, and in 2026 that recommendation has hardened into consensus for a simple engineering reason. A separate block can be generated server-side, injected through a tag manager, or templated without surgery on the visible DOM. Microdata and RDFa force you to edit the same HTML your designers touch, which makes them brittle and expensive to maintain at scale.

This comparison lays out the trade-off directly:

Our stance, from what we see in audits: there is no defensible reason to ship Microdata or RDFa for a new build. The only situation where inline markup earns a second look is a legacy platform where the visible content and the markup are already tightly coupled and a rewrite is not funded. Otherwise, JSON-LD wins on readability, maintenance, and the fact that it is the format Google actively documents and expands. The one caveat that survives the format war applies to all three equally: the markup has to describe what is on the page. Decoupling is a maintenance convenience, not a license to invent facts. If you are naming an entity that has its own definition, our note on the shared vocabulary that gives these types meaning explains why the @type you choose has to exist in that spec to be understood.

Where we see JSON-LD go wrong

The failures cluster into a short list. The most damaging is schema that describes content not present on the page: a Review block with no review, a Product with prices the user never sees. Google treats that as spam and can apply a manual action. The most wasteful is deploying markup for a feature that no longer exists, most often teams still shipping FAQPage expecting the retired expandable snippet, or PracticeProblem after its January 2026 deprecation. The markup is not illegal, it just buys nothing on the SERP anymore, so budget it against AI comprehension only, not clicks.

A quieter mistake is misreading which schema types actually earn a Search reward. Google clarified in late 2025 that Dataset structured data is used only by Dataset Search, not standard Google Search, so a site marking up datasets and expecting normal SERP features is optimizing for a surface that will never render them. On the technical side, orphan @id references that point to entities defined on another template, and Organization blocks silently duplicated on every URL, are the two errors we flag most often. They rarely throw a validation error, which is exactly why they survive to production.

The tactical takeaway for a working SEO is to treat JSON-LD as an entity layer, not a snippet hack. Ship Organization, WebSite, and BreadcrumbList sitewide, add Article or Product per page type, keep every claim tied to visible content, and re-validate the template on each deploy. In a netlinking operation, that discipline matters because the pages you point links at should be the ones the answer engines can parse and cite, which is the same logic behind treating coverage across the models that surface entities as a distribution channel of its own. Clean structured data does not replace authority, it makes the authority you already have machine-legible, and in a search landscape where citation and ranking are drifting apart, that legibility is no longer optional.