Learn / variants

Marking up variants: the ProductGroup pattern

A product in five sizes is five purchasable offers sharing one page — but most themes emit one flat Product block for the default variant and call it done. Google then sees a fraction of your catalogue, and naive validators report your valid markup as missing. Here is the ProductGroup pattern that fixes both.

The flat-Product problem

Shopify auto-emission describes the selected or first variant as a single Product. The other four sizes exist on the page for shoppers and nowhere in the markup for machines: their prices, availability and identifiers are invisible to every consumer of structured data. For Merchant Center alignment this is a quiet catalogue cut — variants that cannot be matched cannot serve — and for validators it produces the paradox of “no Product markup found” on pages that plainly carry a Product block, because the checker looked past nesting it did not understand.

The ProductGroup pattern

Declare the group once with the shared facts (name, image set, brand, category), then nest one Product per variant under hasVariant, each carrying its own SKU or GTIN, price, currency and availability. Deduplicate with @id so the group block and any legacy flat block resolve to one entity instead of two competing ones. Variant-level identifiers matter most: without distinct SKUs or GTINs per variant, matching still collapses the group into one item.

{ "@context": "https://schema.org", "@type": "ProductGroup",
  "@id": "https://shop.example/products/trail-boot#group",
  "name": "Trail Boot", "brand": { "@type": "Brand", "name": "Nordhaus" },
  "hasVariant": [
    { "@type": "Product", "sku": "TB-8", "offers": {
      "@type": "Offer", "price": "149.00", "priceCurrency": "USD",
      "availability": "https://schema.org/InStock" } },
    { "@type": "Product", "sku": "TB-10", "offers": {
      "@type": "Offer", "price": "159.00", "priceCurrency": "USD",
      "availability": "https://schema.org/OutOfStock" } }
  ] }

The ratings trap

Never fabricate variant ratings

aggregateRating is only valid with genuine independent reviews. Stamping every variant with five stars from your own review widget is self-serving markup — it will not earn stars and it can suppress the listing. Leave ratings off rather than invent them.

Validating variant markup

  1. View source and confirm the group block is server-rendered, not injected.
  2. Count hasVariant entries against real variants — every purchasable combination needs an offer.
  3. Confirm each variant offer carries price, currency and availability.
  4. Run the Rich Results Test and expect one deduped entity, not a pile of competing Products.

Deeper: product schema pillar · Related guide: no product markup found

Find out if this is happening to you

Shipwork parses nested ProductGroup and hasVariant structures — reporting each variant offer missing price, currency or availability instead of crying “missing markup”. Free, no account, no signup — paste your store address.

Check my variants

Questions

Does every variant need its own offer in markup?
Yes — one offer per purchasable combination, each with price, currency and availability. A group with a single shared offer misstates every variant but one.
Will ProductGroup confuse validators?
Naive ones, yes — they report “missing Product” on valid grouped markup. The Rich Results Test understands nesting; so does the free structured-data check.
Should variants share one SKU?
No. Distinct SKUs (or GTINs where they exist) per variant are what let Google match each combination separately.
Can I keep my flat Product block too?
Only if both resolve to one entity via shared @id. Two competing top-level Products for the same item produce duplicate-entity warnings.

Keep reading