JSON-LD vs Microdata vs RDFa: Which Schema Format Should You Use?

Updated on March 2, 2026

If you've spent any time digging into structured data, you've probably hit a wall of jargon pretty fast. JSON-LD, Microdata, RDFa — they all promise to help search engines understand your content better, but picking the wrong one can mean hours of cleanup later. I've implemented all three across different projects, and the differences are sharper than most comparison guides admit. Let's cut through the noise.

The Core Problem They're All Solving

Search engines are remarkably good at reading text, but terrible at context. When your page says "4.5 stars, 238 reviews," Google doesn't automatically know that's a product rating versus a movie score versus a restaurant review. Structured data is the layer you add to tell it exactly what's what — and earn those rich results (star ratings, FAQs, event dates, breadcrumbs) in the SERPs.

All three formats use the same underlying vocabulary from Schema.org. The difference is purely in how you encode that vocabulary into your page. Think of it like writing the same address in English, French, or Spanish — same information, different expression.

Microdata: The Inline Approach That Made Sense in 2011

Microdata was HTML5's official answer to structured data. You annotate your existing HTML using attributes like itemscope, itemtype, and itemprop — right inside your content markup.

Here's what a simple product snippet looks like in Microdata:

<div itemscope itemtype="https://schema.org/Product">
  <span itemprop="name">Wireless Keyboard</span>
  <div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
    <span itemprop="price">49.99</span>
    <span itemprop="priceCurrency">USD</span>
  </div>
</div>

The appeal is obvious: your structured data lives right alongside the content it describes. No duplication, no separate block to maintain. In theory, this is elegant.

In practice? It's a nightmare to maintain at scale. Every time a designer restructures the HTML for visual reasons — wrapping a heading in a new div, splitting a paragraph, refactoring a component — there's a real chance of breaking the schema hierarchy. The itemscope/itemprop chain is fragile. Miss a closing tag in the wrong place and your entire product schema silently breaks. You won't know until your rich results disappear.

Google still supports Microdata, but they've been clear for years that it's not their preferred format. Google Search Central's own documentation leads with JSON-LD in every example.

RDFa: Powerful, Academic, and Extremely Verbose

RDFa (Resource Description Framework in Attributes) predates both Microdata and JSON-LD. It comes from the semantic web world — a W3C standard designed for maximum expressiveness and interoperability. If Microdata is a hammer, RDFa is a Swiss Army knife that also happens to be a wrench, a spectrometer, and a philosophy dissertation.

Same product, in RDFa:

<div vocab="https://schema.org/" typeof="Product">
  <span property="name">Wireless Keyboard</span>
  <div property="offers" typeof="Offer">
    <span property="price">49.99</span>
    <span property="priceCurrency">USD</span>
  </div>
</div>

Cleaner than Microdata syntactically, but same core problem: it's embedded in your HTML. Worse, RDFa has multiple versions (RDFa Core, RDFa Lite, RDFa 1.1) and the attribute names shift depending on which subset you use. I've seen developers mix these up across a single project. Debugging that is genuinely miserable.

RDFa shines in very specific contexts — academic publishing, government data portals, linked data applications where the full power of RDF triples matters. For everyday SEO work? It's overkill in the worst way: more complexity, same result.

Google's crawlers handle RDFa, but again — it's not what their tools are optimized to test against. The Rich Results Test and Schema Markup Validator both feel most reliable with JSON-LD.

JSON-LD: Why Google Recommends It (And Why They're Right)

JSON-LD (JavaScript Object Notation for Linked Data) takes a completely different approach. Instead of annotating your HTML, you drop a single <script> block — typically in the <head> — containing all your structured data as a clean JSON object.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wireless Keyboard",
  "offers": {
    "@type": "Offer",
    "price": "49.99",
    "priceCurrency": "USD"
  }
}
</script>

That's it. Your HTML stays completely untouched. The structured data is self-contained, human-readable, and trivially easy to validate with a quick JSON linter before you even push to production.

