Technical SEO

What Is JSON-LD? The Structured Data Format Google Recommends

By Alex·2026-07-12·8 min read

Key Takeaways

JSON-LD is a structured data format that lives in a standalone <script> block — completely separate from your page HTML
Google explicitly recommends JSON-LD over Microdata and RDFa for most schema types
Unlike inline formats, JSON-LD supports @id and sameAs — properties that link entities across pages into a knowledge graph
Adding or removing JSON-LD never touches your HTML templates — it survives redesigns, CMS migrations, and front-end rewrites

A development team spends three weeks adding Microdata to 400 product pages. Every <span>, <div>, and <meta> element gets an itemprop attribute hand-coded into the template. One month later, the front-end team ships a redesign. New templates overwrite every modified element. Three weeks of structured data work — gone in a single deploy.

That scenario happens on real production sites. JSON-LD (JavaScript Object Notation for Linked Data) avoids it entirely. Instead of weaving schema attributes into your HTML elements, JSON-LD wraps all structured data in a standalone <script type="application/ld+json"> block. The block sits in your page's <head> or <body>, untouched by any HTML change. Google Search Central calls it the recommended format — and the reason is practical, not theoretical.

JSON-LD Keeps Structured Data Separate From Your HTML

Structured data tells search engines what a page represents in machine-readable terms: this page describes a LocalBusiness at 123 Main St with a 4.8-star rating. Before JSON-LD, the only way to communicate this was Microdata — adding itemscope, itemtype, and itemprop attributes directly onto existing HTML elements. Every piece of data had to be attached to a visible element on the page.

Microdata weaves schema attributes into your presentation layer:

<!-- Microdata: coupled to HTML structure -->
<div itemscope itemtype="https://schema.org/LocalBusiness">
  <h1 itemprop="name">Sunrise Bakery</h1>
  <p itemprop="address" itemscope
     itemtype="https://schema.org/PostalAddress">
    <span itemprop="streetAddress">123 Main St</span>,
    <span itemprop="addressLocality">Portland</span>
  </p>
</div>

JSON-LD expresses the same information as a self-contained block. No attributes on HTML elements. No coupling between data and presentation:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Sunrise Bakery",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main St",
    "addressLocality": "Portland"
  }
}
</script>

When a front-end redesign ships, the Microdata version breaks — every itemprop attribute disappears with the elements they were attached to. The JSON-LD block survives unchanged. On large sites with hundreds of templated pages, this decoupling means schema changes require editing one script block or one server-side injection point — not every template partial across the codebase.

This separation has a second benefit: JSON-LD can be injected without template access. A marketing team can add Organization schema through Google Tag Manager using a Custom HTML tag — no engineering ticket required. A CMS plugin can inject Product schema server-side without modifying the theme. Microdata requires direct access to the HTML templates that render each element, which typically means a developer for every schema change.

