How Sale Dates and Product Categories Work in Merchant Markup

Google’s merchant listing structured data guidance now covers two pieces of product information that often live outside the page markup: when a sale price applies and how a product is categorized. Together, the additions give merchants a clearer way to keep product pages, structured data, and Merchant Center submissions conceptually aligned.

The practical value is not simply having more properties to publish. It is being able to represent promotional timing and product classification consistently, without treating structured data as an isolated SEO layer.

Key takeaways

• Google’s updated guidance explains how validFrom, validThrough, and priceValidUntil can describe the effective period of a sale price.
• The timing properties may be placed on Offer or PriceSpecification nodes, according to the supplied CrushPress.AI report.
• Product.category can use merchant-defined text or CategoryCode values associated with a formal category system.
• The additions align structured data more closely with Merchant Center’s sale_price_effective_date, product_type, and google_product_category attributes.
• Consistent values across the product page, structured data, and feed should be the implementation priority; the new markup does not by itself guarantee greater search visibility.

Two updates address one product-data problem

The supplied CrushPress.AI report presents sale duration and product category as additions to the same merchant listing documentation. Although they describe different aspects of a product, both address a common operational problem: important commerce data can become inconsistent when it is maintained separately in a storefront, structured data, and a Merchant Center feed.

The sale guidance connects schema.org properties with Merchant Center’s sale_price_effective_date attribute. The category guidance similarly connects Product.category with the product_type and google_product_category feed attributes. This does not make those fields interchangeable in every system. It does, however, give implementation teams a clearer correspondence between the concepts expressed in each channel.

That correspondence matters because promotional data is time-sensitive, while category data is usually taxonomy-sensitive. A pricing error may expose an expired or premature offer; a category mismatch may give systems conflicting descriptions of what the product is. The documentation changes provide a more explicit model for managing both risks.

Sale markup should follow the promotion’s actual lifecycle

According to the report, Google’s new sale-duration section discusses validFrom, validThrough, and priceValidUntil as ways to define when a sale price is effective. It also includes guidance and examples for assigning the properties to either an Offer or a PriceSpecification node.

The choice of node should reflect how the site’s product model owns pricing information. If an Offer contains the active commercial terms, the timing data may belong with that offer. If prices are represented through a dedicated PriceSpecification, keeping the dates with that specification can make the relationship between the amount and its validity period clearer. The important point is to use a coherent model rather than distributing related values arbitrarily.

Implementation should begin with the source of truth for the promotion. The structured data’s start and end values should be generated from the same approved schedule that controls the visible sale price and, where applicable, the Merchant Center submission. Automated removal or replacement after the promotion ends is just as important as publishing the future dates correctly.

Teams should also distinguish a scheduled sale from a routine price update. The reported guidance concerns the effective period of sale pricing; it should not be used to manufacture a promotional window when the page does not genuinely present a time-bound offer.

Product categories can preserve two useful vocabularies

The same report says Google’s documentation now supports Product.category using both Text and CategoryCode types. This mirrors two different classification needs represented in Merchant Center: product_type can express a merchant’s own taxonomy, while google_product_category represents Google’s classification.

A custom text category can preserve the language used in navigation, merchandising, reporting, or inventory management. A category code can identify the product within an external classification system. These are complementary signals: one communicates the merchant’s view of the catalog, and the other connects the item to a standardized vocabulary.

The source reports that Google’s examples allow custom text labels and Google Product Category codes in structured data. The implementation lesson is to retain the meaning of each value. A merchant label should not be presented as though it were an official code, and a code should remain associated with the category system it comes from.

Category markup should also be generated from maintained catalog data rather than copied manually into individual templates. Central ownership reduces the chance that a product is reclassified in the feed or storefront while stale structured data remains on the page.

A practical implementation and validation sequence

1. Identify the systems that control visible prices, promotion schedules, merchant feeds, and catalog categories.
2. Map sale start and end data to validFrom, validThrough, or priceValidUntil in the Offer or PriceSpecification model used by the site.
3. Map the internal merchant taxonomy and any Google category assignment to the appropriate Text or CategoryCode representation for Product.category.
4. Generate the markup from the same governed data used by the storefront and feed instead of maintaining a separate manual copy.
5. Check products before a sale begins, while it is active, and after it ends to confirm that visible content and machine-readable values change together.
6. Include category and promotional fields in routine structured-data audits so catalog migrations and template changes do not silently create conflicts.

Validation should cover meaning as well as syntax. Markup can be technically parseable while still containing an expired sale window, an incorrect category, or a value that disagrees with the page. The more useful test is whether every representation describes the same product and offer at the same moment.

As merchant markup moves closer to feed-level expressiveness, the durable advantage will come from shared product-data governance. Merchants that connect templates to reliable pricing and taxonomy sources will be better positioned to adopt these fields without creating another layer of catalog maintenance.

References

• CrushPress.AI — Google Merchant Listings Gain Powerful Sale Data Updates