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 is the same regardless of how the markup is encoded. What differs is the encoding format: JSON-LD, Microdata, or RDFa. Google’s official guidance is that all three are supported and parsed equally well, and that the format choice does not change what rich results a page is eligible for. But the guidance also names a preference, and for new work that preference settles most of the decision.
The three formats side by side #
The formats differ mainly in where the markup lives and whether it touches the visible page.
| Format | Where it lives | Visual position |
|---|---|---|
| JSON-LD | A <!–INLINECODE0–> block, typically in <!–INLINECODE1–> | Hidden from visible page content |
| Microdata | HTML attributes inline on existing elements | Embedded within visible HTML |
| RDFa | HTML attributes similar to Microdata, using RDF vocabulary | Embedded within visible HTML |
The visual difference is the whole story. JSON-LD is a self-contained block that describes the page’s entities without altering the page’s HTML structure. Microdata and RDFa are attributes that decorate existing HTML elements, marking up the content where it appears. A recipe page in JSON-LD carries the recipe data in a script block; the same page in Microdata marks the recipe up inline, with attributes like itemtype="https://schema.org/Recipe" and itemprop="name" layered onto the existing elements.
JSON-LD: the format Google recommends #
Google’s documentation recommends JSON-LD for structured data when a site’s setup allows it, describing it as the easiest format for site owners to implement and maintain at scale. That recommendation sits alongside a plain statement that all three formats are supported, so the preference is about ergonomics, not eligibility. Several practical properties back it up.
- 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 do not break the structured data.
- Reliable crawling, including dynamic injection. Google states it can read JSON-LD even when the block is injected by JavaScript or embedded by a CMS widget. That reliability is a large part of why the format is preferred.
- Easy to generate and validate. A single JSON document is simpler to produce server-side, validate, debug, and keep in version control than attributes scattered across the page’s HTML.
- Documentation alignment. Google’s Search Central examples are almost entirely JSON-LD. Following the official examples produces JSON-LD output by default.
- CMS support. Modern CMSs and SEO plugins, including Yoast, Rank Math, WordPress core blocks, and Shopify themes, generate JSON-LD out of the box.
The trade-off is that JSON-LD describes the page’s entities separately from the visible content, so a maintenance lapse can leave the two out of sync. Google’s guidelines explicitly require structured data to match what users see on the page. The compensating practice is to generate the JSON-LD from the same data source as the visible content, so a content change propagates to the markup automatically rather than by hand.
Marking up a product page, the shape in practice:
<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",
"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 head or body, and nothing in the visible HTML needs to know it is there.
Microdata: still works, rarely the right choice #
Microdata was popular in the early 2010s, before JSON-LD became dominant. Sites built in that period often still carry Microdata in their templates, and it continues to work. New implementations rarely choose it, though a few situations still favor it: an existing implementation that produces the rich results a site needs and has no business-critical problems, where a migration would cost more than it returns; teams that prefer inline markup sitting next to the content it describes; and rare rendering pipelines that strip script blocks from cached or email-templated pages, where inline attributes survive.
The problems are more common than the fits. HTML structure changes break the markup, because moving or splitting an element means also updating its Microdata attributes, and that burden compounds over time. Multiple entities on one page get awkward, with attributes nested and overlapping across elements, where JSON-LD handles the same entities in one clean block. And CMS support is fading, since most modern plugins emit JSON-LD by default and forcing Microdata usually requires custom development.
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>
<div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
<meta itemprop="priceCurrency" content="USD" />
<span itemprop="price">199.00</span>
<link itemprop="availability" href="https://schema.org/InStock" />
</div>
</div>The markup is woven into the HTML that produces the visible page. Restructuring the page, say moving the price out of the offer block, means restructuring the attributes too. 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. It is technically capable but far less common in SEO contexts. It still turns up on sites with broader linked-data goals, on academic and government sites where linked-data principles predate schema.org’s popularity, and in legacy implementations built with early semantic web frameworks.
For search work it carries the same drawbacks as Microdata plus a few of its own: Google’s examples are almost never RDFa, so official guidance is thin; the attribute syntax is more verbose, with more namespace handling and nesting; and almost no modern CMS generates it by default. RDFa is fine if it is already in place and producing the results a site needs. It is not a sensible choice for new implementations. In RDFa Lite the syntax mirrors Microdata’s shape, using vocab, typeof, and property in place of itemscope, itemtype, and itemprop, and it shares the same coupling to HTML structure.
What Google actually does with each format #
Implemented correctly, the three formats produce equivalent results. Google has stated repeatedly that format choice does not affect ranking or eligibility; what matters is that the structured data is present, valid, and matches the visible content. A product page with JSON-LD Product markup earns the same product rich results as the same page in Microdata. An article in JSON-LD Article markup earns the same article results as the equivalent Microdata or RDFa. The rich-results report in Search Console does not differentiate by format at all; it shows which entities Google extracted, not how they were encoded. So the format decision does not change what is possible. It changes how easy the markup is to implement, maintain, and validate, which is exactly why Google’s own recommendation lands on the format that is hardest to get wrong.
How to check any implementation, whatever the format #
Whatever encoding a site uses, the same quality checks decide whether the markup does anything.
- It validates. Google’s Rich Results Test and the Schema Markup Validator flag syntax errors and missing required fields.
- It matches visible content. Structured data claiming a five-star rating on a page that shows three stars is a guideline violation. Google requires consistency.
- Required fields are present. Each schema type has required and recommended fields, and missing required fields prevent rich results from appearing.
- Multiple entities are linked. A page describing a product, its reviews, and the selling organization should connect them with
@idreferences in JSON-LD, oritemrefin Microdata. - The markup is on the right pages. Product schema belongs on product pages, not category pages; article schema on individual articles, not archives. Misplaced markup is ignored or produces incorrect results.
Beyond those checks, the recurring failures in structured-data audits are predictable: deploying markup without validating it, so an invalid field makes Google ignore the whole block; marking up content that does not qualify, such as adding FAQ schema to general content with question-shaped headings, a pattern Google has enforced against more aggressively since 2024; letting the markup drift from the visible content when a price or availability changes; placing site-wide organization markup on pages where it does not apply; using deprecated or non-standard schema types that get ignored; and shipping markup without ever checking the Rich Results report in Search Console, so problems compound silently.
FAQ #
Does the format I choose affect my rankings?
No. Google has stated the format choice does not affect ranking or which rich results a page is eligible for. Presence, validity, and consistency with visible content are what matter.
Should I migrate my old Microdata to JSON-LD?
Only if the current markup is causing specific problems. Working Microdata rarely justifies the migration cost. If you do migrate, deploy JSON-LD in parallel first, confirm it produces the same coverage in Search Console over a few weeks, then remove the Microdata, so the site is never left with no structured data.
Is JSON-LD in the page head reliable if it is added by JavaScript?
Google states it can read JSON-LD even when injected dynamically by JavaScript or a CMS widget. It is still worth confirming with the URL Inspection tool that the rendered page contains the block.
Which validator should I use?
The Rich Results Test checks eligibility for Google’s rich-result features; the Schema Markup Validator checks general schema.org syntax. Use both, then monitor the Enhancement reports in Search Console for site-wide trends.
Where this leaves the decision #
The format choice is the easy part of structured data in 2026, and it points one way. Use JSON-LD for new implementations; leave working Microdata or RDFa in place unless it is producing specific problems worth a migration. The harder work is deciding what to mark up and keeping the markup accurate, because format never made a page eligible for a rich result. Discipline does: mark up at the same time the content is written, validate before deploy, monitor in Search Console, and update the markup whenever the content changes. JSON-LD’s advantage is that it survives the churn. It sits in a script tag, never touches the visible content, and does not break when a template moves, which is why the markup tends to still be there after years of CMS migrations and redesigns.