JSON-LD vs microdata: 22 of 385 home pages carried microdata and one carried RDFa

Google names three formats and the field ships one

Google's introduction to structured data, read on 14 September 2026 and carrying Last updated 2025-12-10 UTC, states that Google Search supports structured data in the following formats, unless documented otherwise, and then names JSON-LD, Microdata and RDFa. The same page says that implementing it using formats like JSON-LD, Microdata, or RDFa can result in rich results. Three formats, named by the organisation whose parser most site owners are writing for.

The vocabulary maintainer says something similar about its own history. The schema.org FAQ, read the same day, records that focusing on microdata seemed like a pragmatic decision at the time, that for some time now we have been supporting multiple syntaxes, specifically including RDFa and JSON-LD, and that there are certain things that are much harder in Microdata, like mixing vocabularies, or inverting the direction of a property relationship. Microdata came first and the project moved on without deprecating it.

The three differ in where the values live rather than in what they can say. JSON-LD puts them in a script block that no reader sees and no layout touches. Microdata puts them on the elements that already display the value, using the itemprop attribute defined in the HTML reference. RDFa does the same job with different attribute names, specified in RDFa Lite 1.1. All of that is documentation. None of it says what is actually deployed, and this blog has only ever tested the question on five frozen pages, where it found that a valid BreadcrumbList scored zero because of its syntax.

JSON-LD vs microdata: which one do real sites actually ship?

The frame is the 392 hostnames committed to this repository at worker/seeds/corpus-seeds-platform.json, stratified by the platform a site is built on rather than sampled at random from the web, and weighted toward small and mid sized sites. Each was asked once for its home page over HTTPS as LantadBot/1.0, redirects followed, a 25 second timeout, from one network location, with nothing executed. That matters for a count of this kind, because markup injected after load never appears in the bytes, and only two of nine crawler operators say either way whether theirs renders. The detection rules were deliberately strict and are described below. How the authority for each request is fixed is set out in our methodology.

385 of the 392 answered with a 2xx and an HTML content type. Of the seven that did not, three returned 403, two returned 404, and two failed at the transport layer before any status arrived. Those seven are counted nowhere.

Across the 385, JSON-LD appeared on 239 pages carrying 437 blocks between them, and eight pages shipped exactly one block that would not parse as JSON. Microdata appeared on 22. RDFa appeared on one. No page in the sample carried all three. The platform a site is built on predicts the outcome far better than anything else measured: 53 of 54 Wix and Squarespace pages carried JSON-LD against 8 of 31 documentation sites, which is the same split the earlier count of JSON-LD alone reported on this corpus three days earlier. What is new is the second and third columns, and they are empty almost everywhere. Six of the ten strata, covering 243 of the 385 pages, produced no microdata and no RDFa at all.

What the 239 JSON-LD pages declare is narrow as well. Counting every type named in every block, WebSite appears on 187 pages and Organization on 161, followed by ImageObject on 93, SearchAction on 86, WebPage on 79, PostalAddress on 69 and LocalBusiness on 55. BreadcrumbList reaches 60 and ListItem 59, which are the same structure counted twice. Those are the nodes a template writes about the site itself, and the types that describe what a business actually sells or publishes sit well below them.

Does reading the other two syntaxes rescue a page that has no JSON-LD?

This is the question the earlier count left open, and it has a number now. 146 of the 385 pages published no JSON-LD. Reading those 146 again for microdata and for RDFa found three with microdata and one with RDFa. Four pages. The remaining 142 carry nothing that any schema parser reads, in any of the three syntaxes the vocabulary travels in.

So a reader that recognises only JSON-LD was wrong about four of 385 pages, which is 1.0 percent. That is the honest size of the blind spot, and it cuts both ways. It is small enough that the earlier headline figure stands more or less intact: 142 bare pages rather than 146, a correction of under three percent of that group. It is also not zero, and the four sites it covers are real businesses whose markup this scanner still cannot see, because the extractor reads one script type and no code path anywhere in it looks at an attribute. That limit is unchanged since it was written up in August, and what a crawler sees of a page is the surface it applies to.

