JSON-LD vs Microdata vs RDFa: format choice for 2026

Three formats can deliver the same structured data to Google. The choice between them affects implementation cost, maintenance burden, and whether the markup survives template changes. The right answer in 2026 is clearer than it was a decade ago.

Schema.org markup tells search engines what entities a page describes: a product, an article, a person, a recipe, an event. The vocabulary (schema.org) is the same regardless of how the markup is encoded. The encoding format is the choice: JSON-LD, Microdata, or RDFa.

Google’s official guidance for years has been that all three formats are supported. The practical reality is more pointed. JSON-LD has become the format Google’s documentation recommends first, the format most rich results examples use, and the format most modern CMSs generate by default. Microdata and RDFa still work, but for new implementations, the case for picking either over JSON-LD is narrow.

The three formats:

Format	Where it lives	Visual position
<strong>JSON-LD</strong>	A <!–INLINECODE0–> block, typically in <!–INLINECODE1–>	Hidden from visible page content
<strong>Microdata</strong>	HTML attributes inline on existing elements	Embedded within visible HTML
<strong>RDFa</strong>	HTML attributes similar to Microdata, with RDF vocabulary	Embedded within visible HTML

The visual difference matters. JSON-LD is a self-contained block that describes the page’s entities without affecting the page’s HTML structure. Microdata and RDFa are attributes that decorate existing HTML elements, marking up the content where it appears.

A page describing a recipe in JSON-LD has the recipe data in a script block in the head. The same page in Microdata has the recipe data marked up inline in the recipe HTML, with attributes like itemtype="https://schema.org/Recipe" and itemprop="name" decorating the existing elements.

JSON-LD: the format Google recommends:

JSON-LD has become Google’s preferred format through a combination of explicit documentation guidance and practical advantages:

Separation from HTML structure. The script block describes the entities without depending on the page’s visual markup. Template changes that move HTML elements around don’t break the structured data.
Easy to generate dynamically. Server-side code, JavaScript, and CMS plugins can produce JSON-LD without coordinating with the page’s HTML rendering.
Easy to validate. A self-contained JSON document is easier to validate, debug, and version control than scattered HTML attributes.
Documentation alignment. Google’s Search Central documentation uses JSON-LD examples almost exclusively. Following Google’s examples produces JSON-LD output.
CMS support. Modern CMSs and SEO plugins (Yoast, Rank Math, WordPress core blocks, Shopify themes, headless platforms) all generate JSON-LD by default.

The trade-off: JSON-LD describes the page’s entities separately from the visible content. A maintenance failure (forgetting to update the JSON-LD when the page content changes) produces structured data that contradicts the visible page. Google’s guidelines explicitly require structured data to match the visible content.

The compensating practice: generate JSON-LD from the same data source as the visible page content, so updates propagate automatically.

The shape of JSON-LD in practice, marking up a product page:

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Wireless Headphones X300",
  "image": "https://example.com/headphones-x300.jpg",
  "description": "Over-ear wireless headphones with 40-hour battery life.",
  "sku": "X300-BLK",
  "brand": {
    "@type": "Brand",
    "name": "AudioCraft"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/headphones-x300",
    "priceCurrency": "USD",
    "price": "199.00",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "847"
  }
}
</script>

The script tag sits in the page head or body. Nothing in the visible HTML needs to know it’s there.

Microdata: still works, rarely the right choice:

Microdata was popular in the early 2010s, before JSON-LD became dominant. Sites built during that period often still have Microdata in their templates. New implementations rarely choose it.

Where Microdata still makes sense:

Existing implementations that don’t have business-critical problems. Microdata works. If the markup is producing the rich results the site needs, switching to JSON-LD for the sake of switching usually isn’t worth the migration cost.
Sites where developers prefer inline markup. Some teams find Microdata more natural because it sits next to the content it describes. The cognitive model is “the markup is the page” rather than “the markup describes the page.”
Edge cases where rendering pipelines drop JSON-LD. Rare, but some legacy systems strip script blocks from cached pages or from email-templated versions. Microdata survives those pipelines.

Where Microdata creates problems:

HTML structure changes break the markup. Moving an element, splitting a section, or restructuring the layout requires also updating the Microdata attributes. The maintenance burden compounds over time.
Multiple entities on one page get awkward. A page describing a product and an organization and a breadcrumb has overlapping Microdata, with attributes nested across elements. JSON-LD handles multiple entities in a single, clean script block.
CMS support is fading. Most modern SEO plugins generate JSON-LD by default. Forcing Microdata output often requires custom development.

The summary: Microdata works but doesn’t have practical advantages over JSON-LD in 2026. New implementations should default to JSON-LD unless a specific constraint requires Microdata.

