Schema.org vocabulary can be expressed in three syntaxes: JSON-LD, Microdata and RDFa. They can describe identical information, and search engines parse all three. The differences are entirely practical, and they matter a great deal in a real codebase.
#The three formats
JSON-LD places structured data in a single <script type="application/ld+json"> block, independent of your visible HTML:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Aeron Desk Lamp",
"offers": {
"@type": "Offer",
"price": "129.00",
"priceCurrency": "USD"
}
}
</script>Microdata annotates your existing HTML with attributes:
<div itemscope itemtype="https://schema.org/Product">
<h1 itemprop="name">Aeron Desk Lamp</h1>
<div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
<span itemprop="price">129.00</span>
<meta itemprop="priceCurrency" content="USD">
</div>
</div>RDFa is similar to Microdata with different attribute names, from the broader semantic web tradition.
#Why JSON-LD wins in practice
Separation of concerns. The structured data lives in one place. A designer changing the product page layout cannot accidentally break it, because it is not woven through the markup.
Trivially generated. Your server or framework already has the product object. Serialising it to JSON-LD is one function call. Threading Microdata attributes through a template requires touching every element that carries a property.
Auditable. You can read the entire structured data payload in one block. Reconstructing what Microdata says requires mentally parsing scattered attributes across the page.
Survives refactors. This is the decisive practical argument. Microdata implementations degrade over time as components are rewritten — an itemprop gets dropped when a <span> becomes a <div> and nobody notices for months. JSON-LD does not have that failure mode.
Google explicitly recommends it. That alone settles most debates in a team.
#Where Microdata still has an argument
Guaranteed content parity. Because Microdata annotates visible content, the structured data and what users see cannot diverge. With JSON-LD it is possible to describe a price that differs from the page — which is a policy violation and a real risk in a system where the two are generated from different code paths.
The mitigation is straightforward: generate both from the same data source. If your template renders product.price and your JSON-LD serialises product.price, they cannot disagree.
Existing implementations that work. If you have functioning Microdata producing rich results, there is no urgency. Migrate when you next touch those templates rather than as a project of its own.
#Can you use both?
Technically yes, and search engines will parse both. In practice it creates a maintenance burden and a risk of contradiction — two sources describing the same entity that can drift apart.
Pick one. If migrating, remove the old format in the same change rather than leaving it in place "just in case".
#Placement
JSON-LD conventionally goes in <head>. Google can also read it from <body> and from script injected after page load, but head placement removes any dependence on rendering and is easiest to audit.
For pages describing multiple entities — an article that also has an FAQ section and sits in a breadcrumb trail — use a @graph array or multiple script blocks. Both are valid.
#Generating it properly
The failure mode with JSON-LD is hand-writing it per page. Hand-written markup drifts out of sync with the page within weeks and does not scale past a few dozen URLs.
The pattern that works: use the schema markup generator to design and validate the shape you want for each page type, then implement that shape as a template that serialises from your real data. Every product page then produces correct JSON-LD automatically, sourced from the same object that renders the visible page.
#Validation
Two tools, and they serve different purposes:
Google Rich Results Test — checks eligibility for specific rich result types and reports missing required properties. This is the one that tells you whether Google will use your markup.
Schema Markup Validator at validator.schema.org — validates against the full Schema.org vocabulary, stricter than Google's tool. Useful for catching property names that are valid vocabulary but not part of any Google rich result.
Then watch the Enhancements reports in Search Console after deployment. A template bug propagates to every page of that type at once, and Search Console is where it surfaces.
Frequently asked questions
Does Google prefer JSON-LD?
Yes, Google explicitly recommends JSON-LD in its structured data documentation. All three formats are parsed, but JSON-LD is the recommended and most maintainable choice.
Should I migrate existing Microdata to JSON-LD?
Not urgently if it is working. Migrate opportunistically when you next rework those templates. New implementations should use JSON-LD from the start.
Can JSON-LD be added with JavaScript?
Google can process JSON-LD injected by JavaScript, since it renders pages. However server-side rendering is more reliable, avoids any dependence on the rendering queue, and is easier to audit. Prefer it where possible.