Retailers: when a product variant deserves its own page
A shoe offered in eight sizes and six colours produces forty-eight URLs competing for the same query. The canonical tag, the instruction that tells Google which page to favour among similar versions, does not solve the problem: Google states that no method is mandatory and that it selects the representative URL itself. Your signal is a suggestion.
- Google describes canonical URL selection as a deduplication process in which it picks the page most representative of a set of duplicate pages.
- No signalling method is mandatory. Without a stated preference from you, Google identifies on its own the version it judges most relevant.
- A canonical tag can be ignored if the pages are not similar enough. Google recommends that a large part of the duplicate page's content be present in the canonical version.
- Two canonical tags on the same page cancel both. It is the most frequent mistake on automatically generated catalogues.
- The real decision is architectural: a variant deserves its own page only if it has search demand and content of its own.
On this page
What is the distinct page threshold
The distinct page threshold is the criterion that determines whether a product variant deserves its own indexable URL or should remain an option on a single page. It rests on two cumulative conditions: search demand specific to that variant, and content genuinely different from the other versions. Below the threshold, the variant becomes an option rather than a page, which avoids scattering signals across competing URLs.
Forty-eight pages for one shoe
This piece is written for ecommerce managers and owners whose catalogue carries products with variants: shoes, clothing, furniture, hardware, parts. It is about architecture, not content.
The math is mechanical. A shoe model offered in eight sizes and six colours produces forty-eight combinations. If each one gets its own URL, a catalogue of four hundred models generates 19,200 pages for four hundred actual products.
Those pages are nearly identical. Same description, same specifications, same reviews, often the same photo except for the colour. They target the same query and compete with each other for it.
Contrary to a persistent belief, the result is not a penalty. It is dilution: the links, mentions and signals that should have accumulated on one page spread across forty-eight, and none reaches the weight needed to rank well.
The consequence is commercial before it is technical. A weaker average position on your best-selling models translates directly into lost sales, and the advertising budget then buys back traffic that organic, that is, the free visits coming from search results, should have produced. That is spending that compensates for an architecture mistake, not an acquisition decision.
On a large catalogue, this multiplication also hits your crawl budget, that is, the limited time Google's crawler grants to exploring your site. A crawler that walks through 19,200 near-identical URLs spends less time on your new arrivals and on the pages that sell. The topic is covered from the faceted navigation angle in our corpus, and the logic is the same.
The canonical tag is a suggestion
This is the point most vendors present backwards, and it completely changes how you approach the problem.
Google describes canonical URL selection as a deduplication process: it selects the representative URL for a piece of content from a set of duplicate pages, so that only one version appears in its results.
The documentation is explicit about the status of your signal: Google encourages the use of canonical methods, but none is mandatory, and a site gets by without stating a preference. If you do not state one, Google identifies on its own the version it judges objectively most relevant.
You express a preference, and the engine decides. Setting a canonical tag is not a fix: it is a signal, followed or not depending on the quality of your architecture.
Google also notes that the different methods overlap and become more effective combined. A tag on its own is worth less than a tag backed by consistent internal linking, that is, the links your pages make to each other, and by a sitemap pointing to the same URL.
The distinct page threshold
Rather than canonicalizing after the fact, decide upstream which variants deserve a page. Two conditions, cumulative.
Search demand of its own. Do people search for this variant by name? "Black work boot" has demand. "Black work boot size 10.5" does not. Colour often deserves a page, size almost never.
Genuinely different content. Photos specific to the variant, specifications that change, a distinct use. If the only difference between two pages is an attribute value, they are not two pages.
| Variant type | Own demand | Different content | Decision |
|---|---|---|---|
| Size | No | No | Option on the product page |
| Colour | Often | Own photos | Distinct page if demand exists |
| Material or finish | Often | Different specifications | Distinct page |
| Format or capacity | Yes | Different price and use | Distinct page |
| Quantity per pack | Rarely | No | Option |
This table settles the majority of cases in a retail catalogue. What stays ambiguous gets decided by looking at real demand, not the product team's intuition.
The cost of getting it wrong is not symmetrical. Creating too many pages scatters your signals and inflates the catalogue's maintenance cost. Creating too few deprives you of revenue on variants your customers search for by name. The first case gets fixed at the template level, the second requires producing content, so it costs more to repair.
The mistakes that cancel your canonical
Two tags on the same page. Google states that if you specify more than one rel canonical element, all of them are ignored. It is frequent when a plugin and a template each set one.
Pages too different to be canonicalized. Google recommends that a large part of the duplicate page's content be found in the canonical version. If the topic is close but the wording very different, the tag risks being ignored.
The canonical pointed at the wrong page. The URL you indicate must be the one you want to see in the results. An automated generation error goes unnoticed for months.
The canonical used for pagination. Google specifies that pointing the subsequent pages of an article to the first one is not a correct use, since they are not duplicate pages, and that the content of the subsequent pages risks not being taken into account.
Contradictory signals. A tag that designates one URL while internal linking and the sitemap designate another weakens the signal instead of strengthening it.
The first and the fifth are the most common on automatically generated catalogues, and both can be detected in an hour of checking. It is the best ratio of time invested to revenue protected in this whole file.
What dilution costs
This cost does not present itself as a penalty, and that is what makes it hard to see.
It takes three forms. Weaker positions, because the weight acquired spreads across several URLs instead of accumulating. Crawl budget consumed by pages without value, at the expense of your new arrivals. And an unpredictable URL in the results, where Google sometimes shows a marginal variant rather than your main page.
The third form is the most expensive in conversion. A buyer who searches for a model and lands on the size 6 variant of a colour they did not want leaves more often than they continue their visit.
Put a number on it like any other loss. If 12% of your organic entries on product pages land on an irrelevant variant, and those sessions convert half as well, the loss is calculated directly from your organic revenue. On $600,000 of organic revenue, the order of magnitude reaches a few tens of thousands of dollars a year.
Check what Google actually chose
It is the check almost nobody does, and it takes an hour.
Your signal and Google's decision are two different things. Site owner tools show, for a given URL, the canonical you declared and the one Google selected. When the two differ, your architecture is not saying what you think it says.
Take twenty product pages representative of your product families and compare the two values. A systematic gap on one family signals a template problem, not a page problem.
Then look at which variant URLs actually receive organic entries. If size variants show up among your entry pages, your distinct page threshold is too low and the fix happens at the template level, for the whole catalogue at once.
What to settle before touching the tags
Canonicalization is the consequence of an architecture decision, not a patch applied after the fact. These five questions get settled before any technical work.
- How many URLs does your catalogue generate, for how many genuinely distinct products?
- Which variants have search demand of their own, verified rather than assumed?
- On twenty product pages, is the canonical you declare the one Google selected?
- Do size or quantity variants appear among your organic entry pages?
- If the fix requires rebuilding the product template, who decides, and on what budget?
The answer that holds up gives a ratio of URLs to actual products, and verified search demand per variant. A hollow answer talks about duplicate content and penalties. A vendor who proposes setting canonical tags without having looked at which canonical Google chose is applying a method without measuring its effect.
Measuring the gap between your URLs and your actual products, and checking Google's choices, is part of what we deliver in a paid audit.
What stays with you: the distinct page threshold decision, which commits the structure of the catalogue, and the trade-off between the technical effort and the expected commercial gain. What gets delegated: counting the URLs, verifying demand per variant, comparing declared and selected canonicals, fixing the templates and tracking the entry pages. A company that decides its threshold before generating its catalogue never has this problem. A company that sets tags on a poorly designed architecture moves the problem without solving it, pays twice, and rediscovers it at the next redesign with a bigger catalogue.
This work sits inside the wider picture described in a complete guide for SMBs and large companies.
Making a heavy catalogue genuinely perform in search is at the heart of the Attract customers with SEO and AI goal.
Your catalogue runs past several tens of thousands of SKUs? See our work in ecommerce.
These URL choices are made before generating the catalogue: the method is in our article on the URL architecture of a large catalogue.
Frequently asked questions about variants and canonicalization
Does duplicate content trigger a penalty?
No, and that belief leads to bad decisions. Google handles duplicate pages through a deduplication process: it chooses the representative URL and shows only one. The cost is not a sanction, it is signals scattered across several URLs and crawl consumed with nothing in return.
Do you need a page per colour?
Only if the colour has search demand of its own and genuinely different content, notably its own photos. On many catalogues, colour clears the threshold and size never does. Verify the demand rather than trusting the product team's intuition: every page created without real demand costs maintenance and brings in no customer.
Is my canonical tag always respected?
No. Google states that no signalling method is mandatory and that it identifies on its own the version it judges most relevant. A tag can also be ignored if the pages are not similar enough. Check in your site owner tools which canonical Google actually selected.
Can you use the canonical on pagination pages?
Google specifies that pointing the subsequent pages of an article to the first one is not a correct use, since they are not duplicate pages. The content of the subsequent pages then risks not being taken into account. Pagination is handled differently from duplication.
What about a catalogue already generated with one page per combination?
Fix it at the template level, never page by page. A single template change settles thousands of URLs at once, at a cost that bears no comparison with a one-by-one fix. Plan the redirects from the old URLs to the page you keep, and then check which canonicals Google actually selects, rather than assuming the fix was understood.
How long before you see an effect?
Count on several weeks, the time it takes the engine to recrawl and re-evaluate the whole set. On a very large catalogue, the full effect can take a few months, because recrawling depends on the available crawl budget. Track the share of your organic entries landing on the right page, and the revenue that flows from it, rather than the ranking of a single query.
- Google Search Central, What is canonicalization, official documentation, accessed July 2026. Source for the description of the deduplication process and the causes of duplication.
- Google Search Central, How to specify a canonical with rel canonical and other methods, official documentation, accessed July 2026. Source for the non-mandatory status of the methods and the consolidation of signals.
- Google Search Central, 5 common mistakes with rel=canonical, accessed July 2026. Source for the treatment of multiple tags, the content similarity requirement and the pagination case.
- Falia working framework, arithmetic of the number of URLs generated by variants. Volumes are explicit scenarios, to be redone with your own catalogue.
Geneviève puts the strategy for your engagement into action. She leads all our web development projects: Shopify, WordPress and the new ways of building a site with AI. She manages our team of developers and translates your business needs into technical language. She runs your organic search (SEO), your visibility in AI answers (GEO) and your site's conversion rate optimization (CRO). Her work is at the heart of three goals: Attract customers with SEO and AI, Improve your site's conversion, and Strengthen your visibility in AI answers. With Gabriel, she also builds the landing pages for your advertising campaigns. She writes mainly about SEO, AI visibility and web design.
About Falia →
SEO
Paid advertising
Conversion
AI visibility
Web design