The same product page in Microdata, for comparison:

<div itemscope itemtype="https://schema.org/Product">
  <h1 itemprop="name">Wireless Headphones X300</h1>
  <img itemprop="image" src="https://example.com/headphones-x300.jpg" />
  <p itemprop="description">Over-ear wireless headphones with 40-hour battery life.</p>
  <meta itemprop="sku" content="X300-BLK" />
  <div itemprop="brand" itemscope itemtype="https://schema.org/Brand">
    <meta itemprop="name" content="AudioCraft" />
  </div>
  <div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
    <link itemprop="url" href="https://example.com/headphones-x300" />
    <meta itemprop="priceCurrency" content="USD" />
    <span itemprop="price">$199.00</span>
    <link itemprop="availability" href="https://schema.org/InStock" />
  </div>
  <div itemprop="aggregateRating" itemscope itemtype="https://schema.org/AggregateRating">
    <span itemprop="ratingValue">4.5</span>
    (<span itemprop="reviewCount">847</span> reviews)
  </div>
</div>

The markup is woven into the HTML that produces the visible page. Restructuring the page (moving the price out of the offer block, splitting the rating display into a separate component) requires also restructuring the Microdata attributes. That coupling is the maintenance cost JSON-LD avoids.

RDFa: niche, mostly academic:

RDFa (Resource Description Framework in Attributes) was designed to support a broader semantic web vision than schema.org alone. The format is technically more capable than Microdata in some ways but less commonly used in SEO contexts.

Where RDFa still appears:

Sites with broader linked data goals. Organizations that want to participate in linked data ecosystems beyond search engines sometimes use RDFa to express richer relationships than schema.org’s flat vocabulary requires.
Academic and government sites. RDFa has historical support in academic publishing, government data initiatives, and library systems where linked data principles predate schema.org’s popularity.
Legacy implementations. Sites built with early semantic web frameworks sometimes still have RDFa markup.

Where RDFa creates problems:

Limited Google documentation. Google’s examples are almost exclusively JSON-LD or Microdata. RDFa works in practice but has less official guidance.
Complex syntax. RDFa’s attribute structure is more verbose than Microdata for equivalent expressions, with more namespace handling and more nesting.
CMS support is minimal. Almost no modern CMS generates RDFa by default. Custom development is the default path.

The summary: RDFa is fine if it’s already in use and producing the desired results. It’s not a recommended choice for new implementations.

The same product page in RDFa Lite, for comparison:

<div vocab="https://schema.org/" typeof="Product">
  <h1 property="name">Wireless Headphones X300</h1>
  <img property="image" src="https://example.com/headphones-x300.jpg" />
  <p property="description">Over-ear wireless headphones with 40-hour battery life.</p>
  <meta property="sku" content="X300-BLK" />
  <div property="brand" typeof="Brand">
    <meta property="name" content="AudioCraft" />
  </div>
  <div property="offers" typeof="Offer">
    <link property="url" href="https://example.com/headphones-x300" />
    <meta property="priceCurrency" content="USD" />
    <span property="price">$199.00</span>
    <link property="availability" href="https://schema.org/InStock" />
  </div>
  <div property="aggregateRating" typeof="AggregateRating">
    <span property="ratingValue">4.5</span>
    (<span property="reviewCount">847</span> reviews)
  </div>
</div>

The attribute syntax is similar in shape to Microdata (vocab/typeof/property instead of itemscope/itemtype/itemprop) and shares the same coupling to HTML structure.

What Google actually does with each format:

The three formats produce equivalent results when implemented correctly. Google’s Search Relations team has confirmed in multiple talks that the format choice doesn’t affect ranking; what matters is whether the structured data is present, valid, and matches the visible content.

The practical equivalences:

A product page with JSON-LD ProductMarkup produces the same product rich results as the same page with Microdata Product markup.
An article page with JSON-LD Article markup produces the same article rich results as the equivalent Microdata or RDFa.
The rich results report in Search Console doesn’t differentiate by format. The report shows what entities Google extracted, not how they were encoded.

The implication: format choice doesn’t affect what’s possible. It affects how easy the markup is to implement, maintain, and validate.

A note on performance: the three formats differ in what they put on the wire. JSON-LD adds a script block to the page payload (typically 500 bytes to 5KB depending on entity complexity), entirely separate from the rendered HTML. Microdata and RDFa add attributes to existing HTML elements, increasing the markup density of the visible page (typically 200 bytes to 2KB across attributes, depending on schema depth). For most pages the difference is negligible against the rest of the payload. The performance-relevant edge case appears in frameworks with client-side hydration: JSON-LD blocks are inert (script type=”application/ld+json” never executes, never participates in hydration), while Microdata and RDFa attributes survive React/Vue/Svelte rendering only if the framework preserves arbitrary HTML attributes (most do, but some sanitizing pipelines strip non-standard attributes). For Next.js, Nuxt, and similar production frameworks, JSON-LD has the cleaner integration path because the script block sits in the document head or body without intersecting with the component tree.

