Product schema in 2026: 9 fixes that decide if your merchant listings show

Summary. On 7 July 2026 Google made two changes to merchant listing structured data. It added a category property to Product, which lets you declare a Google Product Category in page markup instead of only in a Merchant Center feed, and it added a new "Sale duration" section explaining how validFrom, validThrough and priceValidUntil set the effective window for a sale price. Both changes close a gap between what your page says and what your feed says. The timing is not accidental: Q3 and Q4 promotional calendars run on sale windows, and Google's documentation now states plainly that "Your listing may not display if the priceValidUntil property indicates a past date." For Indian sellers the stakes scale with the market. The India Brand Equity Foundation puts India's e-commerce industry at Rs 10,82,875 crore (US$ 125 billion) in 2024, projected to Rs 29,88,735 crore (US$ 345 billion) by 2030 at an 18.4% CAGR, with online shoppers rising from 280 to 300 million in 2025 towards 420 to 440 million by 2030. In our remediation work the new properties are rarely the reason a page loses rich results. Older rules are: a price of zero, an AggregateOffer where an Offer is required, one URL serving two currencies, or Product markup that only exists after JavaScript runs. These are the nine checks, in the order we run them.

What changed on 7 July 2026

Google's documentation changelog records two entries on that date. The first added category to the merchant listing documentation, detailing how Product.category can be used with both Text and CategoryCode types, aligning with the product_type and google_product_category attributes in Merchant Center feeds. The second added a "Sale duration" section to the merchant listing guide.

Roger Montti, SEJ Staff writer at Search Engine Journal, weighed them this way: "In total, there are three new additions but the biggest change by far is the addition of a new Category property."

He is right about which one matters more, for a reason that is easy to miss. Category in markup gives Google a page-level statement of what a product is, in Google's own taxonomy, that does not depend on your feed being current. For any seller whose feed lags their catalogue, that is a meaningful new signal.

Fix 1: Get the required properties right before anything else

Three properties are required on Product for merchant listing eligibility: name, image and offers.

On Offer, Google requires price or priceSpecification.price, priceCurrency or priceSpecification.priceCurrency, and priceSpecification.

Two rules inside that list break more pages than the rest of this article combined.

The first is the offer type. Google states it directly: "Product snippets accept an Offer or AggregateOffer but merchant listings require an Offer as the merchant has to be the seller of the product in order to be eligible for merchant listing experiences." Marketplace-style templates that emit AggregateOffer for a price range are disqualified from merchant listing experiences by construction.

The second is price. "Unlike product snippets, merchant listing experiences require a price greater than zero." Any page that renders a zero price while stock is being loaded, or for a made-to-order item, is out.

There is a third rule that quietly decides which of your two prices Google reads: "If you use both the offers.price and offers.priceSpecification properties to encode an active price, Google will use the price provided through the offers.price property and ignore the offers.priceSpecification property." Templates that were extended over time often end up emitting both, with the stale one at the Offer level.

Fix 2: Understand Google's three price kinds before you touch sale windows

Google's merchant listing documentation defines three kinds of price, and they are distinguished by which properties are absent as much as which are present.

Google's rule for the overlap is blunt: "Price specifications containing both of these properties are ignored." A member-only sale price marked with both priceType and validForMemberTier is not a partially valid price; it is discarded.

Two related properties are still in beta. membershipPointsEarned carries the note "This property is in beta, and you may not see an effect in Google Search right away", and validForMemberTier carries a similar warning that off-page MemberProgramTier structured data might not show up in Google Search right away. Plan loyalty pricing markup as an investment in feed parity, not as a rich-result win this quarter.

For a transition period Google also still accepts ListPrice in place of StrikethroughPrice for strikethrough prices. New implementations should use StrikethroughPrice.

Fix 3: Put the sale window where Google can read it

This is the new section, and the placement rule is the part teams get wrong.

Dates go in ISO 8601 format, and Google's own example is 2025-12-31T23:59:59+01:00. Use validFrom for the start. For the end, use either validThrough or priceValidUntil. Google's best practices ask for both a start and an end, for the start to be earlier than or equal to the end, and, in its words: "We recommend including the time and timezone in the [ISO 8601] format for accuracy in Google systems."

Where those properties go depends on where the sale price lives.

On the Offer node, when price on that node holds the current active sale price, add validFrom and either validThrough or priceValidUntil directly to the Offer:

            {
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Example kurta set",
  "offers": {
    "@type": "Offer",
    "url": "https://www.example.in/kurta-set",
    "price": 1799.00,
    "priceCurrency": "INR",
    "validFrom": "2026-09-20T00:00:00+05:30",
    "priceValidUntil": "2026-09-30T23:59:59+05:30",
    "priceSpecification": {
      "@type": "UnitPriceSpecification",
      "priceType": "https://schema.org/StrikethroughPrice",
      "price": 2499.00,
      "priceCurrency": "INR"
    }
  }
}
          

