Microdata vs JSON-LD vs RDFa: Which Structured Data Format to Use in 2026

You’ve probably seen them: Recipe cards that show directly in search results with star ratings already visible, FAQ sections that expand without ever leaving Google, product prices and availability that just work.

That’s all structured data doing the heavy lifting behind the scenes.

Now, if you’re adding structured data to your own site, you face a choice immediately: Microdata, JSON-LD, or RDFa?

I’ve implemented all three across different projects. I think most developers would overthink this decision. I almost did. They’ll draft a Microdata schema, realize it’s getting nested and ugly halfway through, then spend weeks wondering if they should’ve used RDFa instead. I am guilty of this myself.

Spoiler: they should’ve started with JSON-LD.

The short answer is that JSON-LD probably wins for most use cases in 2026, but the real answer depends on your stack, your existing codebase, and what you’re trying to achieve.

tip

If you’re new to structured data entirely, start with my Ultimate SEO Checklist for Web Developers for the bigger picture before diving into format specifics.

What Is Structured Data and Why Should You Care?

Well, if you don’t know this, you probably haven’t read my series on SEO for developers, so I’ll give you the TL;DR:

Structured data tells search engines what your content means, not just what it says. That powers rich results (FAQ cards, star ratings, breadcrumbs) which can 2-3x your click-through rate. Here’s how it works..

When Google crawls a page and finds the text “Rishi Chawda,” it sees a string. When it finds that string wrapped in a Person schema with properties like jobTitle and url, it understands that this is information about a specific person.

By the way, that’s a really cool name. The person with this name must be super cool, right?

Alright, alright. So what’s the payoff? Rich results.

Structured data is what powers those enhanced search listings: FAQ dropdowns, star ratings, recipe cards, event details, breadcrumb trails, and more. Pages with rich results consistently see higher click-through rates than plain blue links.

Here’s the thing though: structured data is not a direct ranking factor. I know how someone might think it helps but Google has been clear about this. It won’t move you from page 5 to page 1.

But if you’re already ranking, rich results can double or triple your CTR (click through ratio), and that kind of user engagement does send positive signals.

Three formats exist for marking up structured data on the web:

1. Microdata — HTML attributes woven into your existing markup
2. JSON-LD — a JSON script block separate from your HTML
3. RDFa — HTML attributes similar to Microdata but from a different specification

All three use Schema.org vocabulary. All three are supported by Google. But they work very differently in practice.

The Three Formats at a Glance

Quick version (table below), or keep reading for the full story:

The table tells most of the story, but let’s look at each format properly.

Microdata: Structured Data Woven Into HTML

Microdata uses three core HTML attributes to embed structured data directly into your page elements:

• itemscope — declares that this element contains a structured data item
• itemtype — specifies the Schema.org type (e.g., https://schema.org/Person)
• itemprop — assigns a property name to the element’s content

Here’s a Person schema marked up with Microdata:

<div itemscope itemtype="https://schema.org/Person">
  <h1 itemprop="name">Rishi Chawda</h1>
  <p itemprop="jobTitle">Principal Software Engineer</p>
  <a itemprop="url" href="https://rishikc.com">
    rishikc.com
  </a>
  <p itemprop="description">
    Software engineer focused on web performance
    and developer tooling.
  </p>
</div>

The advantage here is transparency: the structured data is tied directly to the visible content. What the user sees is exactly what the search engine reads. There’s no risk of the structured data saying one thing while the page shows another (which Google really doesn’t like).

When Microdata makes sense:

• Legacy sites where adding a <script> block isn’t practical
• Cases where you want a guaranteed 1:1 match between visible content and structured data
• Simple schemas with few properties

Where Microdata gets painful:

• Complex schemas that require nesting. Marking up an Article with an author who has their own Person schema, published by an Organization with a logo.. the HTML gets deeply nested and honestly becomes a maintenance nightmare
• Any redesign or structural change to your HTML requires updating the Microdata too. Your front-end team changes the layout, and suddenly your structured data breaks
• Multiple schemas on one page means Microdata attributes scattered everywhere, making it hard to debug and update

bonus

I wrote a comprehensive implementation guide for Microdata and Microformats in my article on Microdata & Microformats: Essential SEO Markup.

JSON-LD: Structured Data Decoupled From HTML

JSON-LD (JavaScript Object Notation for Linked Data) takes a fundamentally different approach. Instead of weaving attributes into your HTML, you write the structured data as a JSON object inside a <script> tag:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Rishi Chawda",
  "jobTitle": "Principal Software Engineer",
  "url": "https://rishikc.com",
  "description": "Software engineer focused on web performance and developer tooling."
}
</script>

