Product structured data: product snippets vs merchant listings

Google reads Product markup in two different ways, depending on whether people can buy on the page. This guide explains the two types, the properties each one requires, where shipping and return policies belong, and how to test the result.

This guide is built from Google Search Central: the introduction to Product structured data, the product snippet and merchant listing documentation, and the pages on return policies, shipping policies, review snippets and product variants. For what structured data is and which types most business sites need, start with our structured data basics.

Two kinds of product markup

Product markup can make price, availability, ratings, shipping and other details appear with your page in Google Search, Google Images and Google Lens. Google splits it into two classes and asks you to "follow the requirements for the type that best suits your use case":

Product snippetsMerchant listings
ForPages "where people can't directly purchase the product": editorial reviews, comparison and aggregator pagesPages "where customers can purchase products from you"
Extra optionsMore review detail, such as pros and consMore product detail, such as sizing, shipping and returns
Offer typeOffer or AggregateOfferOffer only
PriceZero is acceptedMust be greater than zero
Search Console reportProduct snippetsMerchant listings

The two overlap. Google notes that "adding the required product information properties for merchant listings means that your product pages can also be eligible for product snippets." So a shop marks up its product pages once, to the merchant listing standard, and a review site marks up its review pages to the product snippet standard.

Product snippets: what's required

A product snippet is a text result with extra product details such as a rating, review information, price and availability. The requirements are short: the name of the product, plus at least one of review, aggregateRating or offers. Google adds that the Rich Results Test "may report a warning if you provide offers without review or aggregateRating properties."

Reviews follow the separate review snippet rules. A reviewer's name must be a real person or team; Google's example of a bad value is "50% off on Black Friday" and of good ones "James Smith" or "CNET Reviewers". Editorial review pages can also add positiveNotes and negativeNotes to the review for the pros and cons display, with at least two statements in total. Google states that "only editorial product review pages are eligible for the pros and cons appearance in Search, not merchant product pages or customer product reviews."

Merchant listings: what's required

Merchant listing markup is for shop pages. Only pages where a shopper can buy are eligible, "not pages with links to other sites that sell the product", and Google "may attempt to verify merchant listing product data before showing the information in search results."

Three properties are required on the Product:

  • name, the name of the product.
  • image, one or more product photos. The URLs must be crawlable and indexable. For best results Google recommends several high-resolution images (at least 50,000 pixels when width and height are multiplied) in 16x9, 4x3 and 1x1 ratios.
  • offers, a nested Offer. AggregateOffer isn't accepted here, because "the merchant has to be the seller of the product."

Recommended properties include description ("strongly recommended"), brand.name, aggregateRating and review, the global identifiers (gtin, gtin8 to gtin14, isbn), sku, color, size, audience and category. Google asks for GTINs in numeric form, not as URLs, and for an sku without whitespace.

Offer details: price, stock and condition

The Offer needs a price and a currency: price and priceCurrency (in three-letter ISO 4217 format), or the same two inside a priceSpecification. If both forms are present, Google uses offers.price and ignores the other. Unlike product snippets, "merchant listing experiences require a price greater than zero."

The recommended Offer properties are the ones shoppers notice:

  • availability: one value, such as InStock, OutOfStock, PreOrder, BackOrder or Discontinued.
  • itemCondition: NewCondition, RefurbishedCondition or UsedCondition.
  • priceValidUntil: Google warns that "your listing may not display if the priceValidUntil property indicates a past date."
  • shippingDetails and hasMerchantReturnPolicy: see the next section.

To show a sale, keep the current price as the active price and add a second price specification with priceType set to https://schema.org/StrikethroughPrice for the regular price. Google says not to mark the active price with a priceType. Price drops are different: Google works them out itself by watching price changes over time, and they "are not guaranteed to be shown."

Shipping and return policies

This is where current guidance has moved. Google now recommends describing your standard policies once, at business level, rather than on every product:

  • Returns: a MerchantReturnPolicy nested under your Organization with the hasMerchantReturnPolicy property. It can link to your return policy page or spell out return windows, methods, fees and refund options.
  • Shipping: a ShippingService nested under Organization with hasShippingService, describing costs and delivery times by weight, size or destination.

Both policy pages recommend putting this information "on a single page on your site" and say you "don't need to include it on every page." Use hasMerchantReturnPolicy or shippingDetails on an individual Offer only to override the standard policy for specific products, or when you have no standard policy. Offer-level policies support only a subset of the properties, and an Offer can point to the global policy by its @id.

Product variants

