What cannibalisation actually is
Google picks one page per site for most queries. When you have several pages that could plausibly answer the same query, it has to choose, and the signals telling it which to choose are split — your links, your anchor text and your relevance are spread across the candidates instead of concentrated on one.
The result is a page that ranks in position 11 when a consolidated version would rank in position 6. Nothing is broken and nothing is penalised. You're just competing with yourself and paying for it in positions.
The word makes it sound dramatic. Usually it's mundane: a service page and a blog post written eighteen months apart by people who never spoke, both aimed at the same buyer, both half-answering the question.
- It is not a penalty. Google has no cannibalisation filter. This is a signal-dilution problem, not an enforcement action.
- It is not caused by repeating a keyword across your site. Mentioning a phrase on twenty pages is normal. Building twenty pages *about* that phrase is the problem.
- It is most common on sites over about 100 pages that publish without a keyword map, and on ecommerce sites where categories and filter pages overlap.
The detection method: URL flipping in Search Console
Ignore the tools that offer a "cannibalisation report". Most of them flag any query where two URLs got an impression, which describes half a healthy site. The reliable method uses Search Console and takes about five minutes per query.
- Open Performance → Search results and set the date range to the last 12 months so you have enough weeks to see a pattern.
- Add a Query filter set to the exact target query. Everything from here on is that one query.
- Switch to the Pages tab. This lists every URL of yours that earned an impression for that query. One URL with the overwhelming majority of impressions is healthy. Two or three with comparable shares is your first flag.
- Now check for flipping. Keep the query filter, add a Page filter for URL A, and look at the average position line across the year. Then swap the page filter to URL B and do the same.
- Read the two lines together. If A holds position while B sits far behind, that's fine — one page owns it. If A and B take turns, one climbing as the other falls, Google is switching between them. That's cannibalisation.
- Confirm with the Compare function: set two date ranges three months apart, filter to the query, and see whether the top URL changed. A changed winner with no content changes in between is the clearest evidence there is.
When two of your pages ranking is completely fine
This is where most cannibalisation audits go wrong. Multiple URLs appearing for one query is normal, common and often good. Before you merge anything, check whether you actually have a problem.
- Different intents behind the same words. An explainer about SEO costs and a pricing page can both surface for cost-related queries and serve different people. Both convert, in different ways. Leave them.
- Head term and long tail. Your pillar page owns the broad query, a detailed post owns a specific variant. That's a working topic cluster, not a conflict.
- Brand queries. Google routinely shows several pages from one site for a brand search, sometimes as sitelinks. That's coverage.
- The 'wrong' page ranks but converts better. If a blog post outranks your service page for a commercial query and produces more enquiries than the service page ever did, the ranking is not the problem. Fix the service page's copy instead of demoting the post.
- Impressions are trivially small. A query with 40 annual impressions doesn't justify a merge, a redirect and a regression risk.
Four fixes, ranked by risk to existing traffic
Once you've confirmed a real conflict, there are four ways out. They're listed here from safest to most destructive, which is also the order you should consider them in — most people reach straight for the merge and lose traffic they didn't need to lose.
| Fix | What it does | Risk to existing traffic | Right when |
|---|---|---|---|
| 1. Differentiate | Rewrite titles, H1s, openings and internal anchors so each page targets a distinct intent. Nothing deleted, nothing redirected. | None — fully reversible | The pages cover genuinely different intents but were written as if they didn't. |
| 2. Canonical the loser to the winner | Both URLs stay live for users; ranking signals consolidate on one. | Low to medium — the loser's own long-tail traffic goes | The pages are near-duplicates but both need to remain reachable. |
| 3. Merge and 301 | Combine the best of both into one URL, redirect the other permanently. | Medium — biggest upside, and hard to walk back | The pages say the same thing and only one deserves to exist. |
| 4. Noindex the loser | Removes it from the index. Passes nothing anywhere. | Highest — the page's signals are simply discarded | Users need the page, search never should. A filter view, an ads landing page, a thin variant. |
Why differentiate goes first
It's free, it's reversible, and it frequently reveals that you never had a duplication problem — you had two pages with near-identical titles and openings that happened to cover different ground. Rewriting the title, the H1, the first hundred words and every internal anchor pointing at each page fixes a surprising number of cases in an afternoon.
It fails when the pages genuinely duplicate each other. If you can't articulate two different jobs for them, move down the list.
Why noindex goes last
Noindex removes a page from the index and consolidates nothing. Whatever links, age and relevance that URL had accumulated go nowhere — unlike a canonical or a 301, which pass them to the survivor. Using noindex on a page with real history is the most expensive mistake in this list, and the most common.
The one case where it's correct: the page must exist for humans but must never compete. See canonical vs noindex for the full decision.
The honest caveat: it's over-diagnosed
A lot of what gets reported as cannibalisation is just two pages both being mediocre. Merging two thin pages does not produce one strong page — it produces one thin page with a redirect pointing at it, and the position doesn't move.
Before you merge anything, ask what the merged page will do that neither page does now. If the answer is "be longer", stop. The problem isn't overlap, it's that neither page is good enough to rank, and consolidating two weak pages doesn't create strength.
The other frequent misdiagnosis is a ranking drop blamed on cannibalisation when the real cause is a core update, a lost link or a competitor publishing something better. Check the date the position changed against Google's update history before you restructure a section of the site around a theory.
And one operational rule: never resolve cannibalisation by deleting a page and letting it 404. If a URL has to go, redirect it. A 404 discards everything the page earned, for no benefit over a redirect that costs nothing.
Preventing it with a keyword map
Detection and fixing are both cleanup. The version of this problem you actually want is the one that never happens, and it's prevented by a single document.
A keyword-to-URL map assigns every target query exactly one owning page. Before anyone commissions an article, they check it. If the query has an owner, the brief becomes "improve the existing page" rather than "write a new one" — which is where roughly all cannibalisation gets created. The map also gives every internal link a single correct destination and anchor, so your own linking stops splitting the vote. The build process is set out in keyword-to-URL mapping.
Run a quarterly check alongside it: pull your top 50 target queries from Search Console, count distinct URLs earning impressions for each, and review anything with more than one. Fifteen minutes a quarter, and it catches conflicts while they're still cheap to fix.