On a PriceSpecification node, when the sale price is defined there rather than on the Offer, add validFrom and validThrough to that node. Google adds a warning worth writing on a sticky note: "Note that the priceValidUntil property isn't applicable to the PriceSpecification type."

That single sentence is the most common new-code bug we expect from this change. A developer reads the property list, sees three date properties, and applies all three uniformly to both node types. priceValidUntil on a PriceSpecification is silently meaningless.

The consequence of getting it wrong is spelled out in the property table: "Your listing may not display if the priceValidUntil property indicates a past date." A stale sale date does not degrade your listing. It can remove it.

Fix 4: Declare category in markup, not only in the feed

Product.category accepts Text or CategoryCode, and it accepts an array mixing both.

Plain text works like the product_type feed attribute and represents your own category label. Google recommends keeping custom product types under the 750-character limit.

CategoryCode is how you declare a Google Product Category on the page. Set @type to CategoryCode, set inCodeSet to a Google Product Taxonomy URL, and set codeValue to either the numeric GPC ID or the full category path. Google's own examples use the ID "2271" and the path "Apparel & Accessories > Clothing > Dresses". Paths use > as the level separator, and each segment in the path must contain at least one letter.

You can supply several values at once, mixing GPC codes, GPC paths and custom product type strings in one array.

The engineering judgement here: if your feed and your page disagree about what a product is, the fix is upstream of both. Take the category from the same source of truth that populates your feed, or you have simply created a second place to be wrong.

Fix 5: Give every currency its own URL

Google's technical guidelines say it without qualification: "When offering products for sale in multiple currencies, have a distinct URL per currency. For example, if a product is available for sale in Canadian and US dollars, use two distinct URLs, one per currency."

Indian D2C brands selling to domestic and NRI or export customers routinely serve INR and USD from the same URL, switching on IP geolocation or a cookie. That pattern is incompatible with merchant listing eligibility, and it is expensive to unwind after a replatform rather than during one.

The same guideline set adds three more eligibility conditions that catch template-driven sites:

• "Only pages where a shopper can purchase a product are eligible for merchant listing experiences, not pages with links to other sites that sell the product." Affiliate and comparison pages are out.

• "Product rich results only support pages that focus on a single product (or multiple variants of the same product)." Category and collection pages are out, and Google adds that this includes product variants where each variant has a distinct URL.

• "Car isn't supported automatically as a subtype of Product. For now, include both Car and Product types if you want to attach ratings to it and be eligible for the Search feature."

Fix 6: Render the markup server-side

Google's guidance on this is a recommendation with a hard operational edge.

"If you're a merchant optimizing for all types of shopping results, we recommend putting Product structured data in the initial HTML for best results." Then the reason: "Be aware that dynamically-generated markup can make Shopping crawls less frequent and less reliable, which can be an issue for fast-changing content like product availability and price. If you're using JavaScript to generate Product markup, make sure your server has enough computing resources to handle increased traffic from Google."

Read that alongside fix 3. Sale windows, availability and price are exactly the fast-changing fields, and client-rendered markup is exactly where crawl reliability drops. A headless storefront that hydrates its JSON-LD in the browser is combining the two worst options for the fields that matter most during a sale.

If you are already planning a headless build, this belongs in the architecture decision rather than in a later SEO ticket. We cover the same trade-off from the platform side in our SEO-safe replatform and migration work.

Fix 7: Fix availability and condition enumerations

availability takes an ItemAvailability value, and Google supports ten: BackOrder, Discontinued, InStock, InStoreOnly, LimitedAvailability, OnlineOnly, OutOfStock, PreOrder, PreSale and SoldOut. Short names without the URL prefix are also supported.

itemCondition takes NewCondition, RefurbishedCondition or UsedCondition.

For both, Google says the same thing: "Don't specify more than one value." Systems that map an internal multi-warehouse stock state into schema often emit two availability values for a product that is in stock in one location and back-ordered in another. Pick one, and pick the one a shopper on that URL would experience.

Fix 8: Move shipping and returns to the organization level

Google's preference here saves work rather than creating it.

For both shippingDetails and hasMerchantReturnPolicy, the documentation says to use the property under Offer "Only if some of your products have specific shipping policies for which you need to override your global shipping policy, or if you don't provide a standard shipping policy for your business". It adds that "the properties supported for offer-level shipping policies are a subset of the properties supported for organization-level shipping policies", and makes the same point about returns: "Product-level return policies should only be used to override a standard merchant-level return policy or when there is no standard return policy as product-level return policies support only a subset of the properties available for merchant-level return policies."

So one organization-level policy, referenced by @id, beats the same block duplicated across 40,000 product pages, and it exposes more properties while it does so.

While you are in this area, two smaller items. hasCertification now replaces the older hasEnergyConsumptionDetails pattern, which Google says it continues to support but no longer recommends. And if you sell anything Google treats as adult-oriented, hasAdultConsideration is mandatory for those items; Google Search supports only the value https://schema.org/SexualContentConsideration for that property.

