Structured data is how you tell search engines and AI systems what your content actually means, not just what it says. But there are three different syntaxes for implementing it: Microdata, RDFa, and JSON-LD. They all speak the same underlying vocabulary (largely Schema.org), but they do it in very different ways, with very different implications for your site.
If you've ever stared at a schema implementation guide and wondered why some examples look like tangled HTML attributes while others look like a clean block of JavaScript, that's the difference between these three formats. Let me break it down properly.
How each format actually works
The core distinction between the three formats is where the structured data lives relative to your HTML content. This sounds like a technical detail, but it has real consequences for maintenance, readability, and how reliably crawlers can process it.
Microdata
Microdata is an HTML5 specification. It works by adding attributes directly to your existing HTML tags. You annotate elements in your page with itemscope, itemtype, and itemprop attributes. The browser renders the page normally, but crawlers read those attributes to understand what the content represents.
A simple example: if you have a product name in an <h1> tag, you'd wrap it in a <span itemprop="name"> and add itemscope itemtype="https://schema.org/Product" to a parent element. The structured data is essentially baked into the visible content of the page.
The appeal of Microdata in its early days was that it tied the structured data tightly to the actual displayed content, which felt like it reduced the risk of misleading search engines. In practice, it became a maintenance headache. Change your HTML structure and you risk breaking your schema. It's also verbose and difficult to read, especially across complex pages.
RDFa
RDFa (Resource Description Framework in Attributes) predates Microdata and comes from the broader Semantic Web movement. Like Microdata, it embeds structured data as attributes within your HTML. But it uses a different set of attribute names: vocab, typeof, property, and resource are the main ones.
RDFa is more flexible and powerful than Microdata in theory. It supports a wider range of vocabularies and can express more complex relationships between entities. RDFa Lite, a simplified subset, was introduced to make it more approachable for everyday web publishers.
In practice, RDFa is even more verbose than Microdata. It was designed by people who cared deeply about the Semantic Web as a philosophical project, which means it handles edge cases that almost no e-commerce site will ever encounter, at the cost of significant complexity. Google has supported it for years, but it's always been the least popular of the three formats for day-to-day web development.
JSON-LD
JSON-LD (JavaScript Object Notation for Linked Data) takes a completely different approach. Instead of embedding data inside your HTML markup, it lives in a separate <script type="application/ld+json"> block, usually in the <head> or at the bottom of the page. The structured data is entirely separate from the visible content.
That separation is the key advantage. You can add, edit, or remove your structured data without touching your HTML at all. A developer can inject it via a CMS, a tag manager, or a server-side script. It's readable. It's testable. And because it's just a JSON object, most developers already know how to work with it.
Google officially recommends JSON-LD. They've said so clearly in their developer documentation. It's also what FlinnSchema uses for every implementation, because it's the most reliable format for getting structured data processed correctly at scale.
Why the separation of data from markup matters
When your structured data is woven into your HTML attributes, as it is with both Microdata and RDFa, any front-end change carries schema risk. A designer reskins the product page. A developer refactors the template. The HTML structure shifts, and suddenly your itemprop attributes are pointing at elements that no longer contain the right content, or they're gone entirely.
With JSON-LD, the schema block is independent. You can update your entire visual design without touching a line of structured data. You can also have a dedicated process for managing and validating schema, completely decoupled from your front-end deployment pipeline.
For e-commerce sites in particular, this matters enormously. Product pages, category pages, and review content change frequently. Keeping Microdata or RDFa in sync with those changes is genuinely difficult at scale. JSON-LD can be generated programmatically from your product database and injected dynamically, which is exactly how it should work for a site with thousands of SKUs.
How AI search engines process structured data
This is where the format choice becomes more than just a developer preference. AI search engines like ChatGPT, Perplexity, and Gemini are not crawling your site in real time when someone asks a question. They're working from indexed knowledge, from data they've already processed. Structured data helps them understand your content during that ingestion phase.
JSON-LD is easier for automated systems to extract reliably. Because it's a discrete, self-contained block, a parser doesn't need to walk the entire DOM to reconstruct the structured data. It's right there, in a predictable location, in a predictable format.
Microdata and RDFa require the parser to traverse the HTML tree and assemble the structured data from scattered attributes. That works when the HTML is clean and well-formed. When it isn't, which is common on sites that have evolved over years with multiple developers and CMS plugins, the extracted data can be incomplete or malformed.
If your goal is AI visibility, and it should be, then JSON-LD is the only sensible choice. It's the format that gives AI systems the clearest possible signal about who you are, what you sell, and what makes you worth recommending.
You can read more about why this matters in our post on what JSON-LD schema markup is and why AI search needs it.
Practical compatibility: what Google and Bing actually support
All three formats are technically supported by Google and Bing. But "supported" doesn't mean "equally well supported." Google's Rich Results Test handles JSON-LD most reliably. Their documentation examples are almost exclusively in JSON-LD. When Google introduces a new schema type or feature, the JSON-LD implementation is always documented first and most thoroughly.
Bing follows a similar pattern. Microsoft's AI products, including Copilot, draw on Bing's index, so structured data that Bing processes cleanly has a direct path into Microsoft's AI answers.
The practical lesson: if you're choosing a format for a new implementation today, there is no legitimate reason to choose Microdata or RDFa over JSON-LD. The only scenario where you'd maintain existing Microdata or RDFa is if migrating it would be too costly in the short term, and even then, migrating it should be on the roadmap.
Common misconceptions about the three formats
"JSON-LD isn't as trustworthy because it's separate from the visible content"
This concern comes up occasionally. The idea is that because JSON-LD can describe things that aren't visible on the page, it could be used deceptively. Google addressed this years ago. They check for consistency between JSON-LD markup and page content as part of their quality systems. If your JSON-LD says you have a 4.8-star rating but there are no reviews on the page, that's a problem. But the format itself isn't inherently less trustworthy. It's the content of the markup that matters.
"Microdata is better because it's more tightly coupled to the content"
Tight coupling sounds like a virtue until you try to maintain it across a large site. The coupling that makes Microdata feel "honest" is the same coupling that makes it fragile. JSON-LD can be just as accurate. It just requires discipline in keeping it updated, which is a process problem, not a format problem.
"RDFa is more powerful so it must be better"
RDFa's power comes from its expressiveness in handling complex linked data relationships. For a typical e-commerce or service business, you will almost never need that expressiveness. You need clean, accurate, well-maintained schema for your products, organisation, reviews, and FAQs. JSON-LD does all of that with far less friction.
What this means for your schema strategy
If you're starting from scratch or auditing an existing site, the answer is straightforward: use JSON-LD. Implement it in the <head> of your pages, generate it dynamically where content changes frequently, and validate it regularly with Google's Rich Results Test and Schema.org's validator.
For Shopify sites, JSON-LD can be injected through theme templates or via apps. For WordPress, plugins like RankMath and Yoast generate JSON-LD natively, though their default outputs often need customising to match your actual content structure. For custom builds, generating JSON-LD server-side from your content database is the most reliable approach.
Getting the right schema types in place is equally important. You can find a detailed breakdown of which types matter most in our guide to which schema types every e-commerce site should have.
At FlinnSchema, we work exclusively with JSON-LD because it's the format that gives clients the most reliable path to structured data that AI systems can actually use. If you want to see how your current implementation stacks up, our free AI visibility audit will show you exactly what's working and what isn't.
The format debate might seem academic, but it has real downstream effects. Clean, well-structured JSON-LD is one of the clearest signals you can send to AI search engines that your business is worth knowing about.
Frequently Asked Questions
Can I mix JSON-LD with Microdata or RDFa on the same page?
Technically yes, and search engines will attempt to process both. In practice, mixing formats on the same page usually creates confusion rather than benefit. If you have legacy Microdata or RDFa on a page, the cleanest approach is to migrate it fully to JSON-LD rather than running both in parallel. Duplicate or conflicting markup can lead to inconsistent rich result behaviour.
Does Google treat JSON-LD differently to Microdata when ranking pages?
Google says structured data is not a direct ranking factor, but it influences eligibility for rich results, which affect click-through rates. In practice, JSON-LD implementations tend to be processed more reliably, which means fewer errors and more consistent rich result display. The indirect effect on performance is real, even if the direct ranking signal isn't.
Is JSON-LD affected by JavaScript rendering issues?
It can be, if the JSON-LD block is injected entirely by client-side JavaScript. Google can process JavaScript-rendered content, but it introduces a delay. For best results, render JSON-LD server-side so it's present in the initial HTML response. This is particularly important for AI crawlers, which may not execute JavaScript at all during indexing.
What's the easiest way to check which format my site is currently using?
View your page source and search for application/ld+json to find JSON-LD blocks. Search for itemscope or itemtype to find Microdata. Search for typeof or vocab to find RDFa. Many sites have a mix, particularly if they've used multiple plugins or themes over the years. Google's Rich Results Test will also show you what structured data it's finding, regardless of format.