1) Two rich-result experiences

2) The core properties

• • • • • • • • Required: name, image, and an offers object containing price, priceCurrency, and availability (for example, InStock or OutOfStock).
               
           
       

• • • • • • • • For star ratings: aggregateRating (rating value and review count), or individual review entries.
               
           
       

• • • • • • • • Recommended: brand, and an identifier: sku, and ideally gtin or mpn. Google matches your product to its catalog using GTIN, MPN, and brand, not your internal SKU, so include real identifiers where you have them.
               
           
       

3) Variants: ProductGroup and hasVariant

• • • • • • • • Nested (single page). All variants live on one URL, or the URL just appends a parameter like ?color=blue. Put the ProductGroup and all its variant Products in one JSON-LD block using hasVariant. The canonical is the base URL without variant parameters.
               
           
       

• • • • • • • • Flat (separate URLs). Each variant has its own page. Each variant Product is its own markup, linking back to the shared ProductGroup with isVariantOf. Common for large or headless catalogs.
               
           
       

{
  "@type": "ProductGroup",
  "name": "Classic Cotton T-Shirt",
  "brand": { "@type": "Brand", "name": "Example Apparel" },
  "productGroupID": "TSHIRT-COTTON",
  "variesBy": ["https://schema.org/size"],
  "hasVariant": [
    {
      "@type": "Product",
      "name": "Classic Cotton T-Shirt, Small",
      "size": "S",
      "sku": "TSHIRT-COTTON-S",
      "image": "https://example.com/tshirt-s.jpg",
      "offers": {
        "@type": "Offer",
        "price": "29.99",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock",
        "url": "https://example.com/tshirt?size=s"
      }
    }
    // ... one Product per variant
  ]
}

4) Shipping and returns annotations

5) The golden rule: match the page

6) Implementing and validating

1. Use JSON-LD in the page, Google’s preferred format. Most platforms and SEO apps can output it; the challenge is making the template produce the right pattern for each product type.
2. Start with your highest-traffic categories rather than the whole catalog at once, so you catch template problems early.
3. Validate every template with Google’s Rich Results Test, then watch the Search Console rich-results and merchant-listings reports for errors after deploying.
4. Re-check quarterly. Schema that validated once can silently break after a theme or CMS change. A periodic audit catches it.

7) Common mistakes

• Product schema on category pages. Google warns against it. Category pages list many products; mark up each product on its own page, and use ItemList on the category (see category page content and structure).
• Schema that doesn’t match the page. Mismatched price or availability risks losing eligibility. Keep them in sync.
• Wrapping a single-SKU product in ProductGroup. Nothing to group. Use plain Product.
• Variant URLs that don’t deep-link. Every variant’s URL must pre-select that variant, not point at the base page.
• Missing identifiers. No unique SKU or GTIN per variant means Google can’t tell them apart. Add real identifiers.
• Mixing nested and flat patterns. Pick one approach per page and apply it consistently.

8) Sources used

FAQ: product schema and rich results

Where to go next