Only 16 schema.org types reach 10 million domains

What Schema.org published, and what a domain count actually counts

The About Usage Statistics page carries the version stamp V30.0 and the date 2026-03-19 in its footer, and describes the pipeline in three steps. Each step removes something a reader might otherwise assume is in the data, so all three are worth taking literally.

Gather. The page states that term frequencies are measured within Google's public web crawling infrastructure, and that data is aggregated at the domain level rather than by individual pages. It spells out the consequence itself: if you use the same term on 100 pages of your site, it still only counts as one domain using it. A figure of ten million domains therefore means ten million sites used the term at least once somewhere, and says nothing at all about how heavily any of them use it.

Group. Instead of exact numbers, domains are grouped into range buckets, for two stated reasons. The first is filtering out daily noise, because temporary server issues, network slow-downs, or minor website updates can make exact counts jump up and down daily. The second is protecting website privacy, on the grounds that exact numbers could allow competitors or bad actors to track minor changes on specific websites or reverse-engineer how search engines crawl the web.

Publish. An updated file is pushed to GitHub every month, and the page adds that each release requires manual validation and approval to ensure data quality and filter out anomalies before publication. That is a slower cadence than a scraper would give you and a more careful one.

Two further limits are stated plainly on the same page. The dataset does not separate JSON-LD from Microdata from RDFa, and the answer given is that they are all combined into a single stat, so nothing here tells you which serialisation the web prefers. And aggregation is by domain rather than by URL because, in the page's own words, URL counts and number of objects are very heavily influenced by the index composition in search indices. That is a search engine stating, inside its own dataset documentation, that a page-level count would largely be measuring its own index rather than the web.

The raw files sit in the canonical Schema.org repository under data/public_stats/google, at https://github.com/schemaorg/schemaorg/tree/main/data/public_stats/google, published as CSV and JSON carrying the same data plus a JSON summary of the bucket distributions. The announcement is at https://blog.schema.org/2026/06/04/announcing-the-schema-org-usage-statistics-dataset/. Both are given as plain text because neither host is one this site links to.

958 types, 4,587 properties, and 76 percent of them below 1,000 domains

Each monthly file holds 5,545 rows. Counting the July 2026 release gives 958 rows classed as Itemtype, which is a Schema.org type such as Product or Person, and 4,587 classed as Predicate, which is a property such as price or telephone. The May and June files carry the same 5,545 rows and the same split, so the vocabulary under measurement has not changed across the three releases. Only the buckets move.

The distribution is the finding. Of the 958 types, 470 sit in the lowest bucket of fewer than 1,000 domains, which is 49 percent of the type vocabulary. Of the 4,587 properties, 3,747 sit in that same bucket, which is 82 percent. Together, 4,217 of 5,545 measured terms, or 76 percent of everything Schema.org publishes a statistic for, are used by fewer than a thousand domains each. At the other end, 16 types and 36 properties reach the top bucket of more than 10 million domains.

Those counts are ours, taken from the CSV, and they agree exactly with the summary JSON that Schema.org distributes beside it. Reconciling a derived figure against the publisher's own aggregate is the cheapest check available on any dataset you intend to quote, and it is the one we would want done to a number of ours. It is also the reason we can put these figures in a post at all rather than withholding them.

Schema.org anticipates the obvious misreading and answers it on the same page. Asked whether a term in the lowest bucket means search engines ignore it, the stated answer is not necessarily: that bucket holds both brand-new terms and highly specialized terms, and because the total number of medical websites is small compared to the whole internet, such terms will naturally stay in the lower buckets. A long tail of rarely used terms is what a general purpose vocabulary looks like when it is working. It is not evidence that the tail is dead.

What the dataset does establish is a base rate, and a base rate is precisely what most structured data advice lacks. When a checklist tells you to add a type, this file now tells you whether that puts you among sixteen million sites or six hundred. Neither answer is automatically the right one for your page, but only one of them was previously knowable, and the difference matters when you are deciding where finite engineering time goes. Most published generative engine optimization advice has had to reason about markup without any base rate at all, which is part of why so much of it is assertion. It is the same reason we publish our own scoring method rather than a score alone.

The 16 types at the top, and why several of them are template output

Here are all sixteen, in the alphabetical order the file gives them: Article, BreadcrumbList, EntryPoint, ImageObject, ListItem, Offer, Organization, Person, PostalAddress, Product, PropertyValueSpecification, ReadAction, SearchAction, Thing, WebPage and WebSite.