Same data, completely different approach. The JSON-LD block lives in your <head> (or anywhere in the <body>), separate from your visual markup. Your HTML stays clean, and the structured data stays organized.

This is why Google explicitly recommends JSON-LD. Let me quote their documentation directly:

“Google recommends using JSON-LD for structured data whenever possible.”

When JSON-LD makes sense (which is most of the time):

• New sites where you’re starting fresh
• Any site where you control the <head> or layout templates
• Complex schemas with deep nesting (Article → Author → Organization)
• Sites using static site generators like Astro, Next.js, or Hugo
• When you want to add structured data without touching existing HTML

Where JSON-LD requires caution:

• The data in your JSON-LD must match what’s visible on the page. Google has penalized sites where the structured data claimed things the page didn’t show (like fake reviews or prices)
• If your JSON-LD is generated dynamically and something breaks, users won’t notice but your rich results will disappear

For most developers reading this, JSON-LD is the right call. Period.

bonus

For a deep dive into JSON-LD implementation with Schema.org, check out my complete JSON-LD structured data guide.

RDFa: The Third Option

RDFa (Resource Description Framework in Attributes) is the third format, and honestly, it’s the one you’ll encounter least in the wild. It works similarly to Microdata, embedding structured data as HTML attributes, but uses different attribute names:

<div vocab="https://schema.org/" typeof="Person">
  <h1 property="name">Rishi Chawda</h1>
  <p property="jobTitle">Principal Software Engineer</p>
  <a property="url" href="https://rishikc.com">
    rishikc.com
  </a>
  <p property="description">
    Software engineer focused on web performance
    and developer tooling.
  </p>
</div>

The key attributes are vocab (instead of itemtype), typeof (instead of itemscope), and property (instead of itemprop).

When RDFa makes sense:

• Drupal sites — RDFa is built into Drupal’s core and used by default
• Government and academic sites that already use RDFa for other linked data purposes
• When you’re already using RDFa Lite and want to keep consistency

When to skip RDFa:

• Basically any other situation. If you’re starting fresh, JSON-LD is simpler. If you need inline markup, Microdata has broader documentation and community support.

I don’t want to be dismissive. RDFa is a perfectly valid format, and Google processes it just fine. But honestly, it occupies a niche that shrinks every year as JSON-LD adoption grows. Unless you have a specific reason, this isn’t the path to take in 2026.

Google’s Official Recommendation

Here’s what Google actually says. From their structured data documentation:

Their pick: JSON-LD. Easier to add, easier to test, no HTML changes needed.

The reality: All three formats get you equal treatment for rich results. Choose based on your stack, not on ranking bonus (there isn’t one).

The flexibility: Mix formats on same page if you want. Go nuts. Google reads them all.

Probably the main reason Google prefers JSON-LD isn’t about search ranking and more about reliability, I think. JSON-LD blocks are self-contained, making them easier for Google’s parsers to extract without dealing with malformed HTML, missing closing tags, or CSS-hidden elements that might affect Microdata/RDFa interpretation.

bonus

One question you might have once you start implementing JSON-LD (and it probably gets searched constantly; I know I have): “Can I load JSON-LD from an external file using <script src>?”

The answer is no, and this is where many developers hit a frustrating wall. Google requires JSON-LD to be inline in the HTML response. That <script type="application/ld+json" src="schema.json"> approach won’t work. The data has to be present in the initial HTML that Googlebot receives.

I get it. This feels like a weird constraint if you’re thinking about modularity and clean code. Looks like Google won’t budge on it though.

Which Format Should You Choose?

Here’s a simple decision framework:

Choose JSON-LD if:

• You’re building a new site
• You want the simplest maintenance path
• You use a static site generator (Astro, Next.js, Hugo, Gatsby)
• You need to add structured data without touching existing HTML
• You want to inject structured data via Google Tag Manager (yes, Google can read GTM-injected JSON-LD)

Choose Microdata if:

