826 Schema Types, About 30 Google Features
Quick answer: Schema.org 30.1 shipped on 16 September 2026 with a batch of new product and compliance vocabulary. None of it appears in Google's documented search features, and Google's own guidance tells you to treat its documentation as definitive over schema.org's. The vocabulary and the feature list are on separate release cycles, and only one of them changes what your result looks like.
Schema.org currently defines 826 types, 1,540 properties, 96 enumerations and 544 enumeration members. Google's structured data gallery documents roughly 30 search features. Those two numbers are the entire subject of this post.
The gap is not a bug or a backlog. Schema.org is a shared vocabulary with several consumers, of which Google Search is one. But it produces a steady stream of announcements that read, to anyone running an SEO programme, like new opportunities — and most of them are not.
What 30.1 actually added
The release, dated 16 September 2026, covers two themes plus miscellany. On the compliance side it introduces DigitalProductPassport, EnvironmentalProductDeclaration and DeclarationOfConformity as subtypes of Certification, with hasDigitalProductPassport, authorizedRepresentative, importer, recycledContentPercentage and substanceOfConcern to describe them. That is EU regulatory vocabulary, and it exists because the Digital Product Passport is becoming a legal requirement for some product categories, not because a search engine asked for it.
On the retail side it adds consumerNotice, isOftenBoughtWith and specification on Product, itemPopularity on Offer, minimumOrderValue on ShippingRateSettings, and valueGroup on PropertyValue. There is a new MaximumRetailPrice enumeration member for priceType, a couple of range extensions, and two additions to the medical specialty list.
Look at itemPopularity for a second, because it is the one most likely to get marked up speculatively. A property that lets you declare how popular an offer is, consumed by nothing you can verify, and self-reported by the seller. If that sounds like a ranking signal, consider why no search engine would treat it as one.
Google says to read its docs, not schema.org's
This is stated plainly in Google's introduction to structured data: "Most Search structured data uses schema.org vocabulary, but you should rely on the Google Search Central documentation as definitive for Google Search behavior, rather than the schema.org documentation."
That is an unusually direct instruction from a company that normally hedges. It exists because the confusion is common and expensive. A type existing in the vocabulary, validating in a parser, and rendering green in a testing tool tells you the markup is well-formed. It does not tell you any search feature consumes it.
The same page pushes back on the completionist instinct: it is "more important to supply fewer but complete and accurate recommended properties rather than trying to provide every possible recommended property with less complete, badly-formed, or inaccurate data." Note that this is about recommended properties within a supported feature — Google is saying that even inside the supported set, more is not better.
How a property actually becomes real
There is a clean worked example from the same month. On 24 September 2026 Google's documentation changelog recorded support for the creator property in VideoObject, plus an update to interactionStatistic. That property already existed in schema.org. Nothing about the vocabulary changed. What changed is that Google documented it as something it reads for a specific feature — and even then it is recommended, not required. We covered what that change does and does not get you separately.
So the sequence is: schema.org defines a term, sometimes years pass, and then a search engine documents that it consumes it for a named feature. Only the second event is actionable. Watching schema.org releases for SEO purposes is watching the wrong feed; the dated documentation changelog on Google's side is the one that predicts what your results will look like.
Traffic runs the other way too. Google removed FAQ rich results for most sites in 2026 while FAQPage remained a perfectly valid schema.org type — the vocabulary did not move an inch and the feature disappeared anyway. What schema is still for after that removal is a more useful question than which new types to add.
A decision rule for a new schema.org term
| Situation | Do |
|---|---|
| Named in a Google feature doc, required | Ship it, and validate it |
| Named in a Google feature doc, recommended | Ship it only if the data is accurate and already on the page |
| In schema.org, not in any Google doc, but a non-Google consumer needs it | Ship it for that consumer; expect nothing from Search |
| In schema.org, no known consumer | Skip it, and revisit when someone documents reading it |
The third row is the one people forget exists. The EU Digital Product Passport vocabulary has a real consumer — regulators and supply-chain systems — and if you sell physical goods into the EU, 30.1 may matter to you a great deal. It just will not change your snippet.
The failure mode worth avoiding
Speculative markup is not merely inert. Google's guidance is explicit that you should not add structured data about information that is not visible to the user, even if the information is accurate, and should not create pages purely to hold structured data. Both rules bite hardest on templated pages, where a generator emits a property for every record whether or not the underlying page shows it.
For a directory or comparison site that is a live risk rather than a theoretical one, and it sits next to the wider question of what makes a generated page worth publishing at all — the same territory as scaled content abuse and the publish gate for programmatic pages. The specific case of star ratings on software listings is worth reading if you aggregate community signals, because upvotes are not an aggregateRating and marking them up as one is exactly the kind of accurate-but-wrong data this guidance targets.
What to do with your existing markup
Audit for subtraction rather than addition. Pull the JSON-LD from a representative page of each template, list every type and property emitted, and mark each one against a documented Google feature. Anything unmatched is either serving a non-Google consumer you can name, or it is payload. Removing payload shrinks your HTML, removes a class of stale-data bug, and costs nothing in Search.
Then make sure the basics are correct on every template, because that is where the returns actually are. Breadcrumbs, a correct Organization block on the site, and clean article metadata do more than any amount of exotic vocabulary. The free breadcrumb schema generator and HowTo schema generator on TechLogHub produce the supported shapes directly, and the meta tag generator covers the non-JSON-LD half that people skip. If you are evaluating tooling for this, the SEO and content category is sorted by what tools do.
Set a reminder to read Google's search updates log monthly, and let schema.org releases pass without action unless a named consumer of the new terms has appeared. Version 30.1 is a good release. It is also, for almost every site reading this, nothing to do.
FAQ
Does adding unsupported schema.org properties hurt my rankings?
Valid markup that Google does not consume is generally inert rather than penalised. The risk is not the unused property itself but the practices that tend to accompany it: describing information that is not visible on the page, or emitting data that is inaccurate because nobody checks a field that has no visible effect. Both are things Google's guidelines address directly.
How many structured data features does Google actually document?
Around 30 in the search gallery, plus a couple of shopping sub-features such as merchant return and shipping policies. These are features rather than types: a single feature may involve several schema.org types, and a single type may serve more than one feature.
If a property validates in a testing tool, does that mean Google uses it?
No. Validation confirms the markup is syntactically correct and conforms to the vocabulary. Whether a search feature consumes it is a separate question answered only by the feature documentation, which is why Google tells site owners to treat its own docs as definitive over schema.org's.
Should I mark up the new Digital Product Passport types?
Only if you have a compliance or supply-chain reason to. That vocabulary was added for EU regulatory purposes and is not part of any documented Google search feature, so it will not change how your pages appear in results.
Which feed should I watch for structured data changes?
Google's dated documentation updates log, not schema.org's release notes. The September 2026 VideoObject creator entry is a good example: the property was already in the vocabulary, and the actionable event was Google documenting that it reads it.
Is more structured data better within a supported feature?
Google says no. Its guidance is to supply fewer but complete and accurate recommended properties rather than every possible one with less complete or badly formed data. Completeness of the properties you do emit beats coverage.
A vocabulary release is an offer, not an instruction. The only structured data that changes anything is the kind a named consumer has said, in writing, that it reads.