Product Schema and Merchant Center

Product structured data sits at the intersection of organic search and AI shopping visibility. In JSON-LD, it communicates machine-readable product information that powers rich results in organic search, Shopping listings, and the data signals that AI shopping agents draw from when making product recommendations. Structured data on your product pages and data in Google Merchant Center interact directly; keeping them consistent is part of the implementation.

What structured data does a product page need?

A complete product page implementation uses the Product type as the root, with Offer nested to specify commercial terms.

Google runs two Product rich-result experiences. They have different requirements, and conflating them is the commonest source of bad advice:

• Merchant listings are for pages where the product can be bought directly. These are what feed Shopping surfaces and the Shopping Graph.
• Product snippets are for pages that describe a product without necessarily selling it, such as a review or a roundup. This experience carries more review detail, including pros and cons; merchant listings carry more commercial detail. The two overlap, and aggregateRating is recommended for both, so a page marked up for merchant listings is generally eligible for product snippets as well.

For merchant listing eligibility, Google requires only:

• name: the product name
• image: at least one image URL
• offers: an Offer carrying price and priceCurrency

Note that merchant listings require a price greater than zero, unlike product snippets.¹ A product priced at zero, or listed as price on application, is not eligible on that basis alone.

Everything else is recommended, not required.¹ The recommended set is still worth implementing, because it is what produces the richer display and the trust signals Google leans on:

• description: a product description
• sku or mpn (or both): an identifier for matching with Merchant Center feed data
• gtin (or the more specific gtin8, gtin12, gtin13, gtin14): Google recommends including all applicable global identifiers and using the most specific GTIN that applies. This is the key Google matches your offer against other sellers of the same product, so omitting it weakens listing consolidation
• brand: the brand entity
• category: the product’s category, either as free text or a Google product category code
• availability on the Offer: in stock, out of stock, pre-order
• hasMerchantReturnPolicy: return policy via MerchantReturnPolicy
• shippingDetails: delivery costs and estimates via OfferShippingDetails
• aggregateRating: average rating and review count, where genuine reviews exist

The practical reading: you will not lose merchant listing eligibility for omitting return and shipping data, but you will forfeit the shipping and returns detail that Google displays in the listing, which is exactly the information a buyer scans for. Treat them as strongly advisable rather than as a gate. Return and shipping policies can also be set once at the account level in Merchant Center rather than repeated in markup on every product.

What are MerchantReturnPolicy and OfferShippingDetails?

MerchantReturnPolicy specifies the return conditions for a product: the return window (e.g. 30 days), how the item is physically returned, and refund availability. The Merchant Center feed equivalent is the returns attribute, whose method sub-attribute takes BY_MAIL, IN_STORE, AT_A_KIOSK or DROP_OFF_LOCATION. Google describes the attribute as optional for each product but highly recommended, and supports up to 100 return policy overrides per offer.²

Return policy can be specified at the account level in Merchant Center (applying a default to all products) or at the product level in structured data, overriding the account default for individual products.

OfferShippingDetails specifies available shipping services: carrier, estimated delivery window, and cost. Accurate shipping data improves how delivery information displays in Shopping results and organic rich results.

How do you mark up product variants?

Where a product is sold in sizes, colours or materials, Google asks for the ProductGroup class alongside the individual Product markup, using variesBy to name which properties distinguish the variants, hasVariant to nest them, and productGroupID to carry the parent SKU.³ The variant Product can point back with inProductGroupWithID, though Google notes this does not need repeating when productGroupID is set on the group. Adding it makes the products eligible for display with variant information in merchant listings.

The markup has a URL requirement attached to it, and this is where variant implementations usually fail. Google requires that each variant can be preselected directly with a distinct URL, typically via query parameters, and that preselecting “includes showing the right image, price, and availability, as well as allowing the user to add the variant to the cart”.³ Without those URLs Google cannot identify the variants at all, whatever the canonical tag says. Where variants live on separate pages instead, there is no single canonical URL representing the group and each page needs full, self-contained markup.

How do you categorise a product in markup?

The category property lets you state a product’s category in the structured data itself rather than only in a Merchant Center feed. It is recommended, not required, and it takes two different value types that mirror two different feed attributes.¹

A plain Text value is your own custom product type, the equivalent of the product_type feed attribute. Google recommends keeping these under 750 characters. A CategoryCode value is a Google Product Category, the equivalent of google_product_category. For a CategoryCode you set inCodeSet to a Google product taxonomy URL and codeValue to either the numeric category ID or the full category path, using > as the separator between levels.

The property accepts an array, so you can supply several values at once and mix the two types:

"category": [
  {
    "@type": "CategoryCode",
    "inCodeSet": "https://www.google.com/basepages/producttype/taxonomy-with-ids.en-US.txt",
    "codeValue": "2271"
  },
  "Dresses",
  "Special Occasion > Wedding & Bridal Party Dresses"
]

This matters most for sites that lean on on-page markup rather than, or alongside, a feed: accurate categorisation is what helps Google match a product to relevant queries, and category gives Google that signal from the page itself.