Medium severity
Structured Data
Missing JSON-LD Organization Schema
No Organization structured data found. Google uses this to populate Knowledge Panels and verify entity identity across search results.
Paste-ready fix
<script type="application/ld+json">
{ "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#org",
  "name": "Your Business",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png" }
</script>
Structured data audit checks 30+ schema types per page. See a full report →

Why Google Recommends JSON-LD Over Microdata and RDFa

Google Search Central states it directly: "Google recommends using JSON-LD for structured data whenever possible." Three technical properties drive the preference.

First, JSON-LD eliminates nesting errors. Microdata requires correct parent-child relationships between HTML elements — an itemprop="address" must sit inside the itemscope of the correct entity. Refactor one <div> and the schema silently breaks. JSON-LD uses standard JSON nesting, and any JSON validator catches structural errors instantly. Second, certain rich result types only accept JSON-LD. Google's structured data gallery shows that types including HowTo, FAQ, and several others require JSON-LD format exclusively. Third, JSON-LD is the only format that supports dynamic injection through tag managers and server-side rendering pipelines without modifying the page template.

Feature	JSON-LD	Microdata	RDFa
Where it lives	Standalone `<script>` block	Inline attributes on HTML elements	Inline attributes on HTML elements
Survives redesigns	Yes — decoupled from HTML	No — deleted when elements change	No — same risk
Tag Manager injection	Yes — Custom HTML tag	Not possible	Not possible
`@id` entity linking	Full support	Not supported	Limited
Google preference	Recommended	Supported, not preferred	Supported, not preferred
Nesting error risk	Low — JSON validators catch errors	High — tied to DOM structure	High — tied to DOM structure

RDFa deserves a brief mention. It functions like Microdata — inline attributes on HTML elements — but uses a different vocabulary (typeof, property instead of itemscope, itemprop). It shares the same fragility: any HTML change can break the data. RDFa is still supported by Google but sees declining adoption. The practical choice in 2026 is between JSON-LD and Microdata, and the evidence points clearly toward JSON-LD.

Entity Linking With @id and sameAs

Microdata and RDFa describe entities on individual pages. JSON-LD does something they cannot: it links entities together using @id, a property that assigns each entity a unique identifier that other JSON-LD blocks — on the same page or across your site — can reference by URI.

Consider a business website. The homepage defines an Organization. The Contact page describes a ContactPoint. Product pages list items sold by the Organization. Without @id, each page's structured data is an island. Google infers that the Organization on page A is probably the same one on page B, but "probably" is not "definitely."

With @id, the connection is explicit:

<!-- Homepage: define the Organization -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#org",
  "name": "Sunrise Bakery",
  "sameAs": [
    "https://www.linkedin.com/company/sunrise-bakery",
    "https://www.facebook.com/sunrisebakery"
  ]
}
</script>

<!-- Product page: reference the Organization -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Sourdough Loaf",
  "manufacturer": { "@id": "https://example.com/#org" }
}
</script>

The Product page's manufacturer field points back to the Organization defined on the homepage via its @id URI. Google does not need to re-parse the Organization's properties — it already has them. The sameAs property extends this further: it tells Google that the Organization on your site is the same entity as the LinkedIn page and Facebook profile at those URLs. This is how structured data evolves from tagging individual pages to building a coherent entity graph that Google uses for Knowledge Panels and AI answers.

If your current implementation uses duplicate Organization blocks on every page with no @id references and no sameAs links, the markup still works for basic rich results. But you are leaving entity disambiguation signals on the table — signals that become increasingly important as AI-powered search relies on entity resolution to decide which sources to cite.

MendMySEO audits JSON-LD across every page of your site — checking for missing @id references, broken entity links, and schema types your pages lack. Join the waitlist.

Frequently Asked Questions

Does JSON-LD slow down page load?

No. The <script type="application/ld+json"> block is not executed by the browser — it is only read by search engine crawlers. A typical JSON-LD block adds 1-3 KB to page weight, which has no measurable impact on load time or Core Web Vitals scores.

Can I use JSON-LD and Microdata on the same page?

Yes. Google can process both formats simultaneously. However, describing the same entity in both formats creates redundancy and increases the risk of conflicting data. Pick one format per entity type — and Google recommends JSON-LD.

Where should I place the JSON-LD script tag?

Google processes JSON-LD in both <head> and <body>. Most implementations place it in <head> for consistency, but <body> works identically — which is why Google Tag Manager injection (appended to <body>) is fully supported.

How do I validate JSON-LD markup?

Use Google's Rich Results Test to check if your markup qualifies for rich results. Use Schema.org's Markup Validator for syntax and vocabulary validation. Both are free and return errors immediately.

Does JSON-LD affect AI search visibility?

Structured data helps AI models understand entity relationships and factual claims on your page. JSON-LD properties like sameAs and @id help AI systems disambiguate your brand from similarly named entities — a prerequisite for accurate citation in AI-generated answers. The signal is indirect but growing in importance as AI search engines increasingly rely on structured entity data.