Keyword cannibalization on ecommerce sites
Ecommerce keyword cannibalization does not look like the blog version of the problem. On a content site two articles compete and you merge them. On a store the competition is generated automatically — by faceted navigation, by product variants, by category pages that overlap with collection pages, and by a search feature that indexes its own results. The pages multiply faster than anyone can audit them by hand, so the fix has to be a rule about which URLs may be indexed, not a page-by-page decision.
Run the Keyword Cannibalization Checker on your site — free, no account.
The four sources, in order of damage
1. Faceted navigation
Filters are the biggest generator. A category with five filter dimensions can produce thousands of crawlable URLs, most of them serving a subset of the same products with the same template copy. When several of those are indexable, they compete with the category page and with each other for the same head term.
The tell is a Search Console query where the serving URL keeps changing between a clean category path and a parameterised one.
2. Category vs collection vs landing page
Most stores accumulate three URLs for one commercial term: the platform's category page, a hand-built collection or landing page created for a campaign, and sometimes a blog post targeting the same phrase. Each was created by a different person for a different reason and nobody retired the others.
3. Product variants
Size and colour variants as separate indexable URLs are duplication rather than competition in most cases, since nobody searches for the variant. They matter here because they consume the crawl allocation that should be reaching your category pages — a crawl efficiency cost rather than a ranking one.
4. Internal search results
Indexable /search?q= URLs are the worst case, because they generate a page for any query anyone types and each one competes with a real category. If your platform indexes internal search results, that is usually the first thing to switch off.
Deciding which URLs may be indexed
The whole ecommerce problem reduces to one policy decision, applied consistently: which generated URLs are allowed to be indexable? Answer it once and most cannibalization stops being created.
URL type index? canonical to ------------------------------ ------ -------------------- category page yes itself one high-demand facet value yes itself multi-facet combination no parent category sort order / view / pagination no* itself (rel prev/next gone) product page yes itself product variant no parent product internal search results no -
The interesting row is the second. Some facet values have genuine search demand — a colour, a brand, a size that people actually query — and those deserve to be real, indexable landing pages with their own copy. The rule is that a facet earns indexation by having demand, not by existing.
Do not block facets in robots.txt Blocking a URL in robots.txt stops it being crawled, which means the canonical tag on it is never read and any links pointing at it pass nothing. Use noindex or canonicalisation for URLs that should not rank, and reserve robots.txt for URLs a crawler should not fetch at all.
Finding it on a store with thousands of URLs
The manual Search Console workflow does not scale past a few dozen checks, so on a store you attack it in two passes.
- Query-side, at the head. Take your top 50 commercial terms and check the Pages tab for each. These are where cannibalization costs actual revenue, and 50 checks is an afternoon — see finding cannibalization in Search Console.
- Structure-side, everywhere else. Crawl the site and group pages by title and heading similarity. On a store this surfaces the template-generated overlaps in bulk, which is exactly the part the query data cannot show you because most of those URLs have no impressions yet.
The second pass is the one that finds the generator rather than the symptom. If forty URLs share a title pattern differing only by a filter value, you do not have forty problems — you have one indexation policy that needs changing.
Fixing the category-vs-collection overlap
This is the case that needs human judgement rather than a rule, because both pages are usually legitimate.
- Pick the survivor on commercial performance first, not on rankings. The page that converts is the one worth ranking.
- Move the useful content — buying guidance, comparison tables, FAQs — onto the survivor. Campaign landing pages usually hold the better copy and the category page usually holds the links.
- 301 the other, then repoint every internal link at the survivor rather than letting it redirect.
- Rewrite the navigation and breadcrumb anchors so one phrase points at one destination.
- Confirm the survivor ends up with more inbound internal links than either page had alone.
Step 5 is the one that decides whether it worked. Consolidation helps because signals concentrate; if the survivor did not actually gain links, nothing concentrated. That is a question about how authority moves through your internal links, and on stores it is usually answered by the navigation rather than by editorial links.
Keeping it from coming back
- Write the indexation policy down and apply it in the platform template, not per URL. Every manual exception becomes next year's cannibalization.
- Require a demand check before any new facet is made indexable.
- Audit after seasonal campaigns — that is when duplicate collection pages get created and abandoned.
- Retire campaign landing pages on a schedule rather than leaving them live indefinitely.
- Re-crawl quarterly and compare the count of indexable URLs against your product count. A ratio that keeps climbing means the generator is back on.
The last check is the most useful single number on an ecommerce site. Products grow linearly; indexable URLs should too. When they grow faster, something templated is producing pages nobody decided to publish. If some of those pages end up with no internal links at all, they also become orphan pages — the same generator causes both problems.
FAQ
Do product variants cause keyword cannibalization?
Rarely in the ranking sense — almost nobody searches for a specific size or colour variant, so the variants are not competing for a query. They are duplication, and their real cost is crawl budget. Canonical variants to the parent product rather than redirecting them, since customers still need to reach each one.
Should faceted navigation URLs be indexed?
Only the facet values with genuine search demand, and those should get real landing-page treatment with their own copy. Multi-facet combinations should canonical to the parent category. A facet earns indexation by having demand behind it, not by existing.
Should I block filter URLs in robots.txt?
No. Blocking crawl means the canonical tag on those URLs is never read, and any links pointing at them pass nothing on. Use noindex or canonicalisation for pages that should not rank, and reserve robots.txt for URLs that should never be fetched at all.
My category page and my collection page target the same term. Which should I keep?
Keep the one that converts better and move the better content onto it. Campaign landing pages usually have the stronger copy while category pages usually have the stronger internal linking, so the merge normally means moving copy onto the category page rather than the reverse.
Should internal site search results be indexable?
No. They generate a page for any string anyone types, each competing with a real category page, and they are the fastest way to fill an index with near-duplicate thin pages. Noindex them and make sure they are not linked from crawlable navigation.
How do I find cannibalization across thousands of product URLs?
Two passes. Check the Pages tab in Search Console for your top 50 commercial queries, since that is where cannibalization costs revenue. Then crawl the site and group pages by title and heading similarity to find the template-generated overlaps in bulk, which is the part the query data cannot show because most of those URLs have no impressions yet.
Put this into practice
Run the Keyword Cannibalization Checker to see this on your own site, or run the full structural audit for the complete picture — both free, no account required.