Fix 9: Fix the images, because they are a required property

image is required, and its guidelines are more specific than most teams implement.

Image URLs must be crawlable and indexable, the images must represent the marked-up content, and the format must be one Google Images supports. Google then recommends "providing multiple high-resolution images (minimum of 50K pixels when multiplying width and height) with the following aspect ratios: 16x9, 4x3, and 1x1."

A 200 by 200 thumbnail is 40,000 pixels and falls under that recommendation. A single square hero satisfies one of the three suggested aspect ratios. Neither is fatal on its own, and both are cheap to fix during a catalogue image pipeline change.

The remediation order we use

Work top down. Rows 1 to 3 decide whether the page can produce a merchant listing at all; the rest decide how good it is.

India-specific considerations

Three things change the calculation for an Indian seller.

The currency rule bites harder here. Brands selling domestically in rupees and internationally in dollars from one storefront are common, and the single-URL-per-currency requirement forces a routing decision that touches canonical tags, hreflang and the sitemap. Do it during a platform change, not as a patch.

Feed and page divergence is structural, not accidental. Most Indian D2C brands run a catalogue in one system, a Merchant Center feed generated by a plugin, and a storefront template that emits its own JSON-LD. Three systems, three chances to disagree about price, availability and now category. The new category property is only worth adding if it reads from the same source as the feed; otherwise it is a third opinion.

Sale calendars are dense. Festive season sale windows are short, overlapping and heavily discounted, which is exactly the case the new sale duration section is designed for and exactly the case where a stale priceValidUntil costs a listing during the highest-traffic fortnight of the year.

Scale explains why this is worth engineering properly rather than patching. The India Brand Equity Foundation, which aggregates figures from press and media reports rather than publishing primary data, puts the industry at Rs 10,82,875 crore (US$ 125 billion) in 2024 heading to Rs 29,88,735 crore (US$ 345 billion) by 2030, with the online shopper base moving from 280 to 300 million in 2025 to a projected 420 to 440 million by 2030. Treat those as directional rather than precise, because IBEF's own page carries competing figures in different sections.

Teams still moving from the Content API for Shopping will find the feed side of this covered in our note on the Content API to Merchant API migration, and the same markup discipline that earns rich results is what earns citations in AI answers, which we set out in structured data and JSON-LD for AI search citations.

What we do in a product schema remediation

eCorpIT was founded in 2021 and works from Gurugram. Our commerce engagements here follow a consistent shape.

We start with a crawl of the live catalogue and extract the JSON-LD each template actually emits, rendered and unrendered, because those two differ on most headless storefronts. We compare that against the Merchant Center feed row by row for price, availability and category, and we produce a defect list ranked by the priority order in the table above rather than by defect count.

Remediation is then a template change plus a data-source change, not a per-page fix. In most catalogues, four to six templates produce every product page, and the same four defects repeat across tens of thousands of URLs. We fix the template, validate with the Rich Results Test, and watch the merchant listing report in Search Console through a full re-crawl before calling it done.

Engagements are typically scoped as a fixed-price audit followed by a time-boxed remediation sprint, sized to the number of templates rather than the number of products. Who it is for: Indian D2C brands, marketplaces and B2B commerce teams whose product pages are losing rich results and who need the feed and the page to stop disagreeing.

We work as senior-led, multi-disciplinary teams, we are assessed at CMMI Level 5, MSME certified and ISO 27001:2022 certified, and we are partners with AWS, Microsoft, Google and Shopify. Where a remediation touches customer data, we design implementations aligned with Digital Personal Data Protection Act requirements.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based technology consultancy with senior engineering teams working across commerce platforms, product data and search visibility. We audit what your templates actually emit against what your Merchant Center feed sends, rank the defects by the eligibility gates that decide whether a listing can appear at all, and fix them at the template and data-source level rather than page by page. If your product pages have quietly lost rich results and nobody can say which system is wrong, talk to us at /contact-us/.

References

1. Merchant listing (Product, Offer) structured data - Google Search Central

1. Latest documentation updates - Google Search Central changelog, 7 July 2026

1. Google's New Merchant Listing Structured Data Improves SEO - Roger Montti, Search Engine Journal, 9 July 2026

1. Google merchant listings support sale duration and product category - Search Engine Land, July 2026

1. Google adds category codes to merchant listings on July 7 - PPC Land, July 2026

1. Google Supports Product Category and Sale Duration To Merchant Listing Structured Data - Search Engine Roundtable, July 2026

1. Google Product Taxonomy with IDs - Google

1. product_type attribute specification - Google Merchant Center Help

1. google_product_category attribute specification - Google Merchant Center Help

1. sale_price_effective_date attribute specification - Google Merchant Center Help

1. Product snippet (Product, Review, Offer) structured data - Google Search Central

1. Product variant structured data - Google Search Central

1. E-commerce Industry in India - India Brand Equity Foundation, last updated June 2026

Last updated: 5 August 2026.