Schema.org 30.1 Product Fields Pass Google Parsing but Fail the Public Validator

Schema.org 30.1 adds six useful commerce properties, but adding them to a Product page does not automatically create a Google rich-result feature. In our September 17 compatibility test, Google’s Rich Results Test parsed the new fields while the public Schema.org validator reported all six as unrecognized. The mismatch is a deployment-timing problem, not permission to ignore validation.

The test card

• Date: September 17, 2026.
• Fixture: one synthetic Product with an Offer, PropertyValue and ShippingRateSettings object.
• New properties: consumerNotice, isOftenBoughtWith, specification, valueGroup, itemPopularity and minimumOrderValue.
• Tools: the public Schema.org validator and Google Rich Results Test.
• Question: can the current tools parse the vocabulary, and does parsing establish feature eligibility?

What the six fields are for

The release also expands work around European digital product passports and ordered lists. Those additions matter for product-data interoperability, but they do not mean Google has created corresponding Search treatments.

The public Schema.org validator rejected the new vocabulary

The public validator returned six errors, one for each new property. It said the properties were not recognized for their respective types. We captured the full result rather than treating the red status as proof that the release notes were wrong.

This result is consistent with a validator deployment that has not yet loaded the latest vocabulary. Validators, documentation and consuming products can update on different schedules. The safe response is to preserve the test date and tool result, then retest after the validator changes.

Google parsed the fields, with two important traps

Google’s Rich Results Test displayed the new properties in its parsed Product data. It did not flag those six property names as unknown. That is useful compatibility evidence, but it is not the same as documentation that Google uses the fields for ranking, rich results, AI answers or Merchant Center.

The Product snippets view considered the main product eligible and returned only optional warnings for a missing review and aggregate rating. The Merchant listings view was invalid because our synthetic fixture intentionally omitted an image and other recommended commerce details. It also objected to the ShippingRateSettings object in the shipping-rate position. Google’s product documentation does not list the six new properties among its required or recommended rich-result fields.

The nested product linked through isOftenBoughtWith produced a second detected Product item. Because that small nested object had no offer, review or aggregate rating, Google marked it invalid. Publishers should not add a skeletal related Product object and assume it will remain a harmless relationship field.

Keep vocabulary, parsing and feature support separate

1. Vocabulary: Schema.org defines a property and the types on which it can be used.
2. Parsing: a validator or consumer can read the property without treating it as malformed.
3. Search feature support: Google documents a field as required, recommended or otherwise used by a specific feature.

A page can pass one layer and fail another. The latest vocabulary can temporarily fail a lagging validator. A parser can retain a property without using it in a visible search feature. A rich result can remain invalid because an older required field is missing.

A deployment protocol for production sites

1. Confirm that each value appears in visible page content and is accurate for the specific product or offer.
2. Keep the existing Google Product baseline, including name, image, offers, price, currency, availability and applicable shipping details.
3. Add one new property at a time in a staging fixture and save the raw JSON-LD.
4. Run both validators, record the date and distinguish unknown vocabulary from feature-eligibility errors.
5. Inspect whether nested entities become separate detected items.
6. Publish to a small page set, monitor Search Console enhancements and retain an easy rollback.
7. Do not claim an SEO or AI-visibility lift without a controlled observation design.

Download the exact JSON-LD compatibility fixture used for this test. It contains invented product data and should not be copied into a live catalog without replacing every value.

What we would ship today

We would use consumerNotice and specification when they make a genuine product record more portable, while retaining visible notices and conventional Product markup. We would treat isOftenBoughtWith more cautiously because the nested Product surfaced as its own detected item. We would only add itemPopularity with an internally documented denominator and period, not a vague popularity claim.

For shipping logic, Google’s documented Merchant listing properties remain the feature contract. A new Schema.org property can enrich a broader knowledge graph without replacing Google’s specified structure.

Verdict

Schema.org 30.1 is usable vocabulary, not a new Google feature announcement. Our fixture shows that Google’s parser can retain the fields even while the public Schema validator lags. The test also exposes a real implementation risk: a nested related product can create another detected Product that must stand on its own.

Sources checked: Schema.org release history, latest vocabulary, Google’s Product snippet and Merchant listing documentation. The fixture is synthetic and tests parsing behavior on one date; it does not measure ranking, traffic or AI citations.