Beyond a data format: a contract with the entity graph
JSON-LD stands for JSON for Linking Data, a W3C Recommendation since 2014 and updated to 1.1 in 2020. That is the dictionary line, and it is the least useful thing to know about it. What matters operationally is that JSON-LD is the channel through which you tell Google, in a structured vocabulary it already understands, what each page is: an article, a product, a local business, a person, an organization. It is less a format than a declaration of identity that feeds the knowledge graph sitting behind Search.
The reason it won the format war is purely architectural. Microdata and RDFa weave attributes into your visible HTML, so every redesign risks shredding your markup. JSON-LD lives in its own <script type="application/ld+json"> block, completely decoupled from the DOM your users see. You can rewrite your entire front end and leave the structured-data layer untouched, or vice versa. Google made its preference explicit in Search Central documentation years ago, and nothing since has reversed that. When we audit a site still running Microdata on a 2018 template, the recommendation is almost always the same: migrate to JSON-LD and stop fighting your own HTML.
The right mental model is a contract. Your structured data layer states claims about the page, and Google decides how much of that claim it trusts and surfaces. The vocabulary for those claims comes from the shared schema.org vocabulary, a collaborative spec backed by Google, Microsoft, Yahoo and Yandex. JSON-LD is the syntax; schema.org is the dictionary it speaks.
Syntax and mechanics: context, type, properties
A JSON-LD block has three load-bearing parts. The @context tells the parser which vocabulary you are using, almost always https://schema.org. The @type declares what the object is, for example Article or Product. Everything else is properties: key-value pairs drawn from that type's allowed fields. That is the whole grammar, and its simplicity is exactly why it scales across a network of sites.
Here is the canonical shape for an article, the example every implementation starts from:
{ "@context": "https://schema.org", "@type": "Article", "headline": "...", "author": { "@type": "Person", "name": "..." }, "publisher": { "@type": "Organization", "name": "..." }, "datePublished": "2026-01-12" }
The short video below walks through that core markup if you want it spelled out property by property.
Two mechanics matter beyond the basics. First, nesting: an Article can embed a Person as its author and an Organization as its publisher, each a typed object in its own right. Second, the @id property, which lets you give an entity a stable identifier and reference it across pages so Google understands that the «author» on a hundred articles is one and the same person. That second mechanic is invisible to beginners and decisive for anyone building topical authority at scale.
Where to put it and how to render it
Placement is the question that trips up most teams. JSON-LD can sit in the <head> or anywhere in the <body>; Google reads it either way and has said so repeatedly. The real decision is not where in the HTML but how it gets there. This video shows the placement choices in a real page if you prefer to see it in context.
Server-side rendering is the only setup we trust in audits. When the JSON-LD is in the raw HTML response, you know Googlebot has it the moment it fetches the page. Client-side injection, where JavaScript writes the script tag after load, depends entirely on Google rendering your JS. Googlebot does render, but rendering is a second, deferred pass with its own queue, and on large sites that delay is real. If your structured data only exists after hydration, you are betting your rich-result eligibility on a render budget you do not control. For a content network pushing pages through a CMS, generate the markup on the server. Frameworks like Next.js make this trivial with server-side data fetching, and a Yoast or Rank Math install on WordPress will output a connected @graph server-side without you touching code.
One honest caveat: a plugin-generated @graph is correct but generic. It declares the bare minimum. If you want author entities, sameAs links and precise types, you will be hand-authoring or extending the plugin output. There is no format magic that replaces deciding what you want to claim.
The schemas that actually earn something in 2026
Not all schema types pull the same weight, and this is where most glossary articles lie by omission. Let me be blunt about what each one buys you. The clip below runs through a couple of the common types in JSON-LD form.
Product markup still earns real estate: price, availability and review stars in the SERP, and it feeds Google's shopping surfaces. For e-commerce it is non-negotiable. Article markup rarely produces a visible flourish on its own, but it clarifies authorship, publish date and publisher, which matters for Top Stories eligibility and for entity attribution. BreadcrumbList reliably replaces the raw URL in the result line, a small but free clarity win. Organization and LocalBusiness feed the knowledge panel and, for local, the map pack context.
Then there is the FAQPage type, which deserves a correction. Google rolled back FAQ rich results in August 2023, restricting them to authoritative government and health sites, and similarly curbed HowTo. If a consultant is still selling you FAQ markup as a way to «grab more SERP space», they are quoting a 2021 playbook. Mark up your FAQs for entity and answer clarity, which still feeds AI-generated answers, but do not expect the accordion stars. That is the 2026 reality versus the legacy assumption, and pretending otherwise is how clients lose trust.
Where JSON-LD goes wrong in audits
The most damaging error is also the most common: markup that describes content not visible on the page. Declaring a review rating that no user can see, or an author who appears nowhere, is a documented structured-data guidelines violation, and Google will issue a manual action or silently drop eligibility. Structured data must mirror what is on the page, full stop.
The second pattern is copy-paste rot. A team grabs a sample Article block, ships it across the site, and forgets to template the headline and datePublished, so every page claims the same title and date. The Rich Results Test will pass it as valid JSON while the data is nonsense. Validity is not correctness, and tools only check the former.
Third, leaving generator defaults in place: a plugin outputs "publisher": { "name": "Your Site Name" } placeholder logos, broken logo URLs, missing image dimensions. These throw warnings in Search Console's enhancement reports that quietly cap your rich-result eligibility. Fourth, and increasingly, JS-injected markup that never renders for Googlebot, the failure mode described above. When a page «has schema» in the source but Search Console reports zero detected items, render is almost always the culprit. The fix workflow is unglamorous: validate with the Rich Results Test, cross-check the URL Inspection rendered HTML in Search Console, and reconcile the two.
Why it matters for a netlinking operation
For anyone running link campaigns, the interesting JSON-LD is not Product or FAQ, it is the entity layer. Consistent Organization, Person and author markup, tied together with sameAs pointing to verified profiles, is how you tell Google that a publisher and its authors are real, stable entities rather than a disposable PBN footprint. We operate Stringer as a network of owned French media, and structured-data consistency across those properties is part of what makes each publisher legible as a legitimate source, not anonymous link inventory. That is an operational use of schema, not a ranking trick.
The forward-looking angle is AI visibility. Structured data is one of the cleaner signals LLM-powered answer engines use to extract facts about entities, so the same Article and Organization markup that does little for classic rich results is becoming load-bearing for getting cited in AI answers. If your goal is to make your entities legible to AI answer engines, schema is part of the groundwork. And when the value of a backlink increasingly depends on the source being a recognized entity, it pays to place links directly with publishers whose identity Google already trusts, structured data included. The format is plumbing; the entity strategy on top of it is the actual lever.