Canonical Tags for Product Variants

The answer: choose a variant model and hold to it

Google documents two valid ways to canonicalize product variants: keep all variants on one page and canonicalize every variant URL to the parameter-free base URL, or give each variant its own page that stays its own canonical. Neither is wrong; what breaks is a site that mixes them, with some color URLs consolidating, others self-canonical, and internal links and sitemaps pointing at a third set.

A product variant is one purchasable combination of a product's attributes, such as a t-shirt in green, size M. Google's ecommerce guidance says each variant can be addressed by its own URL, either as a path segment (/t-shirt/green) or a query parameter (/t-shirt?color=green, or Shopify's ?variant= ID). The choice between the two models is really a choice about what should be indexed: the product, or each version of it.

Variants and category paths are different problems

Ecommerce duplication usually gets discussed as one issue, but two unrelated situations produce it, and they call for different answers.

The distinction matters because the reasoning that justifies consolidating a category path (identical content, nothing lost) does not carry over to variants. A red coat and a green coat are different offers. Canonicalizing one to the other is a decision to stop the red one from being indexed as itself, and that should be made on purpose, not inherited from a rule written for duplicate paths.

Google's single-page and multi-page models

Google's product variant structured data documentation, which added support for the Schema.org ProductGroup type in February 2024, describes how a site can be built either way.

Single-page model

All variants live on one product page and a selector switches between them. Google requires one distinct canonical for the whole ProductGroup, typically the base URL with no variant preselected. That does not mean the variant URLs can disappear. Each must load with its variant already selected, showing the right image, price and availability and allowing that variant to be added to the cart, because that is how Google crawls and identifies individual variants. Each variant's offers.url in the markup carries its own parameterized address.

Multi-page model

Variants are spread across separate pages, for instance one page per color. The ProductGroup definition is repeated on each page, with full markup for the variants that page sells and a URL-only stub for the variants that live elsewhere. Google does not state a canonical rule for this model on that page. The natural reading, and the only one consistent with repeating full markup per page, is that each variant page is its own canonical; consolidating them to a parent would hide the very pages the markup describes.

Google's ecommerce URL structure guide adds the rule that ties both models together: if variants are identified by optional query parameters, the URL without the parameter is the canonical, and the same URL should appear in internal links, sitemaps and canonical tags.

Consolidate or self-canonicalize: how to decide

The deciding fact is what happens to text on a non-canonical URL. Mueller put it plainly in 2018: content on non-canonical versions "generally doesn't get used." If a red variant URL points its canonical at the base product, the word "red" in its title, its GTIN and its unique photos are not what Google indexes.

Consolidate to the base URL (single-page model) when:

• variants differ by a selector state on otherwise identical pages, as sizes usually do;
• search demand is for the product, not for individual versions;
• per-variant copy and imagery are thin or shared.

Give variants their own canonical pages (multi-page model) when:

• a variant has its own search demand, the way a specific colorway of a sneaker often does;
• it has its own images, copy, GTIN and price;
• the goal is for it to rank and appear as an offer in its own right.

A store can use sizes on one page and colors on separate pages; that is still consistent, because each product applies one rule. What is not consistent is a product whose color pages carry self-referencing canonicals while its ProductGroup markup sets the single-page url property, or whose base URL is the canonical while internal links point at ?color= URLs. And a canonical is never the tool for merging genuinely different products; Google treats the declared canonical as a hint and may simply ignore it.

Markup and tags for the single-page model

Every variant URL carries the same canonical, pointing at the base URL:

<!-- served at https://www.example.com/coat?size=small&color=green -->
<link rel="canonical" href="https://www.example.com/coat">

The base URL carries the group markup, with each variant's offer pointing at its preselecting URL. A trimmed outline:

{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "productGroupID": "coat-01",
  "url": "https://www.example.com/coat",
  "variesBy": ["https://schema.org/color", "https://schema.org/size"],
  "hasVariant": [
    {
      "@type": "Product",
      "sku": "coat-01-green-s",
      "offers": { "url": "https://www.example.com/coat?size=small&color=green" }
    }
  ]
}

In the multi-page model the group-level url property is dropped (Google reserves it for single-page sites), each page self-canonicalizes, and the ProductGroup is repeated on every page. In both models each variant needs a unique ID such as a SKU or GTIN, and each group needs a unique ID. Supported variesBy values are color, size, suggested age, suggested gender, material and pattern.

One detail to keep straight: variant URLs in the single-page model must remain crawlable. Blocking ?color= or ?variant= in robots.txt hides both the canonical and the variant offers from Google.

Products that appear in several categories

Category paths have one right answer: a single product URL, linked from every category that lists the product, named in the canonical, and alone in the sitemap. Either drop the category from product URLs or fix one primary path. If the product should show several navigation routes in search, Google's breadcrumb markup allows more than one breadcrumb trail on a single page, so the URL can stay single while the trails multiply.

The canonical is the backstop here, not the fix. Amsive has reported collection-path URLs ranking even though they were canonicalized to the clean product URL, which is what happens when every internal link contradicts the tag.

Each major platform has a specific switch for this. Shopify themes that build product links with the Liquid within filter create collection-path URLs, and removing | within: collection from product-card links stops them being linked. Adobe Commerce's "Use Categories Path for Product URLs" setting creates the duplicates, while "Use Canonical Link Meta Tag for Products" points the canonical at the path-free product URL. WooCommerce defers to WordPress and the SEO plugin, and the usual practice is to canonicalize variation query strings such as ?attribute_pa_color=blue to the parent variable product.

Where Merchant Center fits

Shopping feeds pull in the opposite direction from the single-page canonical, and the two are easy to confuse. Merchant Center wants a different landing page URL for each variant, using a path segment or parameters, and the page must open with that variant's title, color, price, availability and image. That requirement is met by preselecting variant URLs; it does not require those URLs to be the indexed canonical.

The bridge is the optional canonical_link attribute, which Merchant Center labels the Google Search index link. When feed links carry tracking or variant-selection parameters, it names the URL Google should match in the Search index, and it must not itself contain tracking parameters, a preselected variant or a redirect. On a single-page site, link is the preselecting variant URL and canonical_link is the base product URL. Google never lays this reconciliation out in one document, which is why stores sometimes "fix" Merchant Center by self-canonicalizing every variant.

Mistakes and how to catch them

• Consolidating variants and expecting their content to rank. The red page's GTIN and title will not be used once it canonicalizes away.
• Variant state in a fragment (/t-shirt#black). Google treats every fragment as one URL, so it may miss content it assumes is identical.
• Variant URLs that do not preselect. A ?color=green link that loads with the default image and price breaks the single-page requirement and Merchant Center matching together.
• Internal links to non-canonical paths. Collection-path links under a clean canonical send conflicting signals.
• Calling it a penalty. Adobe's documentation uses that word, but Google frames duplicates as a canonical-selection question, not a punishment.

To check the outcome, run URL Inspection on a variant URL and compare the user-declared and Google-selected canonical. In the Page indexing report, "Alternate page with proper canonical tag" is the expected status for consolidated variant and collection URLs, while "Duplicate, Google chose different canonical than user" means Google has not accepted the model. The Rich Results Test and Search Console's merchant listing and product snippet reports validate ProductGroup markup, and Merchant Center diagnostics flag issues such as duplicate variants. A site crawl that compares internal link targets against canonicals catches the category-path leak.

Frequently asked questions