If a product comes in several sizes, colours or materials, Google's variant documentation uses ProductGroup with variesBy, hasVariant and productGroupID to tie the variants to one parent product. Shared details such as brand and reviews can sit on the group, which "can reduce the duplication of information", and the markup makes products eligible to show variant information in merchant listing experiences. Both product snippets and merchant listings support variants.

A JSON-LD example

This is a minimal merchant listing in the shape of Google's examples, with the return and shipping policies referenced from the Organization rather than repeated:

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Executive Anvil",
  "image": [
    "https://example.com/photos/1x1/photo.jpg",
    "https://example.com/photos/4x3/photo.jpg",
    "https://example.com/photos/16x9/photo.jpg"
  ],
  "description": "Sleeker than ACME's Classic Anvil.",
  "sku": "0446310786",
  "brand": { "@type": "Brand", "name": "ACME" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/anvil",
    "price": 119.99,
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}
</script>

Add aggregateRating or review only when those ratings are visible on the page. Policies live in the Organization markup, on one page of the site.

Rules that catch people out

  • One product per page. Product rich results "only support pages that focus on a single product (or multiple variants of the same product)". Google recommends marking up product pages, not category or listing pages.
  • One currency per URL. If you sell in Canadian and US dollars, use two distinct URLs.
  • Initial HTML is safer. Google recommends Product markup in the initial HTML and warns that JavaScript-generated markup "can make Shopping crawls less frequent and less reliable", a problem for prices and stock that change often. Our JavaScript SEO guide covers rendering.
  • Reviews must be visible and genuine. The review snippet rules say marked-up reviews must be readily available on the page, rule out aggregating reviews from other websites, and ban fake or undisclosed incentivised reviews. Breaking them can lead to a manual action.
  • Content limits. Content that promotes widely prohibited or regulated goods, such as firearms, recreational drugs, tobacco and vaping products, isn't allowed.

Structured data isn't the only route. Google says providing both page markup and a Merchant Center feed "maximizes your eligibility to experiences and helps Google correctly understand and verify your data", and some experiences combine the two. Our Google Merchant Center basics covers the feed side, and our guide to Merchant Center product data explains data sources and attribute formats.

Testing and the two Search Console reports

Check a page or code snippet with the Rich Results Test, fix critical errors, then use URL Inspection on a few live pages to see how Google reads them. Search Console has two related reports: the Merchant listings report for pages where shoppers can buy, and the Product snippets report for other product pages such as reviews and aggregators. The Merchant listings report already includes the checks for product snippets with Offer markup, so shops only need the Product snippets report for non-merchant pages. As with all structured data, Google doesn't guarantee that a rich result will appear.

Our view: how we set up product markup

This part is our own practice, not Google's guidance. On online stores we build, we generate the Product markup from the same data that fills the visible page, in the server-rendered HTML, so the price, stock and images in the markup can't drift from what the shopper sees. We put the return and shipping policies in the Organization markup once, link the policy pages from the footer, and only add offer-level overrides where a product really has different terms. Before launch we run a sample of products through the Rich Results Test, and after launch we watch the Merchant listings report for new errors when templates change. If the store also runs Shopping campaigns, we check that the feed and the page markup agree.

Frequently asked questions

What is the difference between product snippets and merchant listings?

Product snippets are for pages where people can't buy the product directly, such as editorial reviews. Merchant listings are for pages where customers can buy from you, and they need more detail: an image, an Offer with a price above zero and a currency. Meeting the merchant listing requirements also makes a page eligible for product snippets.

What are the required properties for product structured data?

For product snippets: name, plus one of review, aggregateRating or offers. For merchant listings: name, image and offers, where the Offer has a price greater than zero and a priceCurrency, either directly or inside priceSpecification.

Where should shipping and return policy markup go?

Google recommends putting your standard policies under your Organization markup: MerchantReturnPolicy with hasMerchantReturnPolicy and ShippingService with hasShippingService, ideally on a single page. Offer-level policies are for overriding the standard policy on specific products.

Can I add Product markup to category pages?

Google recommends against it. Product rich results only support pages that focus on a single product or variants of the same product, so mark up the individual product pages instead.

Do I need Merchant Center if my pages have Product markup?

Not for structured data to work, but Google says providing both page markup and a Merchant Center feed maximizes eligibility for shopping experiences and helps it verify your data. Some experiences combine data from both.

For more on structured data and online stores, see our guides to structured data basics, breadcrumb structured data, launching an online store and reviews and testimonials on websites. We build online stores through our website development service.