The implementation checklist:

Whatever format the site uses, five quality checks apply:

The markup validates. Google’s Rich Results Test (search.google.com/test/rich-results) and the Schema Markup Validator (validator.schema.org) flag syntax errors and missing required fields.
The markup matches visible content. Structured data claiming “5-star rating” when the page shows “3 stars” produces guideline violations. Google’s documentation explicitly requires consistency.
Required fields are present. Each schema type has required and recommended fields. Missing required fields prevent rich results from displaying.
Multiple entities are properly linked. A page describing a product and its reviews and the organization selling it should use @id references in JSON-LD or itemref in Microdata to connect the entities.
The markup is on the right pages. Product schema belongs on product pages, not on category pages. Article schema belongs on individual articles, not on archive pages. Misplaced markup gets ignored or produces incorrect results.

Common implementation mistakes:

Six mistakes recur across structured data audits:

Generating structured data without validating it. The markup compiles and gets deployed, but invalid fields cause Google to ignore the entire block. Validation is a 30-second step that catches most failures.

Marking up content that doesn’t qualify for rich results. Adding HowTo schema to content that isn’t a how-to, adding Recipe schema to articles that mention food but aren’t recipes, or adding FAQ schema to general content with question-shaped headings. Google has tightened enforcement of these patterns since 2024, and misapplied markup often produces manual actions.

Letting structured data drift from visible content. The product page describes a $49 product; the JSON-LD says $39 because the price changed and the markup didn’t update. The fix is generating structured data from the same data source as the visible content.

Including markup on the wrong pages. Site-wide structured data that describes the homepage’s organization appears on every page, including pages where it doesn’t apply. Each schema type should appear only on pages where it’s appropriate.

Using outdated or non-standard schema types. The schema.org vocabulary evolves; some types get deprecated, others get added. Using a deprecated type produces ignored markup; using a non-standard custom type produces ignored markup.

Implementing markup but not monitoring results in Search Console. The Rich Results report shows which structured data is being recognized, which is producing errors, and which is being ignored. Without the monitoring, problems compound silently.

Migrating from Microdata to JSON-LD:

Most sites with legacy Microdata implementations eventually face a migration question. The path that works in production has four stages and avoids the failure mode where the markup briefly disappears or doubles up during the switch.

Stage 1, parallel deploy. Generate JSON-LD alongside the existing Microdata, on the same pages, describing the same entities. Both are present in the HTML. Google ignores duplicate markup of the same entity (it doesn’t produce penalties), so the parallel state is safe. The goal is verifying the JSON-LD produces the expected rich results in Search Console before removing anything.

Stage 2, validation period. Let the parallel deployment run for 2-4 weeks. Monitor the Rich Results report for the new JSON-LD entities. Compare against the Microdata baseline. If the JSON-LD produces the same coverage (or better, since malformed Microdata sometimes goes uncaught), the migration is safe to proceed. If gaps appear (some pages have Microdata that produces rich results but the new JSON-LD doesn’t), the JSON-LD generator needs fixing before removal.

Stage 3, Microdata removal. Strip the Microdata attributes from the HTML. The visible content stays unchanged because Microdata attributes are invisible to users. Deploy and watch Search Console for any drop in rich results coverage that suggests JSON-LD didn’t capture everything the Microdata did. Drops at this stage almost always trace to a specific schema type the JSON-LD generator missed.

Stage 4, cleanup and monitoring. Remove the Microdata generation code from the application. Add the JSON-LD generator to the monitored health checks. The migration is complete when no Microdata remains in the markup and Search Console coverage matches or exceeds the pre-migration baseline.

The mistake to avoid: removing Microdata before deploying JSON-LD, which produces a window (sometimes weeks) where the site has no structured data and rich results disappear. The parallel-deploy approach prevents that window. Sites running on CMS platforms with both Microdata and JSON-LD options can often do this through configuration rather than code; sites with hand-rolled implementations need engineering work for each stage.

Modern CMS and framework patterns:

Implementation looks different across the major content platforms in 2026:

