Google’s Merchant Listing structured-data guidance now gives ecommerce sites a page-level way to publish product categories and sale windows that previously mainly lived in Merchant Center feed attributes. The practical change is not a new feed specification: it is a template, promotion-data, and feed-parity problem for teams that want product pages to express the same category and pricing facts as their feeds.
For GEO work, that distinction matters. The update adds more machine-readable commerce detail to the page, but the supplied reporting does not establish a direct ranking benefit, nor does it establish that adding these properties earns AI citations or inclusion in AI shopping answers. The defensible reason to implement it is data consistency and more precise product information for Google’s merchant listings, not a claimed shortcut to AI visibility.
What Google actually added
The largest addition is Product.category, a recommended rather than required property. It lets a merchant classify a product in on-page markup instead of relying solely on feed attributes. The property accepts plain text, a CategoryCode object, or an array that mixes both formats. searchenginejournal.com
Plain-text category values correspond to the role of product_type in product feeds: they are the merchant’s own category labels. Google recommends keeping custom product types below 750 characters. searchenginejournal.com This is the low-friction option when a catalogue already has stable internal taxonomy strings and the structured-data renderer can expose them reliably.
CategoryCode is the more consequential option for feed parity. It uses inCodeSet to identify a Google Product Taxonomy URL and codeValue for either a numeric Google Product Category ID or the complete category path. This directly corresponds to the google_product_category feed attribute. searchenginejournal.com
The second change is new sale-duration documentation for three existing schema.org properties: validFrom, validThrough, and priceValidUntil. Google describes these as a way to state when a sale price begins and ends, using ISO 8601 dates. A listing may not display if priceValidUntil is in the past. searchenginejournal.com
That is an important wording difference from “Google introduced three new required fields.” The sources describe new guidance and support changes, not a change that makes these fields mandatory. Source reporting also says the update aligns page markup with existing feed attributes—product_type, google_product_category, and sale_price_effective_date—rather than changing Merchant Center feed requirements. digitalxkochi.com
Which product templates need changes
Start with the template that emits Product JSON-LD for purchasable product-detail pages. The required engineering decision is where category data comes from. A catalog with both an internal taxonomy and a maintained Google Product Category mapping should generally expose both, because Google permits multiple category values and mixed plain-text and CategoryCode values. searchenginejournal.com
That does not mean dumping every navigational breadcrumb, collection, and merchandising label into category. The guidance supports multiple values, but the operational goal should be a clear representation of the two category systems already used by commerce operations: the store’s custom type and its Google Product Category mapping. The source material does not provide a recommended number of category values or evidence that more values produce better visibility.
A sensible template audit has four paths:
- Standard PDP template: add category output from the product-information model, with a plain-text custom type and, where available, CategoryCode derived from the Google Product Category mapping.
- Variant-aware PDP template: verify whether category is inherited from the parent product or needs variant-level sourcing. The supplied sources do not resolve this modelling choice, so it should follow the catalogue’s actual data structure.
- Sale or promotion template: render sale dates only when the page has an active price window and ensure those dates correspond to the displayed active price.
- PriceSpecification-based template: place dates differently from a simple Offer implementation; this is where generic schema snippets are most likely to be wrong.
The update is especially relevant where schema is generated separately from the feed. If a CMS, commerce platform, tag manager, or schema app has its own category field, compare it directly with the feed export. The new property closes the former gap between on-page categorization and the feed, but only if both implementations draw from the same governed mapping. searchenginejournal.com
Sale duration is a data-model issue, not a date-field patch
Google’s placement rules are exact. If the price on an Offer node represents the current active sale price, add validFrom and either validThrough or priceValidUntil to that Offer node. searchenginejournal.com
If the sale price is defined on a PriceSpecification node—typically one without priceType when a StrikethroughPrice value is also present—put validFrom and validThrough on that specific PriceSpecification node. Google’s guidance says priceValidUntil does not apply to PriceSpecification. searchenginejournal.com
This means the ecommerce feed or promotion service needs to provide more than a current price. Templates need access to a promotion start timestamp, an end timestamp, timezone information, and an indication of which schema price object represents the sale. Google recommends providing both a start and end date/time, requires the start to be earlier than or equal to the end, and recommends including time and timezone for accuracy. searchenginejournal.com
For feeds, compare those fields against sale_price_effective_date. The source reporting frames sale duration as the page-level counterpart to that existing feed attribute. searchenginejournal.com Do not manufacture dates for evergreen discounts, unclear promotional rules, or prices that are not actually time-limited. The sources do not say that every discounted item needs sale-duration markup.
What this means for GEO, and what it does not
For a GEO practitioner, category and sale duration make product entities and offer states more explicit in the page’s structured representation. That is useful architecture: the page, feed, and product taxonomy can describe the same thing rather than requiring a system to reconcile conflicting labels or stale sale data.
But the evidence here stops there. One source argues that structured data can help AI systems understand products and discusses future AI-driven shopping surfaces, but it does not provide a measured outcome for these new fields. digitalxkochi.com Another source explicitly says structured data is not a direct ranking factor. seovendor.co Neither source demonstrates a causal link between Product.category or sale-duration markup and AI-answer selection.
So I would classify this as schema hygiene with merchant-listing relevance, not a standalone GEO tactic. Implement it where the catalogue has authoritative data and the template can maintain it. Treat it as a failure if it introduces feed/page disagreement, expired dates, or incorrectly scoped price properties.
A controlled rollout plan
- Inventory every PDP schema renderer and identify whether it uses Offer, PriceSpecification, or both.
- Map the source of each custom product type and Google Product Category value; expose CategoryCode only where the mapping is authoritative.
- Map promotion start and end timestamps from the same source used for feed sale windows, including timezone.
- Test standard-price, active-sale, scheduled-sale, expired-sale, and variant product cases before template-wide deployment.
- After rollout, monitor for invalid merchant-listing items and investigate discrepancies between the visible page, markup, and feed.
The important implementation discipline is simple: a product page should not say one category or sale window in markup while the Merchant Center feed says another. Google’s new guidance finally gives teams the fields to align them. It does not remove the need to govern the underlying product and promotion data.