What is JSON-LD?

JSON-LD (JavaScript Object Notation for Linked Data) is a W3C Recommendation (first published in 2014, updated to JSON-LD 1.1 in July 2020) that encodes linked data using standard JSON syntax. It lets you describe entities — products, articles, organizations, events — in a machine-readable way by embedding a <script type="application/ld+json"> block in your HTML. Google's search documentation explicitly recommends JSON-LD as the preferred format for structured data over Microdata and RDFa. When paired with Schema.org vocabularies, JSON-LD is what triggers rich results like FAQ dropdowns, recipe cards, review stars, and product listings in Google Search. We've shipped JSON-LD on 50+ projects, and it's the single most cost-effective SEO intervention for pages that already have good content but aren't earning SERP features.

How it works

JSON-LD works by injecting a self-contained JSON object into your page's <head> or <body> inside a script tag. The object uses an @context key (almost always "https://schema.org") and an @type key to declare what entity you're describing.

Here's a minimal example for an Article:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "What is JSON-LD?",
  "author": {
    "@type": "Person",
    "name": "Melody Sellers"
  },
  "datePublished": "2026-04-15",
  "publisher": {
    "@type": "Organization",
    "name": "Social Animal",
    "url": "https://socialanimal.dev"
  }
}
</script>

The critical thing to understand: JSON-LD is decoupled from the visible DOM. Unlike Microdata, you don't have to weave attributes into your markup. This makes it trivial to manage in component-based frameworks like Next.js or Astro — you generate the JSON object from your data layer and drop it in the <Head> component.

Google's crawler (Googlebot) parses the JSON-LD at crawl time and at render time (for client-side rendered pages). For server-rendered or statically generated pages, the data is available immediately. For SPAs that inject JSON-LD client-side, Google will still pick it up, but there's a latency risk — we always recommend server-side rendering of structured data.

You can validate your output with Google's Rich Results Test or the Schema Markup Validator (formerly the Structured Data Testing Tool, sunset in 2021 and replaced).

When to use it

JSON-LD should be on essentially every page you want indexed. The question isn't whether to use it — it's which types to apply.

Use JSON-LD when:

You want rich results (FAQ, How-To, Product, Review, Event, Recipe, etc.)
You're building a local business site (LocalBusiness schema drives the knowledge panel)
You're publishing articles or blog posts (Article or BlogPosting)
You need organization-level identity (Organization + sameAs for social profiles)
You're running an e-commerce store (Product, Offer, AggregateRating)

Skip it (or don't overthink it) when:

The page is a thin utility page (login, 404, internal dashboards)
You're tempted to mark up content that doesn't actually exist on the page — Google penalizes misleading structured data
You're adding deeply nested types that Google doesn't actually support for rich results — check Google's search gallery for the real list

JSON-LD vs alternatives

JSON-LD competes with two other structured data serializations:

Feature	JSON-LD	Microdata	RDFa
Syntax	JSON in `<script>` tag	HTML attributes inline	HTML attributes inline
Coupling to DOM	None (decoupled)	Tightly coupled	Tightly coupled
Google's preference	Recommended	Supported	Supported
Ease of maintenance	High — one block, one source	Low — scattered across markup	Low — scattered across markup
Framework compatibility	Excellent (Next.js, Astro, etc.)	Painful in component systems	Painful in component systems
Spec status	W3C Recommendation (1.1, 2020)	W3C Recommendation	W3C Recommendation

Our preferred stack is JSON-LD exclusively. We dropped Microdata from our templates around 2020 and haven't looked back. The decoupled nature of JSON-LD means your content team can't accidentally break structured data by editing HTML, and your engineering team can generate it programmatically from a CMS or database.

Real-world example

On a recent Astro-based e-commerce build, we generated JSON-LD Product schema for 12,000 product pages from a Sanity CMS data source. Each page included Product, Offer, AggregateRating, and Brand types. Within six weeks of deploying, Google Search Console reported a 340% increase in rich result impressions for those pages. The product cards in search showed price, availability, and star ratings — directly attributable to the structured data. Total engineering time for the JSON-LD implementation was about four hours, mostly spent writing a utility function that mapped Sanity fields to Schema.org properties. The ROI on structured data work like this is hard to beat.

Frequently asked questions about JSON-LD

Is JSON-LD the same as Schema.org?

No. JSON-LD is a data format — a way to serialize linked data using JSON syntax. Schema.org is a vocabulary — a shared dictionary of types and properties (like Product, Article, Organization). You use JSON-LD as the container and Schema.org as the language inside it. Think of JSON-LD as the envelope and Schema.org as the letter. You could technically use JSON-LD with vocabularies other than Schema.org, and you could express Schema.org vocabulary using Microdata or RDFa instead of JSON-LD. But in practice, JSON-LD + Schema.org is the dominant pairing for SEO.

When did JSON-LD become the standard for SEO?

JSON-LD became a W3C Recommendation in January 2014. Google began supporting it for rich snippets shortly after, but the real tipping point came in 2017-2018 when Google publicly stated JSON-LD was their recommended format. The JSON-LD 1.1 spec was finalized in July 2020, adding features like `@nest` and improved context handling. By 2020, the SEO community had largely moved away from Microdata in favor of JSON-LD, and most major CMS platforms (WordPress via Yoast, Shopify, etc.) adopted JSON-LD as their default structured data output.

What's the alternative to JSON-LD for structured data?

The two alternatives are Microdata and RDFa. Microdata uses HTML attributes like `itemscope`, `itemtype`, and `itemprop` directly on your markup elements. RDFa uses attributes like `vocab`, `typeof`, and `property`. Both are valid W3C standards and both are supported by Google. The practical problem with both is maintenance: your structured data is tangled into your HTML, which makes it fragile in component-based architectures. If a developer refactors a template, the structured data can silently break. We stopped recommending Microdata or RDFa for new projects years ago.

Can you have multiple JSON-LD blocks on one page?

Yes. Google explicitly supports multiple `<script type="application/ld+json">` blocks on a single page. This is common — you might have one block for Organization, another for BreadcrumbList, and a third for the page-specific type like Article or Product. You can also combine them into a single block using `@graph`, which is an array of entities in one JSON-LD object. We generally prefer separate blocks per component in Next.js and Astro because it maps cleanly to the component architecture — each component owns its own structured data — but both approaches validate identically.