Product variants: URLs, canonicals, ProductGroup markup and Merchant Center

A product that comes in several colours or sizes forces three decisions that are often made by different people: how many URLs the variants get, which of those URLs is canonical, and how the variants are described in structured data and in the Merchant Center feed. When the three disagree, Google gets mixed signals about which page represents the product, and shoppers can land on a page showing a different colour or price from the one they clicked.

The ecommerce SEO guide covers variants briefly, alongside categories, faceted navigation and product data.

Schema.org defines a ProductGroup as a group of products that vary only in certain well-described ways, such as size, colour or material.³ That definition is a useful test. If two items differ in more than those few dimensions, for example a laptop with a different processor and screen, they are closer to separate products than variants, and the case for separate pages gets stronger.

Most platforms already produce the parameter form. On Shopify, a variant deep link adds ?variant= and the variant's ID to the product URL, and a product can have at most three options, with each combination of option values being one variant.⁴ What the platform does with the canonical on those URLs is the part to check in your theme.

I default to one page per product group with parameter URLs for the variants. It concentrates links and reviews on one URL, it keeps the number of indexable pages down, and it matches how most shoppers search, which is for the product and then for a size. I move a dimension to separate pages only when both of these hold:

• People search for the variant by name. A colour that appears in searches ("green wool coat") or a model size with its own name may qualify. A clothing size almost never does.
• The page would differ in ways that matter to a shopper: different photos, specifications, description or price.

A mixed setup is common and fine. A coat might get one page per colour, because colours are searched and photographed differently, with sizes selected by parameter within each colour page. Decide this per dimension, and write it down, because the canonical, markup and feed rules all follow from it.

Category listings raise the same question from the other side. Baymard Institute's 2025 product list benchmark, which scored more than 170 leading ecommerce sites in the US and Europe, found 42% did not combine a product's variations into one list item. Its research treats combining them as the way to help shoppers judge the range and find the variation they want.⁵ One listing tile per product group, linking to the base URL, also fits the single-page model and sends internal links to the canonical.

For a single-page setup, there must be only one distinct canonical URL for the whole product group, and the example given is the base URL with no variant selected.¹ Every parameter URL for a variant should carry a rel="canonical" pointing at that base URL.

For a multi-page setup, the single-canonical requirement does not apply, because no single URL represents the group.¹ The documentation does not spell out the canonical for each variant page. My approach is that every variant page you want indexed canonicalises to itself. Pointing a colour page's canonical at a different colour tells Google you do not want the first page in the index, which defeats the point of building it.

Whichever setup you use, keep the signals consistent. Redirects and rel="canonical" are strong canonical signals and sitemap inclusion is a weak one, and different canonical URLs should not be specified for the same page using different methods.⁶ In practice that means the sitemap lists the canonical URLs only, internal links from category pages point at the canonical URLs, and the feed's canonical_link (covered below) agrees with the page.

Put the canonical in the server-rendered HTML and leave it alone when a shopper picks a variant. The HTTP Archive's 2025 Web Almanac found that rendering changed the canonical on 3.02% of mobile sites in its crawl.⁷ A variant picker that rewrites the canonical in JavaScript is one easy way to join them.

Google's variant markup uses a ProductGroup for the shared product and a Product for each variant. The group needs a name, and the recommended properties include productGroupID (the parent SKU), variesBy to list the dimensions that change, and hasVariant to nest the variants, along with properties such as brand and description.¹ variesBy takes schema.org property URLs such as colour, size, material, pattern, suggested age and suggested gender.¹

This markup makes products eligible to show variant information in merchant listing experiences.¹ Product rich results support pages focused on a single product or on several variants of the same product,⁸ which is why a variant page that drifts into listing unrelated products causes problems.

Merchant Center has its own variant model, and it maps closely onto the markup. The item_group_id attribute is required for free listings with product variants, and for Shopping ads for variants in several countries including the United Kingdom and the United States.⁹ The parent SKU is the recommended value. Keep it stable once assigned, and do not submit one at all for products that are not variants.⁹

Other product feeds use the same model, so one well-kept parent SKU serves all of them. In Microsoft Merchant Center, itemGroupId groups the variants of a product, typically items that vary by colour, material, pattern or size, and must be unique within a catalogue and no longer than 50 characters.¹⁰ OpenAI's product feed for ChatGPT uses a group_id shared by all variants, with one row per variant carrying its own price, availability, URL and images.¹¹

The two link attributes are the part most often confused. Merchant Center's link should take the shopper to the exact variant, for example ?color=red.² Its canonical_link attribute tells Google which URL to use when matching the product to the Search index. Use it when your links contain tracking or variant parameters. It should have no preselected variants, and the help page's example has two dress variants sharing one base URL.¹² It is optional: if the landing page already declares a canonical, you do not need to submit it, and if the two differ, Google chooses using its own signals.¹²

On a multi-page setup, the feed still groups the variants under one item_group_id, and each item's link and canonical_link would normally both be its own variant page. Grouping in the feed and separate canonical pages on the site are compatible.

• A variant link that loads the default colour, so the shopper sees a different product from the one in the ad or listing. Merchant Center asks that the landing page details match the submitted title, colour, price, availability and image.⁹
• Variant parameter URLs blocked by a robots.txt rule written for category filters.
• A productGroupID on the page that differs from the feed's item_group_id, often because one system uses the parent SKU and the other an internal product ID.
• Bundles and multipacks grouped as variants. Item group IDs are only for products that are variants.⁹
• A feed link that redirects. Microsoft Merchant Center says the URL may not be redirected,¹⁰ so point every feed at the final variant URL, not a tracking or legacy address.
• Colour pages built for search that canonicalise back to a parent page, so none of them can be indexed.
• A sitemap that lists every variant parameter URL on a single-page setup, which sends a weak signal against the canonical you declared.

Variant URLs and filter URLs often share parameter names, so decide both together. The method for choosing which filtered pages to index is in the post on faceted navigation.