Some of that list is unsurprising. Organization, Person, Product, Article and WebPage are the entities a page is usually about. Our own entity confidence diagnostic gates on the first of those, an Organization-family identity node, which is a setting we chose from a sample of cited pages rather than anything derived from this dataset. Google maintains a separate list of recommended properties for the Organization type, which is a useful reminder that a type appearing on ten million domains and a named consumer expecting particular fields inside it are two different facts. Others are structural: ListItem and BreadcrumbList are the breadcrumb pattern, and ImageObject and PostalAddress are the standard shapes for an image and an address rather than subjects in their own right.

Then there is a cluster that repays a second look. EntryPoint, PropertyValueSpecification and SearchAction are three of the sixteen, and in the property list the top bucket contains potentialAction, target, urlTemplate, query-input, valueName and valueRequired. Those nine terms are, between them, the fields of the sitelinks search box markup. ReadAction and potentialAction together are the other pattern that appears in this shape, emitted by content management platforms on ordinary pages.

The dataset cannot confirm that reading, and it is important to say why. Each row is an independent count of domains using one term, so nothing in the file records that two terms occurred on the same page, let alone inside the same node. What the file supports is that these nine terms each appear on more than 10 million domains. That they are the constituent fields of one well known pattern is a fact about the vocabulary, not a measurement of co-occurrence, and treating it as the latter would be the kind of inference this site tries not to make.

Read conservatively, the point still holds and it is worth holding onto: a large share of the most widely deployed markup on the web is boilerplate a template emitted, not description an author wrote. That is consistent with what we found opening real pages when we captured six storefronts on one day in July, and it is a useful corrective to advice that treats the presence of JSON-LD as evidence of effort.

Two absences are as informative as the list. FAQPage sits one bucket down, in 1 million to 10 million domains, which is lower than the volume of advice recommending it would suggest. And @id, the property that makes several nodes on a page into one linked graph, is not in this dataset at all, because it is a JSON-LD keyword defined by the JSON-LD 1.1 specification rather than a Schema.org term. Anything the dataset can tell you stops at the vocabulary boundary, and graph structure sits outside it. That boundary is not a technicality: reading the same JSON-LD two different ways can produce a perfect score and a zero on one page, and no census of term frequencies would ever surface the difference.

What changed between May and July, and why one release is not a trend

Three releases exist so far, dated May, June and July 2026. Comparing them term by term on 31 July 2026 gives 136 of the 5,545 rows in a different bucket in July than in May, which is 2.5 percent of the file. Split by release, 92 rows changed between May and June and 48 between June and July, and the arithmetic reconciles because exactly two terms moved and then moved back: customerRemorseReturnLabelSource and purchaseDate each crossed the 1,000 domain boundary in one direction and returned in the next release.

Those two are the useful ones. A term sitting near a bucket edge will cross it on noise alone, and the dataset's own explanation of why buckets exist says as much. So a single release tells you roughly where a term sits, and two consecutive releases moving the same way tell you a little more, but nothing here supports reading a one-bucket change as adoption. Anyone building a monitoring product on this file should treat a single crossing as unresolved rather than as an event, which is the same discipline that applies to sampling a small number of AI answers and calling the result a trend, as we set out in how many prompts a measurement needs.

The changes that survive that scepticism are the ones that moved once and stayed. Four types entered the top bucket over the two months: Offer, PostalAddress and Product in June, then Article in July. Two more climbed a bucket into 1 million to 10 million domains, SoftwareApplication and ProfilePage. Exactly three terms crossed two buckets in the two months, and none crossed three: the type BuyAction and the properties businessFunction and referenceQuantity all went from 10,000 to 100,000 domains straight into the 1 million to 10 million band. The remaining 128 rises moved one bucket.

Direction is not uniform, though it is lopsided. Five of the 136 moves were falls: LiveBlogPosting, PlayAction and masthead each dropped from 10,000 to 100,000 domains to 1,000 to 10,000, while RadioEpisode and paymentMethodType dropped into the lowest bucket. Falls are harder to interpret than rises, because a fall can reflect sites removing markup, sites going offline, or a change in what Google's index covers, and the dataset cannot distinguish those. That the file records movement in both directions at all is mild evidence it is measuring something rather than accumulating.