The separation of concerns here isn't just aesthetically pleasing — it has real practical consequences:

  • Frontend changes don't break your schema. A designer can completely gut and rewrite the HTML template. Your JSON-LD block remains unaffected.
  • Injecting via CMS or GTM is straightforward. WordPress, Shopify, and most CMS platforms have JSON-LD plugins that work reliably. You can also inject it via Google Tag Manager for pages you can't touch directly.
  • Nested structures are readable. Complex schemas — a Recipe with NutritionInformation inside an HowToStep inside multiple HowToSection items — are actually parseable as JSON-LD. Try doing that in Microdata without losing your mind.
  • Errors are catchable before deployment. Invalid JSON throws immediately. Malformed Microdata can sit silently broken for weeks.

Google made their position official in 2016 when they explicitly recommended JSON-LD as the preferred format. Since then, every new schema type Google has introduced — Speakable, FAQPage, How-To, Product with Review snippets — has been documented primarily in JSON-LD. Some features, like Speakable for Google Assistant, are only documented with JSON-LD examples.

Head-to-Head: The Practical Scorecard

Let's put this side by side without euphemism:

Ease of Implementation
JSON-LD wins clearly. You write one block of JSON, validate it, paste it in. With Microdata and RDFa, you're threading attributes through HTML you may not have full control over. On a WordPress site with a complex page builder? Microdata becomes a scavenger hunt through generated markup.

Maintainability
JSON-LD wins again. Schema updates mean editing one JSON block. Microdata and RDFa updates mean hunting for the right HTML element amid whatever else changed in the template since you last touched it. On a team where developers and designers both touch the same HTML, Microdata is a liability.

Separation of Concerns
JSON-LD is the clear winner. The content team owns the HTML; the SEO team owns the JSON-LD block. No stepping on each other's work. With inline formats, any HTML refactor is potentially a schema emergency.

Google Support
JSON-LD wins, and it's not close. Google's tools, documentation, and new feature rollouts all prioritize JSON-LD. Bing also supports it well. Microdata and RDFa are supported, but treated as legacy formats in practice.

Rendering Dependency
This is the one area where JSON-LD has a nuance worth understanding: since it's often injected via JavaScript, you need to verify that Google's crawler can see it. If you're server-side rendering, no problem. If you're injecting via GTM or a client-side script, test explicitly in Google Search Console's URL Inspection tool. Microdata and RDFa, being native HTML attributes, don't have this concern — but it's a minor tradeoff given everything else JSON-LD offers.

When Would You Actually Choose Microdata or RDFa?

Honestly? Almost never, for SEO purposes. The edge cases that might push you toward them:

  • You're building a highly specialized semantic web application where RDF interoperability genuinely matters beyond Google
  • You're working in a legacy CMS that has locked-down templates with Microdata already baked in and the migration cost outweighs the benefit
  • An academic or government publishing context where linked data standards require RDFa specifically

For a blog, e-commerce site, SaaS marketing page, local business site, or news publication — JSON-LD every time.

Getting Started with JSON-LD the Right Way

A few things I've learned from implementing this at scale:

Always validate before deploying. Google's Rich Results Test and the Schema Markup Validator are your friends. Don't rely on "it looked fine in the text editor."

Use @context correctly. It should be https://schema.org (with HTTPS), not the old HTTP version, and not the full URL with a trailing slash in some cases. Small errors here can cause silent failures.

Stack multiple schemas when needed. You can have more than one <script type="application/ld+json"> block per page, or use a @graph array to combine them. An article page might have a BreadcrumbList, an Article schema, and an Author Person schema all together.

Match your schema to what's visible on the page. Google's guidelines are explicit: don't mark up content that isn't actually present to users. A rating schema with no visible stars is a policy violation, not a clever hack.

The Bottom Line

The structured data format debate was genuinely open around 2012-2014. Today, it's settled. JSON-LD is what Google wants, what developers can maintain without incident, and what every major SEO tool is optimized to test. Microdata had its moment; RDFa serves a niche beyond SEO. For the vast majority of web projects, choosing anything other than JSON-LD is choosing technical debt without a corresponding benefit.

Pick JSON-LD, implement it cleanly, validate it rigorously, and spend the time you save on actually building out the schema types that earn rich results — rather than debugging why a misplaced itemprop attribute silently broke your product ratings three deploys ago.