• You have an existing site with structured data already in Microdata and it’s working
• You specifically need the visual content to be the same content the schema references
• You’re working with a CMS or template system that makes inline attributes easier than script injection

Choose RDFa if:

• You’re on Drupal (it’s already there)
• You’re in an environment that standardizes on RDFa for linked data purposes

Migrating from Microdata to JSON-LD? You can do it incrementally. Add JSON-LD blocks alongside existing Microdata, verify they work with Google’s testing tools, then remove the Microdata attributes at your own pace. Google handles the overlap gracefully.

Implementing Structured Data in Astro

Since this site runs on Astro, here’s how I handle structured data. Astro’s content collections let you define frontmatter schemas that map directly to JSON-LD output. In my layout component, I generate the JSON-LD block from the article’s frontmatter:

---
const { title, description, date, dateModified } = Astro.props;
const jsonLd = {
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": title,
  "description": description,
  "datePublished": date,
  "dateModified": dateModified || date,
  "author": {
    "@type": "Person",
    "name": "Rishi Chawda",
    "url": "https://rishikc.com"
  }
};
---
<script type="application/ld+json" set:html={JSON.stringify(jsonLd)} />

This approach keeps my structured data DRY (don’t repeat yourself). When I update an article’s publication date, the JSON-LD updates automatically. No hunting down scattered HTML attributes. No risk of them getting out of sync. The structured data lives in the template logic, completely separated from the article content.

bonus

For more on how I built this site with Astro, including content collections and performance optimizations, check out Rebuilding My Site with Astro.

Testing and Validation

No matter which format you choose, always validate your structured data before deploying. The tools are the same regardless of format:

1. Google Rich Results Test — the gold standard. Shows you exactly which rich results your page is eligible for and flags any errors. Available at search.google.com/test/rich-results.

2. Schema Markup Validator — the official Schema.org validator at validator.schema.org. More thorough than Google’s tool for catching schema violations, but doesn’t tell you about rich result eligibility.

3. Chrome DevTools — for a quick check, open DevTools, go to Elements, and search for application/ld+json (for JSON-LD) or itemscope (for Microdata). Useful for debugging live pages.

4. Google Search Console — after deployment, the Enhancements section shows which structured data types Google has detected and any issues it encountered across your site.

A common workflow: validate with the Rich Results Test during development, deploy, then monitor Search Console for any crawl-time issues that didn’t show up in testing.

Common Mistakes to Avoid

After implementing structured data on multiple sites, here are the mistakes I see most often. I learned some of these the hard way:

1. Mismatched data. I once had a client’s JSON-LD claim a product price while the page showed something different during a promotion. Google penalized the structured data hard. Your JSON-LD says the article was published on January 1st, but the page shows March 15th. Google notices, and it can hurt you.

2. Missing required fields. Each Schema.org type has required properties for rich result eligibility. An Article without headline and datePublished won’t trigger rich results even if the rest is perfect.

3. Stuffing schemas with irrelevant data. Adding Product schema to a blog post or LocalBusiness to a personal portfolio. Use the schema that matches your actual content.

4. Forgetting to update. Structured data that was accurate two years ago might reference a role you no longer hold or a price that’s changed. Treat it like any other content.

5. Not testing after CMS updates. I’ve seen CMS plugins break structured data output silently after updates. Add schema validation to your deployment checklist.

bonus

For a deeper look at how link attributes interact with SEO and structured data, see my article on Link Juice, Nofollow & Link Balancing.

The Bottom Line

In 2026, JSON-LD is the safest default for structured data on any new project. Google recommends it, the tooling supports it, and it keeps your HTML clean. For most developers, that’s the whole answer.

But Microdata and RDFa aren’t going anywhere from what it looks like. If they’re already working on your site, there’s no urgent need to migrate. If your CMS uses one natively, work with it rather than against it.

What matters most isn’t the format. It’s that you’re using structured data at all. A well-implemented Microdata schema beats a nonexistent JSON-LD block every time.

Pick one format and start with the schema types that get you rich results (Article, FAQPage, BreadcrumbList). Validate everything, ship it, then monitor Search Console. Expand to more schema types as you see results.

Happy building!

This article is part of my series on Search Engine Optimization for Web Developers. For deeper dives into specific formats, check out Microdata & Microformats: Essential SEO Markup and JSON-LD Structured Data: Complete SEO Guide.