---
title: "Product Schema and Merchant Center"
description: "Product structured data for ecommerce: JSON-LD implementation, Merchant Center integration, the Shopping Graph, and the 2026 spec updates."
tldr: "Product structured data in JSON-LD gives search engines machine-readable product information: price, availability, ratings, return policy and shipping. Google requires only name, image and an Offer carrying price and priceCurrency for merchant listing eligibility, with MerchantReturnPolicy and OfferShippingDetails recommended rather than required, though supplying them enables the shipping and returns detail shown in listings. Google Merchant Center extends the same data into Shopping results and the Shopping Graph. The 2026 Merchant Center spec update adds a video_link attribute and raises the minimum image resolution to 500x500 pixels, enforced from January 2027."
publishDate: 2026-08-22
updatedDate: 2026-09-13
author: "Liam Hayward"
---
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.[^1] A product priced at zero, or listed as price on application, is not eligible on that basis alone.

Everything else is **recommended**, not required.[^1] 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

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 is required and 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.[^2]

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.[^4] 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".[^4] 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.[^1]

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:

```json
"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.[^1]

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.

```json
"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".[^5] 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 states the consequence plainly: "If at least one of these conditions isn't met, the products on your landing page won't match your product data."[^5] 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".[^4]

Treat the feed as the authoritative source and the crawl as a fallback. Where a store supplies both, the feed is what Merchant Center is built around, and the crawl route exists for merchants who do not run one, which is why it carries conditions the feed does not. Keeping the two consistent is the practical rule: a price or availability that differs between the feed and the page is the common cause of disapprovals, and it is a data problem rather than a markup one. Note also that the older Content API for Shopping was **sunset on 18 August 2026**, with progressive errors from 1 September, so any integration still pointing at it needs migrating to the Merchant API.[^6]

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:[^3]

**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 and marketing methods, having been warning-only since 14 April 2026. The warning period is the useful part and it is already half spent, so the audit is due rather than upcoming. Google names where to look: the Needs attention section of a Merchant Center account, then View history, where affected products carry an "Image too small for upcoming enforcement" warning. 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, flagged with their own warning in the same place, so the warnings are where 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](/technical-seo/structured-data-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.

[^1]: [Merchant listing structured data — Google Search Central](https://developers.google.com/search/docs/appearance/structured-data/merchant-listing)
[^2]: [Returns attribute — Google Merchant Center Help](https://support.google.com/merchants/answer/17081382)
[^3]: [Merchant Center product data specification update 2026 — Google Merchant Center Help](https://support.google.com/merchants/answer/16989427)
[^4]: [Product variant structured data — Google Search Central](https://developers.google.com/search/docs/appearance/structured-data/product-variants)
[^5]: [Set up structured data for Merchant Center — Google Merchant Center Help](https://support.google.com/merchants/answer/7331077)
[^6]: [Content API for Shopping: deprecation and sunset — Google for Developers](https://developers.google.com/shopping-content/guides/best-practices)