Schema.org 30.1 brings e-commerce vocabulary and Digital Product Passport

Schema.org published version 30.1 of its vocabulary on September 16, 2026, according to the official changelog at schema.org/docs/releases.html. It is not a structural overhaul: it is a maintenance release, but it carries three moves that matter directly to anyone who writes structured data with an eye on appearing in traditional search results and in generative search engine answers.

The first move is a finer-grained vocabulary for Product, aimed at retail feeds. The second is the arrival of classes for the European Union's Digital Product Passport (DPP). The third, which started in version 30.0 and keeps maturing, is the equivalence annotations with GS1, Dublin Core, and Open Graph. None of these three points is cosmetic: they touch exactly the kind of data a generative AI system needs to cite a brand with confidence in an answer.

The new product fields worth marking up first

Version 30.1 adds a package of properties designed for what the changelog calls "common retail feed data," that is, the fields that already exist in the e-commerce feeds of major advertising platforms and that now get a formal counterpart in the open vocabulary. In Product, consumerNotice arrives (a notice to the consumer, such as a recall or usage restriction), along with isOftenBoughtWith (a product frequently bought together) and specification. In Offer, itemPopularity arrives. In ShippingRateSettings, minimumOrderValue arrives.

In short: these fields describe relationships between products and purchasing behavior, not just the product in isolation, and this is exactly the kind of information an AI-generated answer uses to build a comparative recommendation ("X is often bought with Y," "X is the most ordered item in this category").

A practical markup example, combining two of the new fields:

{
 "@context": "https://schema.org",
 "@type": "Product",
 "name": "Cabo USB-C 2m",
 "isOftenBoughtWith": {
 "@type": "Product",
 "name": "Carregador rápido 65W"
 },
 "offers": {
 "@type": "Offer",
 "price": "49.90",
 "priceCurrency": "BRL",
 "itemPopularity": 0.92
 }
}

It's worth noting that PropertyValue also gained valueGroup, and that the value of PropertyValue now accepts QualitativeValue. In practice, this makes it easier to mark up qualitative variations of a product (size "S/M/L," for example) without resorting to free-text workarounds, which helps an automated extractor understand that this is a range of options, not a loose description.

Digital Product Passport: European vocabulary already appearing in Brazilian catalogs

The second block in 30.1 wraps up work started in version 30.0 (released on March 19, 2026): the vocabulary for the Digital Product Passport (DPP), a European Union regulatory requirement for product traceability. 30.1 adds the DigitalProductPassport class and the hasDigitalProductPassport property, applicable to both Product and Offer. Along with it come EnvironmentalProductDeclaration and DeclarationOfConformity, both subtypes of Certification, plus authorizedRepresentative (for Product and Organization), importer, recycledContentPercentage, and substanceOfConcern, the last three directly on Product.

Anyone who sells exclusively to Brazil might find this remote, but the reading that matters here is different. Brazilian brands that export, or that compete in marketplaces with a European presence, will already find these fields filled in on competitors' catalogs. A generative search system comparing "which product has the smallest carbon footprint" or "which supplier declares conformity" will prefer to cite whoever already answered that question in structured data, not whoever just mentions it in running text on the page.

The bridges with GS1, Dublin Core, and Open Graph matter more than they seem

The least flashy point in the changelog is, in my reading, the most relevant for GEO: version 30.0 added equivalence and export annotations for the GS1, Dublin Core, and Open Graph vocabularies. This means schema.org itself now formally declares where one of its terms corresponds to a term in these other standards.

Why does this matter to someone who doesn't work with RDF day to day? Because information retrieval systems, including those that power AI-generated answers, frequently cross-reference data coming from different sources: a page marked up in schema.org, a product feed in GS1, Open Graph metadata from a social network. When these vocabularies declare equivalence with each other, it becomes cheaper for any system to normalize these three sources as "the same fact," instead of treating them as disconnected signals.

This isn't something you implement on your site: it's an adjustment to the interpretation layer that benefits whoever already uses Product, Offer, and similar types consistently. The practical action here is indirect: keeping the page's Open Graph aligned with schema.org (same name, same image, same price) has stopped being just good social media practice and has become a signal that the vocabulary ecosystem itself treats as redundant and trustworthy.

Other changes bundled into the same release

Beyond the e-commerce and DPP blocks, the September release brought smaller items worth noting:

• Explicit support for ordered lists, documented in an official blog post linked to the changelog, useful for anyone marking up recipes, tutorials, and step-by-step guides in HowTo or ItemList.
• Promotion of terms that were in "pending" status to "GA" (generally available), based on real adoption data, which Schema.org itself also reported in a blog post about term usage statistics.
• New values Ophthalmology and Audiology in the MedicalSpecialty enumeration, of interest to healthcare.
• Extension of OfferShippingDetails with the provider property, and a new MaximumRetailPrice value for PriceTypeEnumeration.

It's worth recalling the recent history: version 29.4, from December 8, 2025, had already created ConferenceEvent as a subtype of Event and added cross-referenced examples with the GS1 web vocabulary and UN/CEFACT, a move that 30.0 and 30.1 deepen.

How to prioritize implementation and measure results

Not every new field deserves to go into your JSON-LD tomorrow. A reasonable priority order, weighing effort against signal for search and generative AI:

1. If you have a product catalog, implement isOftenBoughtWith and itemPopularity first: they connect most directly to comparative questions a user would ask an AI assistant.
2. Validate everything in Google's Rich Results Test and the official schema.org validator before publishing; a badly formatted new field is worse than a missing one.
3. If you export to the European Union, review the DPP vocabulary with your legal team before marking up substanceOfConcern or recycledContentPercentage: these are data points that become a conformity declaration.
4. Audit the page's Open Graph against schema.org: name, image, and price need to match, since the ecosystem now treats this as formal equivalence.

To measure impact, the path is the usual one: track impressions and clicks by rich result type in Search Console before and after publishing, and, on the generative side, monitor whether the brand starts being cited in answers from tools like AI Overviews or search assistants for the target queries. There is no dashboard today that isolates this second effect with precision: the practical approach is to test the query itself manually, on a periodic basis, and log the change.

What schema.org still doesn't solve

None of these changes force a generative AI system to cite a page. The vocabulary only makes information easier to extract and harder to misinterpret; the decision to cite still depends on criteria from the model or search engine itself, which Schema.org doesn't control and doesn't document. Correct structured data is a necessary, not sufficient, condition for appearing in a generative answer.

Source: Official Schema.org release notes (schema.org/docs/releases.html).