One structural caution applies to all of it. The vocabulary count has been identical across three releases at 958 types and 4,587 properties, which means no new Schema.org terms have entered the measured set in that window. A term released after the pipeline was built will not appear simply because nobody has used it yet, so absence from the file is not evidence a term does not exist.

The dataset says it captures no data on robots.txt blocked websites

The most consequential sentence on the documentation page is in the answer to how representative the statistics are. No single crawl can capture the entire internet simultaneously, it says, so all web-scale datasets inherit biases based on the crawler's scope and indexing methodology. These statistics reflect the web as indexed by Google. This also means that there is no data captured on robots.txt blocked websites, for instance.

That is a careful and creditable disclosure, and it defines the boundary of everything above. The dataset is a census of markup on sites that let Google's infrastructure in. Sites that do not are absent, and they are absent silently, indistinguishable from sites that publish no markup at all. For a general picture of vocabulary adoption that hardly matters. For the question this site exists to answer, it matters a great deal, because the excluded population is the one whose crawler access is actually in question.

That population is not static either. When we read the four platform properties Google added to Search Console, three of the four blocked AI crawler tokens outright, and blocking at the edge rather than in a file is becoming the default for whole classes of site, which is why two layers decide whether AI can read your site rather than one. A dataset built on an index is blind to all of it by construction.

There is a second gap, and this one the page does not address. It does not say whether markup was counted from the raw HTML a server returned or from the page after JavaScript ran. That distinction decides whether a JSON-LD node injected client-side is in these counts, and it is not a small distinction: Common Crawl's own FAQ states its crawler runs no JavaScript, which is why 2.14 billion pages were archived in July without it. If Google rendered and most AI crawlers do not, then a term can be well represented in this dataset and still be invisible to the clients a site owner cares about. We cap the schema contribution from client-injected markup in our own scoring for exactly that reason, and we would rather say the page is silent on this than guess which way it goes.

None of this is a criticism of the dataset. It is the correct reading of a file whose publishers told you where its edges are, and it is a better disclosure than most measurement in this field carries. The practical translation is narrow: this data tells you what markup the indexed web publishes. It does not tell you what any particular crawler received from your server, and no aggregate ever will, which is the gap our published research and a per-URL check are for.

What to take from this for your own markup

The honest use of a base rate is narrow, so here is what we think it supports and what it does not.

It supports a sanity check on coverage. If your pages describe an organisation, a product or an article and carry none of the sixteen types that more than 10 million domains use, that is worth a look, not because volume proves value but because being outside a pattern that universal usually has a cause and the cause is usually accidental. Our own diagnostic weights an identity node most heavily of the five signals it scores, and we re-derived those five against 30 pages in one day rather than choosing them by popularity. The two approaches agree more than they disagree, and where they disagree the dataset is the one measuring the web while our weights are a setting we chose.

It does not support chasing the tail. A term in the lowest bucket is not thereby useless, and Schema.org says so directly. Nor does it support the reverse move of adding types because they are common. Offer counts are high because a large share of the indexed web sells things, and Schema.org's definition of Offer is what decides whether your page has one, so emitting it where nothing is sold is markup that states something untrue in a form a machine will believe. The value of a type is whether it correctly describes your page, and that question was never a popularity question.

It supports being sceptical of one number in isolation. Two terms in this file crossed a bucket boundary and crossed straight back inside two months, and the publishers bucketed the data in the first place because exact counts jump around. Any tool that reports a Schema.org term as trending off a single release is reading noise.

And it leaves untouched the thing that decides whether any of this is read. Markup only reaches a model if the fetch succeeded, if the file allowed it, and if the content was in the response rather than assembled afterwards. Those are questions about your server and your robots.txt rather than about your vocabulary, they are the larger half of AI visibility, and they are answered per URL rather than in aggregate: a missing robots.txt and a broken one produce opposite outcomes for the same site, and neither shows up in a census. If you want to see what a crawler receives from a specific page, check what GPTBot gets rather than inferring it from what the web at large publishes.

One last note on provenance, since this post rests entirely on someone else's measurement. Everything above is either quoted from the Schema.org documentation or counted by us from the published CSV files, and our counts reconcile with the summary file Schema.org ships alongside them. We did not scan any site to write this, and nothing here is a Lantad measurement of the web.