The JSON LD vs microdata question comes up whenever a site changes theme, plugin or platform and inherits markup in a format nobody chose. The short answer is that both work, Google reads both, and one of them is much easier to keep correct. The longer answer is about maintenance, not rankings.
This guide covers what each format is, why Google prefers JSON-LD, the cases where microdata is still a reasonable choice, and how to check either. If structured data is new to you, start with our primer on schema markup.
The three formats Google supports
Google’s introduction to structured data markup lists three formats. All three describe the same schema.org vocabulary; they differ only in where the markup lives and how it is written.
JSON-LD is described as “A JavaScript notation embedded in a <script> tag in the <head> and <body> elements of an HTML page”. Microdata places attributes directly on the HTML elements that hold the visible content, nesting them to describe properties. RDFa is “An HTML5 extension that supports linked data by introducing HTML tag attributes that correspond to the user-visible content.”
| JSON-LD | Microdata | RDFa | |
|---|---|---|---|
| Where it lives | A script block in the head or body | Attributes nested in the HTML | Attributes on HTML tags |
| Tied to visible markup | No, kept separate | Yes | Yes |
| Google’s position | Recommended | Supported | Supported |
| Main maintenance risk | Values drifting from the page | Template edits breaking the nesting | Template edits breaking the attributes |
So the JSON LD vs microdata vs RDFa choice is not about what Google can read. It is about who maintains the markup, and how easily they can break it without noticing.
Why Google recommends JSON-LD
Google gives a plain reason. JSON-LD is “the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors)”. That phrase, less prone to user errors, is the whole argument.
Because JSON-LD sits in its own block, it is separate from the text visitors read. A designer can restructure a product page, change the heading levels and move the price into a new component without touching the structured data. With microdata, the same redesign can quietly strip an itemprop attribute or break the nesting, and the markup stops describing the page.
Separation also makes JSON-LD easier to generate. A template or plugin can build one block from the page’s data and drop it in, which is how most CMS platforms and SEO plugins handle it. Here is a minimal example for an article:
The microdata version of the same thing wraps the visible headline, date and byline in elements carrying itemscope, itemtype and itemprop attributes:
Both describe the same entity. Only one survives a redesign untouched. Our guide to article schema covers which properties that block should carry.
When microdata still makes sense
Microdata is not wrong, and replacing it is not automatically worth the effort. There are a few cases where keeping it, or even choosing it, is reasonable.
- It already works. If a mature template outputs valid microdata and the reports in Search Console are clean, rewriting it carries risk for no gain in eligibility.
- The markup must follow the content exactly. Because microdata wraps the visible text, it cannot describe a price or rating the page does not show. Some teams value that coupling as a guard against drift.
- Your platform only emits it. Older themes and some shop software produce microdata by default. Fighting the platform can cost more than it saves.
What you should avoid is running both formats for the same entity with different values. A theme that outputs microdata alongside a plugin that outputs JSON-LD can describe one product twice with two prices. Pick one source of truth per entity and switch the other off. If you sell products, our guide to product schema shows what a single clean block looks like.
What matters more than the format
The format rarely decides whether markup earns a rich result. Completeness does. Google states: “You must include all the required properties for an object to be eligible for appearance in Google Search with enhanced display.”
A complete microdata block beats an incomplete JSON-LD one every time. The common failures are missing required properties, values that disagree with the page, and markup describing content that is not there at all. None of those is fixed by switching formats.
Placement matters too. Injecting structured data through a tag manager is best avoided; generating it in the page’s own HTML is the more reliable route. Our piece on Google Tag Manager and SEO covers where tag managers help and where they get in the way.
How to test structured data in either format
Testing works the same for both. Run the Rich Results Test on a few pages from each template before launch; it reads JSON-LD, microdata and RDFa alike and lists errors and warnings. After launch, monitor the rich result status reports in Search Console, where template-wide problems show up across many URLs at once.
If you are migrating from microdata to JSON-LD, test the old and new versions side by side on the same URL. The detected items should match property for property. Then remove the microdata once the JSON-LD is confirmed, rather than leaving both in place.
Pick test pages that stress the template. An article with several authors, a product that is out of stock, a page with no image: these are the cases where a generated block falls back to a default or drops a property. One clean result on the best-behaved page tells you very little about the other few thousand. And repeat the checks whenever the theme, the plugin or the CMS changes, because markup that was correct at launch can break silently after an update that nobody connected to structured data.
One limitation to be honest about. Choosing the recommended format, and passing every test, does not guarantee rich results. Markup makes a page eligible; Google decides what to show. So judge your structured data by whether it is accurate, complete and easy to keep that way, not by whether a rich result appeared this week. For most sites that points to JSON-LD, generated from the same data that renders the page. If you are asking what JSON-LD is in SEO terms, that is the practical answer: a separate, machine-readable description of the page that is easier to keep correct than markup woven through the HTML.
Frequently asked questions
Should I use JSON-LD or microdata?
Use JSON-LD unless you have a reason not to. Google supports both but recommends JSON-LD as the easiest to implement and maintain at scale.
Does Google rank JSON-LD higher than microdata?
No. Google reads JSON-LD, microdata and RDFa. What decides eligibility is whether all required properties are present and accurate.
Can I use JSON-LD and microdata on the same page?
You can, but avoid describing the same entity twice with different values. Pick one format per entity and switch the other off.
How do I test structured data?
Use the Rich Results Test before launch, then monitor the rich result status reports in Search Console afterwards.
The takeaway Default to JSON-LD, keep one source of truth per entity, include every required property, and test each template rather than a single page.