How do you mark up a sale price and its duration?

If a product is on a limited-time discount, you can state the window the sale price applies to, so Google understands both the price and how long it is good for rather than inferring the duration.¹

The start of the window is always validFrom. The end is either validThrough or priceValidUntil, not both, and the start must be earlier than or equal to the end. Where these properties sit depends on how you have expressed the sale price:

• On the Offer node. Use this when the price on the Offer is itself the active sale price. Both validFrom and your chosen end property go directly on the Offer.
• On a PriceSpecification node. Use this when the sale price is defined inside a PriceSpecification (typically alongside a StrikethroughPrice showing the pre-sale price). Here, use validFrom and validThrough. priceValidUntil is not applicable to the PriceSpecification type, so reaching for it on that node is a silent mistake.

"offers": {
  "@type": "Offer",
  "price": 24.99,
  "priceCurrency": "GBP",
  "validFrom": "2026-11-20T08:00:00+00:00",
  "priceValidUntil": "2026-11-30T23:59:59+00:00"
}

This aligns on-page markup with the sale_price_effective_date attribute that Merchant Center feeds already support. As with categorisation, the value is consistency: a retailer already supplying accurate sale windows through a feed gains most by making the structured data agree with it.

How does Google Merchant Center relate to structured data?

Merchant Center is a separate product from structured data, but the two interact. Merchant Center accepts product data through several routes, including a platform connection, file upload, Sheets, the Merchant API, and crawling your product pages to read their structured data.

The crawl route carries conditions that catch out modern storefronts. The markup “must be present in the HTML returned from the web server” and “can’t be generated with JavaScript after the page has loaded”.⁴ The landing page must carry a single offer, or annotate every offer with a SKU or GTIN matching the feed, and its content and pricing “must not dynamically change based on user information such as IP address or browser type”.⁴ Google’s separate advice for merchants optimising across all shopping results is to put Product structured data in the initial HTML, warning 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”.³

Where sources conflict, Merchant Center applies a precedence order rather than arbitrary reconciliation: product-level feed data wins over Content API settings, which win over account-level settings, which win over product-level markup, which wins over Organization-level markup. Consistent data across the feed and structured data reduces eligibility issues.

Merchant Center product listings appear across Google Shopping, Google Images, Google Search, and the Shopping Graph, Google’s index of product information across the web. Complete, accurate structured data on product pages is the foundation of Shopping Graph inclusion.

What changed in the 2026 Merchant Center spec update?

Google announced a staged spec update for 2026 with three key milestones:⁵

14 April 2026: new attributes available; image warnings begin. New optional attributes were made available: video_link, plus handling_cutoff_time and minimum_order_value on the shipping side, and loyalty programme labels. Technical validation errors for these began reporting on the same day, and image size warnings began for products submitted with images below 500×500 pixels.

30 June 2026: video serving begins. Videos submitted via video_link become eligible to serve across Shopping surfaces. Google begins reporting policy or quality errors for submitted videos. A video error prevents the video from serving but does not affect the associated product offer or listing.

31 January 2027: image resolution enforcement. The minimum resolution of 500×500 pixels becomes mandatory across all product categories, having been warning-only since April. The warning period is the useful part: a Merchant Center account will flag undersized images for nine months before enforcement, so audit product image dimensions against the warnings now. Google also says it will optimise some images below 500×500 itself, and that those optimised images will meet the requirement and prevent disapproval without merchant action, so the warnings are the place to find out which products actually need work.

How do you check the markup is working?

Validate with the Rich Results Test before deployment, then monitor the merchant listings report in Search Console, which reports errors against pages Google has actually crawled rather than against a pasted snippet. The URL Inspection tool’s live test shows what Google sees on a specific URL, which is the check that catches JavaScript-generated markup failing the conditions above. General structured data validation is covered in structured data and schema markup.

What is the Shopping Graph?

The Shopping Graph is Google’s knowledge base of product information, assembled from Merchant Center feeds, product page structured data, third-party data sources, and broader web content. It powers Google Shopping, free product listings, and the AI shopping surfaces that surface product recommendations in AI Mode and conversational interfaces.

Inclusion requires a Merchant Center account, accurate product data, and the trust signals Google uses to assess listing quality: genuine reviews, complete return and shipping policies, accurate pricing, and consistent data across all sources.

Free product listings (distinct from Shopping Ads) are available to all Merchant Center accounts without requiring an active advertising spend. They appear across Google Search, Google Images, and Shopping surfaces when Google determines a product is relevant to a query.

Footnotes

1. Merchant listing structured data — Google Search Central ↩ ↩² ↩³ ↩⁴

2. Returns attribute — Google Merchant Center Help ↩

3. Product variant structured data — Google Search Central ↩ ↩² ↩³

4. Set up your product data in Merchant Center — Google Merchant Center Help ↩ ↩²

5. Merchant Center product data specification update 2026 — Google Merchant Center Help ↩