WordPress. Yoast SEO, Rank Math, and SEOPress all generate JSON-LD automatically for common content types. The plugins handle Article, Product (via WooCommerce integration), BreadcrumbList, and Organization markup with sensible defaults. Customization happens through plugin settings or theme-level filters.
Shopify. The platform generates Product, Offer, and AggregateRating JSON-LD automatically from product data. Apps like JSON-LD for SEO add additional schema types (FAQ, HowTo, Video) where the default templates don’t cover them.
Next.js and React. The standard pattern is rendering JSON-LD as a <script> tag in the page’s head, populated from server-side data. Libraries like next-seo and schema-dts (TypeScript types for schema.org) make the implementation type-safe and reduce errors.
Astro and SvelteKit. Both generate static HTML with structured data inlined at build time. The pattern is similar to Next.js but produces static output that’s easier to debug.
Headless CMS architectures. When CMS and presentation are separated (Contentful, Sanity, Strapi as the CMS; Next.js or Gatsby as the presentation), structured data generation typically lives in the presentation layer with content data from the CMS. The separation can produce schema implementation gaps if the presentation layer doesn’t comprehensively cover content types that the CMS adds later.

The pattern across platforms: structured data is increasingly a templating concern, not a manual markup decision. Sites whose CMS or framework generates schema consistently produce reliable structured data; sites that rely on manual markup produce inconsistent results that are hard to audit and fix.

Debugging structured data in production:

The validators catch most syntax errors at build time. The harder problems appear in production, after deployment, when rich results don’t show up despite seemingly correct markup. The debugging workflow:

Verify the markup is actually in the response. View the page source (not the rendered DOM in DevTools). JSON-LD added by JavaScript may not be in the initial HTML; Google’s first-pass indexer may miss it. Use curl or Search Console’s URL Inspection to see what Google actually receives.
Check the Rich Results Test on the live URL. The test reports eligibility plus any errors or warnings. Warnings (missing recommended properties) won’t block rich results but reduce the chance Google selects the page.
Inspect Search Console’s Enhancement reports. Each schema type has a report showing valid, valid with warnings, and error counts site-wide. Trend the numbers over time; sudden drops indicate template-level breakage.
Compare schema across page templates. Templates that share design but differ in schema (e.g., editorial articles vs product reviews using the same layout) often have subtle differences in which properties get populated. Audit one representative URL from each template.
Verify schema accuracy against page content. Schema that declares a product is in stock when the page shows “out of stock” creates a mismatch that Google’s spam systems may flag. Schema accuracy needs to match user-visible content at all times.

The pattern that catches the most production issues: monthly sampling of 10-20 URLs across page templates through the Rich Results Test, with Search Console Enhancement reports as the trend signal. The sampling catches template-specific problems; the trend reports catch site-wide drift.

Entity-level structured data beyond rich results:

Structured data does more than produce rich results. It establishes entity relationships that Google uses to understand the site beyond the page level. The properties worth marking up even when they don’t produce visible SERP features:

sameAs on Organization and Person schema. Links to the entity’s Wikipedia page, Wikidata entry, official social profiles, and authoritative external references. The signal helps Google’s Knowledge Graph identify the entity unambiguously.
mainEntity on FAQ and How-To pages. Declares the central topic of the page, helping Google identify which questions and answers the page is actually about.
isPartOf on Article schema. Declares the publication, series, or collection the article belongs to. Useful for sites with multiple content properties or content series.
author and editor with full Person schema. Beyond a name string, the full Person reference (with sameAs to author bios, credentials, social profiles) supports E-E-A-T signals for content quality.
reviewedBy and dateModified on YMYL pages. Medical, legal, and financial content benefits from explicit declarations of expert review and update history. The signals support trust calibration that Google’s quality systems consider.

These properties typically don’t produce SERP rich results directly, but they contribute to how Google understands the site’s expertise and authority. The downstream effect is on quality calibration rather than on specific SERP features.

Pick JSON-LD, then focus on what matters:

The format decision is straightforward in 2026. JSON-LD for new implementations. Microdata or RDFa for legacy implementations that are working. Migration between formats is technically possible but rarely worth the cost unless the current format is producing specific problems.

The harder decisions are about what to mark up and how to keep the markup accurate. The format is the easy part; the implementation discipline is the part that determines whether structured data produces rich results, makes pages eligible for special SERP features, and helps Google understand the entities on the site.

The sites that handle structured data well treat it as part of the content production process: marked up at the same time as content is written, validated before deployment, monitored in Search Console, and updated when content changes. The sites that don’t treat it that way end up with structured data that contradicts visible content, produces errors, or simply doesn’t appear in the rich results that the markup was meant to enable.

JSON-LD won by being unobtrusive. The format sits in a script tag, never touches the visible content, never breaks when templates change, never gets corrupted by the WYSIWYG editor. Markup that survives years of CMS migrations, theme updates, and design refreshes wins the long game. The decision about format ends up being a decision about which markup will still be there in five years.

Related posts: