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

You’ve probably seen them: breadcrumb trails that clean up a messy URL, article details that make a result easier to scan, 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.

Yes, 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 What is JSON-LD? A Beginner’s Guide first. This article is the decision guide once the basics are clear.

What Is Structured Data and Why Should You Care?

Structured data gives machines a clearer description of what a page represents.

On Google Search, some supported types can make a page eligible for richer presentations such as breadcrumbs, article details, product information, or event details.

That does not mean every valid schema becomes a visible rich result. It also does not turn structured data into a ranking shortcut.

The practical benefit is simpler:

• clearer entity and page-type signals
• a cleaner path to supported search enhancements when the content qualifies
• easier maintenance when you pick a format that fits your stack

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’s current structured-data docs recommend JSON-LD when your setup allows it.

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(opens in new tab):

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

The reality: Google supports all three formats for supported structured-data features. Choose based on your stack and maintainability, not on a format-specific ranking bonus (there isn’t one).

The flexibility: You can mix formats on the same page, but consistency is usually easier to maintain and debug.

Google’s recommendation toward JSON-LD is best understood as a maintainability choice. A self-contained JSON-LD block is usually easier to generate, test, and update without touching your HTML structure.

bonus

The safest deployment pattern is to render JSON-LD inline in the HTML your page returns. However you generate it internally, the important part is that the final rendered page contains the markup Google can crawl.

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 one structured-data block generated from the same source data as the page

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(opens in new tab).

2. Schema Markup Validator — the official Schema.org validator at validator.schema.org(opens in new tab). 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, use URL Inspection, search appearance data, and any feature-specific reports that apply to your markup.

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. Confusing Schema.org validity with Google feature requirements. Some supported Google features have required or recommended properties. Valid Schema.org alone is not the same thing as current Google feature eligibility.

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 still the safest default for most new projects because it is easier to implement and keep in sync. Microdata is still fine when inline HTML is the practical fit. RDFa is valid, but usually a niche choice.

What matters most is not chasing a format war. It is choosing the format your stack can keep accurate, then using current Google docs to decide which types are worth implementing.

Start with types that match real, visible content and still have current Google documentation, such as Article, BreadcrumbList, Product, or Event when they genuinely fit the page. Be careful with older FAQPage and sitelinks-search-box advice you still see floating around the web.

Happy building!

This article is part of my structured-data cluster. If you want the foundations first, continue with What is JSON-LD?, JSON-LD Examples, Schema.org for Developers, and the dedicated HTML Microdata Tutorial.