Report
Where the vocabulary lives, and what makes a term catch on
Every one of Schema.org's real terms sits in a section, the field the vocabulary itself uses to say where a term is published. I group all 2,487 of them that way, and I group every property by a second fact, how many types Schema.org's own definition lists it as appearing on. Read together, the two answer a question you probably arrived with, whether the term in front of you was ever going to catch on.
- Real terms2,487
- Health, in the bottom band75.00%
- Properties1,529
- Attached to 1 type, in the bottom band52.56%
Where the vocabulary lives
July 2026 · six ranges, no exact numbersGoogle and the Schema.org community, Schema.org usage statistics dataset. Websites in Google's index.
Core holds far more terms than any other section, 1570 of them, and 35.03% sit in Google's bottom band, the smallest of its six usage ranges, meaning fewer than a thousand websites use the term. Health is the exception worth naming. It is the largest of the five named extensions, holding 280 terms, and 75.00% of them sit in that same bottom band, more than double core's share. Health is the largest extension field Schema.org publishes, and it is the one the web has adopted the least.
This grouping is different from the one the industry pages on this site use, and it is worth telling apart if you have read both. Those pages sort types by ancestry, walking each one back through the vocabulary's own class hierarchy to a named vertical, and medical and health comes out with 88 types that way. Section groups every kind of term, not just classes, by a completely different fact, which part of the vocabulary Schema.org chose to publish it in. Medical and health holding 88 types by ancestry and the health section holding 280 terms by section are both correct. Meet both without knowing they measure different things, and you would reasonably read them as disagreeing.
Section needs no defending the way a derived grouping does. It is not judged and it is not walked from anything. It is read straight off the field Schema.org publishes on every term, and you can go and check it on schema.org yourself.
| Section | Terms | In the bottom band |
|---|---|---|
| Core | 1570 | 35.03% |
| Pending | 569 | 62.74% |
| Health | 280 | 75.00% |
| Bibliographic | 25 | 76.00% |
| Automotive | 24 | 37.50% |
| Attic | 12 | 83.33% |
| Machinery | 6 | 83.33% |
| Unpublished | 1 | 100.00% |
| All sections | 2,487 | 46.68% |
Add every section's bottom-band count back together and you get 1,161 terms out of 2,487, the same 46.68% I publish everywhere else on this site as the corrected share below a thousand websites.
Two of the sections are small enough to read carefully. Attic and machinery, the vocabulary's own housekeeping areas, hold 12 and 6 terms, and both land on exactly 83.33% by coincidence. A group that small moves a lot when a single term moves, so treat that particular number more cautiously than core's or health's.
What makes a term catch on
July 2026 · six ranges, no exact numbersGoogle and the Schema.org community, Schema.org usage statistics dataset. Websites in Google's index.
A property's breadth is how many types Schema.org's own definition lists it as appearing on, from a single type up to dozens. Group properties by that breadth, and adoption climbs in a straight line. Attached to one type, a property sits in the bottom band 52.56% of the time. Attached to two or three types, that drops to 28.29%. Attached to four to nine, it drops again to 11.24%. Attached to ten or more, none of the 3 properties in that group sit in the bottom band at all. Every step up in breadth is a step down in how often a property goes unused, without a single exception across the four groups.
That pattern makes sense once you think about what breadth means in practice. A property defined on only one type has exactly one place it can ever be written, one type on one page. A property defined on ten or more types has ten separate places producing examples, documentation and tooling that all reinforce the same field name. Breadth looks less like a reward for popularity and more like a cause of it, because a property with more places to appear has more chances of being the one a developer already needs.
I could have summarised each group with a single number instead of a table, averaging where each property's band sits on Google's ordered list of six. That produces a tidy-looking climb of its own, and it is tempting to publish precisely because it looks like the same finding in less space. I am not publishing it. A band is a position in an ordered list, not a quantity of websites, so averaging the positions gives you a figure with no unit and nothing real underneath it, the mean of a label rather than a measurement of anything. The bottom-band share above is a real proportion of properties, it climbs in the same direction, and you can check it yourself by counting rows in the download.
| Attaches to | Properties | In the bottom band |
|---|---|---|
| 1 type | 1132 | 52.56% |
| 2 to 3 types | 304 | 28.29% |
| 4 to 9 types | 89 | 11.24% |
| 10 or more | 3 | 0.00% |
| All groups with a figure | 1528 | 45.22% |
If you are choosing between two ways to model the same fact, and one already has a broadly attached property while the other would need a narrow new one, the broadly attached property is usually the safer bet. Not because it is better designed, but because more of the web already has a reason to write it. That does not make a narrowly attached property wrong to reach for. Some exist precisely because a broader property would not say the specific thing accurately enough, and precision is sometimes worth more than borrowed adoption.
One property carries no figure for this at all, interactionCount, so it is left out of every group above rather than folded into "1 type", because carrying no figure is not the same claim as carrying one. The widest group is also the smallest sample. Only 3 properties attach to ten or more types, so their 0.00% is a count of three, not a rate stable enough to treat the way the bigger groups' shares are.
How this is measured
I build both groupings from the same file behind the term-by-term table elsewhere on this site, which joins Google's monthly usage archive to a pinned copy of the Schema.org vocabulary. Section comes straight from that vocabulary's own field, so grouping by it needed no judgement call, unlike the ancestry walk the industry pages use to sort a type into a vertical. Breadth comes from counting how many types Schema.org's own definition lists a property as appearing on, which is also read directly rather than inferred from anything.
For both groupings I then read each term's band from the July 2026 snapshot and counted how many sit in the bottom band, under a thousand websites, as a share of the group. Every share on this page is arithmetic on the counts already shown in the table above it, nothing hidden and nothing estimated.
Two different kinds of number sit side by side here. The section and breadth counts are exact, because they come from counting rows in a published file. The bottom-band share is exact as a proportion too, but it only tells you whether a term crossed one threshold, not how far below it sits or whether it has ever moved. A term used by nine websites and a term used by nine hundred are counted exactly the same way on this page. We cannot tell from band data alone why a widely attached property gets used more, only that it does, every time, across every group here.
You can download the same figures as JSON or the wider dataset and check any number on this page against them.
Snapshot July 2026. Built 19 August 2026.
Analysis © Eduard Dziak, licensed under the Apache License 2.0. Please credit eduarddziak.com with a link. Source data: Google and the Schema.org community, Schema.org usage statistics dataset. Rich result requirements: Google Search Central, licensed CC BY 4.0. Term descriptions: Schema.org, licensed CC BY-SA 3.0, each term linking to its own page. Crawl counts: HTTP Archive Web Almanac, licensed Apache License 2.0.