The three microdata only pages are the more interesting group, because all three are Shopify storefronts and all three publish the same thing. notebooktherapy.com carries one itemtype naming schema.org Organization and four itemprop attributes, three of them logo and one url. shopshorthand.com carries two. skullbliss.com carries three. That is a theme header declaring that the shop has a logo. None of the three says anything about a product, a price or availability, which on a storefront is the information a reader would want, so rescuing these pages recovers a logo rather than a catalogue.

Where microdata survives, and who appears to have written it

All 22 microdata pages sit in four of the ten strata, and three of those four are the parts of the corpus running an older content management stack: 10 WordPress small business sites, eight local media sites, three Shopify storefronts and one SaaS marketing site. The hosted site builders produced none. Not one page on Framer, Webflow, Wix, Squarespace or Bubble carried a single itemscope. Those platforms generate their markup, they generate JSON-LD, and the question of syntax never reaches the site owner.

Inside the 19 pages that carry both syntaxes, the microdata rarely describes the business. somersetvethospital.com carries 39 itemtype attributes, of which 17 name ImageObject, four name WebPage, four name Organization and three name Person. grantcountybeat.com carries 170 itemprop attributes. These are the signatures of a theme and its plugins annotating galleries, comment counts and post listings, running underneath a JSON-LD block that a separate plugin writes. The site owner chose neither. That is also why the counts are so lopsided by stratum, and it is consistent with the LocalBusiness study on the industry corpus the same day, where not one of 172 large organisation home pages used microdata at all.

The single RDFa page is the clearest case of markup nobody asked for. accountantsonair.com is an accountancy practice, and its home page carries 56 typeof attributes naming Place, 56 naming GeoCoordinates and 44 naming an image type in the foaf namespace, with no JSON-LD and no microdata anywhere. An accountancy firm does not have 56 locations. A gallery plugin emitting geographic annotations per image does. Compare that with what the vocabulary is actually used for in aggregate, where only 16 schema.org types reach 10 million domains, and the pattern is the same one: the markup that exists is mostly the markup something generated.

Open Graph sits on 359 pages and is none of the three

There is a trap in counting RDFa, and falling into it would have produced a much more exciting and completely wrong number. RDFa marks values with a property attribute. So does Open Graph, the metadata block that produces a link preview in a chat app. A naive count of property attributes across these 385 pages returns 2,850 occurrences, and a detector that treated each as RDFa would have reported that most of the web publishes RDFa.

It does not. Counting RDFa strictly, as a vocab attribute naming a vocabulary or a typeof attribute naming a type, gives one page. Counting Open Graph separately gives 359 of the 385, which makes it by a wide margin the most widely deployed machine readable block in the sample, more common than JSON-LD. Open Graph is not in Google's list of supported structured data formats, it carries no schema.org type, and it describes a title, an image and a description rather than a business, a product or an author. It is a preview card, and it does that job well.

The 122 pages that carry Open Graph and none of the three schema syntaxes are the group this distinction was worth drawing for. Those sites are not unaware of metadata. They have shipped a block deliberately, for a purpose they could see working, and they have shipped nothing an answer engine can lift a fact from. That gap sits underneath the separate problem of markup that says things the page does not, where 70 of 146 markup values were not on the page, and both feed the same question of how confidently a machine can tie a page to an entity. What Google says it needs for its own answer surfaces is set out on our page for AI Overviews.

What this does not measure

No JavaScript was executed, so a page that injects markup after load is counted as carrying none, and that is the correct reading for a fetcher that does not render but the wrong reading for one that does. Whether any of the 142 bare pages emits schema after rendering was not tested here.

One home page per site says nothing about the rest of that site. A product page, an article or a location page is where a storefront or a publisher would put its richest markup, and none of those were read. Each hostname was asked once, on one day, from one network location, so a site that varies its response by geography was seen from a single vantage point and a transient failure reads as permanent. 392 hostnames chosen by platform is 392 hostnames, not a random sample of the web, and the weighting toward small and mid sized sites is the reason the WordPress and Shopify strata are large enough to show microdata at all.

Most importantly, nothing here reports what any AI crawler does. No access log was read, no crawler was observed, and no operator of an AI crawler publishes which structured data syntaxes its parser accepts, so this post cannot tell you whether writing microdata instead of JSON-LD costs you anything with any specific engine. It can tell you what is on the pages, which is the part that is checkable. Aggregate figures from the scans this site runs are on the research page, and the vocabulary underneath all of this is defined in the glossary entry for generative engine optimization.