Schema.org 30.1 Structured Data Update: What It Changes for SEO

What Schema.org 30.1 Actually Added

The 30.1 release expands Schema.org in two areas that are particularly relevant to product data teams.

More Vocabulary for Retail and Product Data

Schema.org added consumerNotice, isOftenBoughtWith, and specification for Product. It also added itemPopularity for Offer, minimumOrderValue for ShippingRateSettings, valueGroup for PropertyValue, and the MaximumRetailPrice value for PriceTypeEnumeration. The existing provider property can now also be used with OfferShippingDetails.

That is a meaningful vocabulary expansion for retailers, marketplaces, feeds, and systems that exchange detailed product information. It does not mean every property should be added to every product page. A property is useful only when the underlying data exists, describes the page or entity accurately, and has a consumer that can use it.

Digital Product Passport Vocabulary Moves Into the Release

Version 30.1 also introduces DigitalProductPassport and hasDigitalProductPassport, along with EnvironmentalProductDeclaration and DeclarationOfConformity as certification-related types. Other additions include authorizedRepresentative, importer, recycledContentPercentage, and substanceOfConcern.

This gives publishers and product-data systems more ways to describe information associated with EU Digital Product Passports. The SEO implication needs restraint: Schema.org has defined the vocabulary, but that fact alone does not establish a new Google Search treatment, a ranking signal, or an AI Search advantage.

The Release Does Not Automatically Expand Google Rich Results

This is the point most likely to be missed in implementation planning. Schema.org is a shared vocabulary. Google Search selects the types and properties it supports for particular Search features and documents those separately.

As of 20 September 2026, Google’s merchant listing documentation does not list the newly added 30.1 properties such as consumerNotice, isOftenBoughtWith, itemPopularity, or minimumOrderValue among the documented merchant-listing properties. That does not make the Schema.org terms invalid. It means Google Search support should not be claimed without separate documentation.

Google’s own update history shows why the distinction matters. On 7 July 2026, Google documented support for the Product.category property in merchant listings and clarified sale-price effective dates. That was a Google Search documentation change with a stated Search and Shopping use. Schema.org 30.1 is a different event from a different layer.

What E-Commerce Teams Should Do With the New Vocabulary

The first question is not ‘Can we add the new properties?’ It is ‘Which system needs this data, and is the source data reliable enough to publish?’

For Google Search, the higher priority remains the product information Google currently documents. Depending on the page and merchant setup, that can include price, availability, product identifiers, category, shipping information, return policies, product variants, and supported loyalty or member-pricing information. Google also recommends organisation-level markup for merchant policies where appropriate.

The 30.1 additions can be evaluated separately. For example, a retailer with a genuine minimum-order rule may eventually have a useful reason to model minimumOrderValue. A marketplace may have a real data source for isOftenBoughtWith. A manufacturer working with Digital Product Passport data may need the new product and certification relationships for interoperability outside a Google rich result.

What should not happen is a blanket deployment because the terms are new. That creates another maintenance surface before the business has established who owns the values, how they are updated, and which downstream system reads them.

A practical order of work is:

1. Protect current Google-supported markup first. Check whether visible product data, Merchant Center data, structured data, shipping policies, and return policies agree.
2. Map the new Schema.org fields to real source data. Do not infer a consumer notice, popularity value, minimum order threshold, or compliance attribute merely to fill a property.
3. Decide who consumes the new data. Schema.org validity is useful, but a production requirement should have a defined purpose beyond ‘more schema’.
4. Pilot before template-wide deployment. Test representative products and make sure the additions do not create conflicting entities or stale values.

AI Search Does Not Create a Separate Schema Layer

Google’s generative AI Search guidance is unusually clear on this point. The company says its core SEO practices continue to apply to AI Overviews and AI Mode, and that structured data is not required for generative AI Search. It also says there is no special Schema.org markup that site owners need to add for those features.

That changes how the 30.1 release should be discussed. The new vocabulary may improve the precision of a site’s data model where the terms genuinely fit. It should not be sold as a method for securing AI citations, AI Overview inclusion, or higher rankings.

Google still advises keeping structured data consistent with visible content, and structured data remains useful for supported rich-result eligibility. The operational value is therefore narrower and more defensible: maintain accurate machine-readable information for the features and systems that actually use it.

For teams measuring AI Search, use the reporting that Google makes available rather than treating schema deployment as a proxy for AI performance. If AI visibility changes after a markup release, that correlation alone does not establish that the markup caused the change.

Use Different Tests for Different Questions

A Schema.org release creates a validation problem because one validator cannot answer every implementation question.

• Use the Schema.org Validator when checking whether new Schema.org vocabulary is expressed correctly.
• Use Google’s Rich Results Test for markup intended for a Google-supported rich result or Search feature.
• Use the relevant Google feature documentation to confirm which types and properties Google actually supports. A green Schema.org validation result does not create Google feature eligibility.
• Check the rendered page and live data source before rollout. Correct syntax is not enough if the visible price, policy, product relationship, or certification information disagrees with the markup.

Large sites should add one more check: compare several URLs from the same template after deployment. Product data tends to fail at scale through feeds, CMS mappings, and shared templates, not because one hand-tested JSON-LD example was invalid.

What to Watch After Version 30.1

There are now two separate update streams worth monitoring. Schema.org may continue expanding its product and Digital Product Passport vocabulary. Google may independently adopt, ignore, or document selected Schema.org properties for Search features.

That means a sensible watch list is short:

• Google Search Central structured data documentation and its update log for newly documented property support;
• Google merchant listing and product documentation for changes to shopping eligibility and enhancements;
• future Schema.org release notes for changes to the 30.1 vocabulary;
• template and feed changes that could make existing markup inconsistent with visible product information.

The release is worth reviewing, especially for organisations with complex product data. Implementing every new term for SEO is premature. The stronger approach is to separate vocabulary support, Google Search support, and internal data requirements, then deploy only where those three layers justify the work.