Keyword cannibalization: how to find it, fix it, and stop causing it
Two of your pages are competing for one query. That is rarely a technical fault. It is the visible result of two briefs written months apart by people who could not see each other’s work, and the fix that lasts is in the planning, not the redirect.
What is keyword cannibalization?
Keyword cannibalization is when two or more pages on the same site answer the same search intent, so search engines alternate between them or rank neither as well as one focused page would. The cost is instability and split signals, not a penalty. The cause is almost always planning: a second page was briefed without anyone checking that the first already existed.
The standard definition stops at the symptom. The more useful framing is that cannibalisation is a decision you already made, months ago, without realising it. Nobody sets out to publish two pages on the same question. It happens because the second brief was written without a check against what was published, or because two keywords looked different in a spreadsheet and turned out to mean the same thing to a search engine.
That framing changes the fix. If you treat cannibalisation as a technical fault, you reach for technical remedies: canonicals, redirects, noindex. If you treat it as a planning failure, you also fix the brief process, and the problem stops regrowing. It is the clearest example of why most SEO audits produce nothing that compounds: merge today’s duplicates and leave the briefing process alone, and the same defect returns with next quarter’s content.
Two pages, one intent
Two pages, related intent
One page, many keywords
Keyword cannibalization versus duplicate content
Duplicate content is the same or nearly the same content available at more than one URL: a page reachable with and without tracking parameters, a printer version, an HTTP and HTTPS copy. Google handles that through canonicalization, which its documentation defines as the process of selecting the representative URL of a piece of content. Cannibalisation is different. The two pages are usually written separately, say different things, and both deserve to exist as content. What they share is the job they do for a searcher. Duplicate content is solved with canonical signals. Cannibalisation is solved with an editorial decision about which page does which job.
Some guides use “content cannibalization” for the wider case, where two pages overlap across a whole topic rather than one keyword. The diagnosis and the fixes below are the same; only the number of queries in the sheet changes.
Is keyword cannibalization bad for SEO?
Keyword cannibalization is bad only when two pages serve the same intent and the split is measurably holding the query back. Several of your pages appearing for one query is not, on its own, a problem, and Google’s own public comments on the subject say so directly.
Google’s John Mueller, answering a question on the subject in an exchange reported by Search Engine Journal in September 2025, said that several pages from one site appearing in the same results is not a problem in itself, that pages are not duplicates just because they appear on the same results page, and that Search Console shows data for when pages were actually shown, so cannibalisation that is only theoretical is not really cannibalisation. His practical advice was to reduce unnecessary duplication and put the effort into one excellent page.
Two pieces of Google documentation explain why a genuine overlap still costs something. The ranking systems guide describes a site diversity system that generally shows no more than two listings from the same site in the top results, and deduplication systems that show only the most relevant of several very similar results. Two of your pages competing for the same slot are competing for a limit, not adding to your share. And the canonicalization documentation notes that Google may choose a different page as canonical than you would, because a stated preference is a hint, not a rule.
| Pattern in Search Console | Usually means | Verdict |
|---|---|---|
| One query, ranking URL changes week to week | Google is not settled on which page answers it | Cannibalisation. Differentiate or consolidate |
| Two URLs for one query, both between positions 11 and 20 | Signals split across two weak answers | Cannibalisation. Usually consolidate |
| Two URLs at positions 3 and 7, both clicked, different titles | Two answers to two angles of the query | Healthy. Leave alone |
| One URL, forty query variations | One page covering a topic well | Working as intended |
| A second URL appears with a handful of impressions | Occasional secondary result | Noise. Ignore |
The damage, where it exists, sits in three places. First, instability: when the ranking URL keeps changing, neither page builds a consistent record for the query. Second, your own internal links: every link pointing at the weaker page is a vote cast for the page you did not want to win, which is entirely self-inflicted. Third, at scale, crawling: Google’s crawl budget guide recommends eliminating duplicate content so crawling focuses on unique content rather than unique URLs, though the same guide says it is written for sites with roughly a million or more pages, or ten thousand or more that change daily. On a sixty-page site, crawl budget is not the reason to act.
Keyword cannibalization and AI Overviews
Google’s page on AI features and your website says there are no additional requirements to appear in AI Overviews or AI Mode, and that a page must be indexed and eligible to be shown with a snippet to appear as a supporting link. It also says both features may use query fan-out, issuing multiple related searches across subtopics, which lets them show a wider and more diverse set of links than a classic results page. The page says nothing about several pages from one site competing for the same answer, so do not treat AI visibility as a separate reason to merge pages.
Two practical points do follow. First, the same page notes that traffic from AI features is included in the Search Console Performance report under the Web search type, so the diagnosis below already covers it. The separate Generative AI performance report Google added in June 2026 shows impressions in AI features by page, but, as Search Engine Roundtable reported, no clicks or queries, so it cannot show two of your pages splitting one query. Second, a page that is not indexed cannot be a supporting link at all, which is one more reason not to settle a split with noindex.
What causes keyword cannibalization?
Keyword cannibalization is caused by publishing decisions made without a view of what already exists. The specific causes repeat across almost every site, and each one points at a different control in the content process.
| Cause | How it shows up | Control |
|---|---|---|
| Briefs written without checking published pages | A new post on a question an older post already answers | Target query in the brief, checked against the site before writing |
| Keyword variants treated as separate topics | Singular and plural, or synonyms, given their own pages | Cluster the keyword list before assigning pages |
| Updates published as new posts | A 2026 version beside the 2024 version, both live | Update in place and change the date, do not republish |
| Blog post and landing page on the same commercial term | A guide outranking the product page for a buying query | Decide the page type per intent before writing |
| Tag, category and archive pages | Thin archive pages ranking for the topic of their own posts | Noindex or remove archives that add nothing |
| Template families run over an unchecked list | Hundreds of pages that differ by one noun | Collision check on the source list before generation |
The plural pair is the classic miss. “Onboarding checklist” and “onboarding checklists” look like two rows in a keyword export and are usually one results page. The synonym pair is the expensive one: “customer churn” and “customer attrition” can be the same intent, and no amount of eyeballing the spreadsheet will tell you so. Only the results page will.
The cause that most teams underestimate is the update published as a new URL. A refresh of an old guide feels like new work, so it gets a new brief, a new slug and a launch. The old page keeps its links and history, the new one starts from nothing, and the two then compete for the query the refresh was meant to win.
How to find keyword cannibalization in Google Search Console
Google Search Console is the best place to find keyword cannibalization because it records which of your URLs were actually shown for each query, which is the evidence Mueller pointed to. The method is to start from a query, not from a page, and look at which URLs earn impressions for it over time.
The procedure in the Performance report
- Open Performance, then Search results, and set the date range to the last three months so a single bad week does not drive the decision.
- Add a Query filter for the term you suspect. Use Queries containing for a family of variants, or the Custom (regex) filter, which works on queries and page URLs, to catch singular and plural together, for example
onboarding checklists?. - Open the Pages tab. One URL with nearly all the impressions means there is no problem for this query. Two or more URLs with meaningful impressions is a candidate.
- For each candidate URL, note impressions, clicks and average position for this query. Write them down, because the next steps change the filters.
- Check stability. Narrow the date range to single weeks, or compare the last 28 days against the previous 28, and record which URL led each period. A lead that changes hands more than once is the strongest signal there is.
- Now reverse the filter. Remove the query filter, add a Page filter for the weaker URL, and open the Queries tab. This shows everything the weaker page earns, including the long-tail queries nobody briefed it for.
- Record the result in a sheet: query, both URLs, their numbers, the stability finding, and what the weaker page earns elsewhere. That sheet is the input to the decision in the next section.
Step six is the one most guides skip, and it is the one that prevents the most damage. A page that ranks badly for its target and well for thirty other queries is doing more work than any cannibalisation report suggests.
How Search Console counts two of your pages in one result
Search Console’s numbers behave differently depending on how they are grouped, and misreading them is a common source of false alarms. Google’s Performance report data documentation explains that position is the topmost position held by a link to your property or page, averaged across the queries where it appeared, and that grouping by property counts a single impression where grouping by page counts one for each URL. Data is also attributed to the canonical URL Google selected.
Two consequences follow. Per-page impressions for one query can add up to more than the query’s total in the property view, because when both pages appear on the same results page, the property view counts that once. And a page’s average position for a query only includes the impressions where it appeared, so a weaker page that shows up rarely at position nine can look better than a stronger page that shows up constantly at position twelve. Read impressions and position together, never position alone.
Doing it across a whole site
The interface works one query at a time, which is fine for a suspicion and slow for an audit. For a site-wide check, export query and page data together through the Search Console API, or a connector such as the one in Looker Studio, and then group rows by query. Any query with two or more URLs above a minimum share of impressions, for example 20 percent each, goes on the candidate list. The threshold is a working rule rather than a standard. Its job is to drop the occasional secondary result so the list stays short enough to act on.
Diagnosis checklist: is this real cannibalisation?
Run the checklist once per candidate query, using the numbers from the procedure above. The more items that are true, the stronger the case for acting. Fewer than half usually means the pair is a healthy cluster and should be left alone.
Other ways to detect keyword cannibalization
Search Console is the primary source, but three other methods catch cases it shows poorly: queries where you rank too low to collect impressions, planned pages that do not exist yet, and pages that collide on titles and headings before they ever rank.
| Method | What it finds | What it misses |
|---|---|---|
| Search Console, query then pages | Real overlap on queries you already appear for | Queries where neither page earns impressions |
| Rank tracker cannibalisation report | Tracked keywords where several URLs rank | Anything outside the tracked keyword set |
| site: search with the topic | Pages on the topic you had forgotten about | Whether they actually compete for anything |
| Crawl export of titles and H1s | Pages with near-identical titles or headings | Pages with different titles and the same intent |
| Keyword map check before writing | Collisions before they exist | Nothing published; it prevents rather than detects |
Commercial tools have built reports around the check. Semrush’s documentation describes a Cannibalization report inside Position Tracking that flags tracked keywords where more than one of your pages ranks in Google’s top 100, and Ahrefs suggests filtering organic keywords to those with multiple ranking URLs and checking a keyword’s ranking history, while warning that the filter alone does not always identify a real problem. Both are useful for the same reason: they show positions beyond what Search Console tends to surface. Both share the same limit: a keyword you do not track is a collision you do not see.
The crawl method is cheap and underused. Export page titles and H1s from Screaming Frog or Sitebulb, sort them, and read down the list. Two titles that promise the same thing to a reader are a collision whatever the data says, and catching them here costs nothing.
Avoid treating a site: search as a diagnosis. It shows that pages on a topic exist, which you already knew. It says nothing about whether they compete.
How to fix keyword cannibalization: choosing the right response
The right fix for keyword cannibalization depends on why the pages overlap and what each one earns, not on how similar they look. There are four editorial responses and five technical tools, and the order in which you consider them matters because only some of them can be undone.
Decision rules
The tree below holds the rules, one pair at a time. Pages with different intents are never merged. A stable split where both pages earn clicks is left alone and rechecked next quarter. Everything else is decided by what share of the weaker page’s clicks the contested query provides. Two cases override it: a weaker page that must stay for users, such as a support article, a changelog entry or a page sales sends to prospects, is demoted rather than redirected; and true copies that must both exist, such as a print version or a parameter variant, take rel=canonical.
Yes
No, the same intent
Yes
No
Under a third
A third to two thirds
Over two thirds
What the technical tools actually do
| Tool | What Google’s documentation says | Use it when |
|---|---|---|
| 301 or 308 redirect | A permanent server-side redirect is the recommended method, and Google treats it as a signal that the target should be canonical | You are retiring the weaker page after a merge |
| rel=canonical | A strong signal for which URL should be canonical, but a hint rather than a rule | Both URLs must stay live and are near duplicates |
| Sitemap inclusion | A weak canonical signal | Always, as support for the other two, never alone |
| noindex | Not recommended for choosing a canonical within a site, because it removes the page from Search entirely | The page has no search value at all, such as a thin tag archive |
| Delete and return 404 or 410 | A strong signal not to recrawl | The page has no traffic, no links and no users |
The sources for that table are Google’s documentation on redirects, on consolidating duplicate URLs and on crawl budget. The row worth rereading is noindex. It is the most common reflex fix for cannibalisation and the documentation advises against it for exactly this purpose: it does not pass the weaker page’s signals to anything, it just removes the page.
Demotion deserves more use than it gets. Google’s link guidance says that every page you care about should have a link from at least one other page and that anchor text tells people and Google what the linked page is about. Read the other way, your internal links are the strongest statement you control about which page is the answer. Pointing them at the page you want to win, with anchors that name the query, is often enough to settle a split without touching either page’s URL. The mechanics of auditing those links are in the guide to treating your internal link graph as a product decision.
A worked example: two pages, one query
A worked example shows why the decision rests on what the weaker page earns elsewhere rather than on the overlap itself. The site and figures below are hypothetical, chosen to make the arithmetic clear.
Take a hypothetical SaaS site with two pages: an older guide, /blog/customer-onboarding-checklist, and a newer page, /blog/saas-onboarding-checklist-template. Over three months in Search Console, for the query customer onboarding checklist:
| URL | Impressions | Clicks | Avg. position | Weeks leading |
|---|---|---|---|---|
| Guide (older) | 4,100 | 62 | 12.8 | 7 of 13 |
| Template page (newer) | 2,900 | 21 | 16.3 | 6 of 13 |
The lead changes hands repeatedly, and both pages sit on page two. On the pattern table earlier, this is cannibalisation. A quick reading says merge the template page into the guide.
Step six of the procedure changes that. Filtered to the template page alone, Search Console shows 380 clicks over the same three months. Only 21 of them come from the contested query, which is 21 divided by 380, or about 5.5 percent. The other 359 clicks, about 94.5 percent, come from queries such as onboarding checklist template and onboarding checklist excel, where the guide does not rank at all.
Merging would put 359 clicks at risk to resolve an overlap worth 21. The right response is to differentiate. Retitle the template page around the template, make its opening say plainly that it is the downloadable version, and link from it to the guide with an anchor naming the checklist. Retitle the guide around the process, and link from it to the template with an anchor naming the template. Each page now owns one intent.
The rule generalises. Divide the weaker page’s clicks on the contested query by its total clicks. A low share means the page has its own job and should be differentiated. A high share means it exists mainly to compete and should be consolidated. There is no exact cut-off, and the thirds are a working rule rather than a published standard: under a third, differentiate; over two thirds, consolidate. For a share in the middle band, the method I use is to differentiate or demote first, because both can be undone, and to consolidate only if the split is still there at the twelve-week review.
Calculate the share for your own pair
Take both numbers from Search Console for the same three months: filter to the weaker page alone for its total clicks, then add the query filter for its clicks on the contested query. The formulas: contested share = contested clicks / total clicks x 100, and clicks at risk in a merge = total clicks – contested clicks. The defaults reproduce the template page: 21 / 380 = 5.5 percent, with 359 clicks earned elsewhere.
Use the same date range for both numbers.
How to merge two pages without losing traffic
Merging two pages without losing traffic depends on sequence: move the content first, then the internal links, then the redirect. Most traffic lost in a consolidation is lost by doing those three in a different order, or by discarding the sections that earned the weaker page’s long tail.
- Export what both pages earn. Pull the full query list for each URL from Search Console, plus the backlinks pointing at each from Ahrefs, Semrush or Majestic. This is your inventory of what must survive.
- Map sections to queries. For every query the weaker page earns with real clicks, find the section that answers it. Those sections move. Sections that earn nothing can go.
- Build the merged page on the stronger URL. Keep the stronger page’s URL, usually the one with more referring domains and more clicks overall, since it carries the most history. Integrate the moved sections as proper sections with their own headings, not as an appendix.
- Update internal links. Change every internal link pointing at the weaker URL so it points directly at the merged page. Use a crawler to find them all, including links inside old posts.
- Add the permanent redirect. A 301 or 308 from the weaker URL to the merged page. Then remove the weaker URL from the XML sitemap.
- Ask the biggest referrers to update. For backlinks that matter, an email asking for the link to be updated is worth sending. The redirect covers the rest.
- Request indexing of the merged page with the URL Inspection tool in Search Console, and record the date of the change.
- Set the review dates before you ship. Four weeks and twelve weeks after the change, compare the merged page against the combined baseline of both pages.
Redirecting before the content moves
Keeping only the stronger page’s content
Leaving internal links on the old URL
Merging pages with different intent
Expect the first weeks after a consolidation to be noisy while Google recrawls both URLs and processes the redirect. Judging a merge in its first fortnight is how teams undo changes that were working. Keep the redirect in place permanently: Google’s redirect documentation says to use permanent redirects when you are sure the redirect will not be reverted, which is exactly the commitment a merge requires.
Keyword cannibalization at scale: template families
Keyword cannibalization at scale comes from generating pages from a template over a keyword list that was never checked for collisions. The template then reproduces one collision as many times as the list has near-identical rows.
A location page for every city, a comparison page for every competitor pair, an integration page for every tool. Each is defensible on its own. Together they can produce hundreds of pages whose differences are a noun and a number, competing for queries that differ by the same noun. The generation is not the fault. The unchecked source list is.
| Scale | How it arises | What it costs | Fix |
|---|---|---|---|
| 2 pages | Two briefs, months apart | One query with an unstable ranking URL | Differentiate or consolidate |
| 20 pages | A cluster planned without clustering | A pillar that cannot win its own topic | Re-plan the cluster, merge the overlaps |
| 200+ pages | A template run over an unchecked keyword list | Crawl spent on near duplicates, and self-competition at scale | Fix the source list, then regenerate |
A test catches the large case before generation. Take the list the template will run over and ask whether any two rows would produce pages a reader could not tell apart from their titles alone. If so, the list is the problem, not the template. The fuller treatment, including coverage thresholds for whether a generated page deserves to exist, is in the guide to programmatic SEO without the thin-content penalty.
How to prevent keyword cannibalization before it exists
Preventing keyword cannibalization means catching the collision at planning time, when it costs one line in a brief rather than a merge, a redirect and a recovery period. Two checks do most of the work: cluster the keyword list before assigning pages, and check every brief’s target query against what is already published.
Cluster by the results page, not by the words
Two keywords belong on one page when Google treats them as one intent, and the most reliable evidence of that is the results page itself. Search both keywords and compare the top ten organic results. When most of the same URLs appear for both, they are one page. When the results are largely different, they are two. The working rule I use is four or more shared URLs in the top ten meaning one page. The exact number matters less than applying the same rule every time.
Word overlap is the faster first pass, and it catches the plural and word-order pairs. The Topical Map Generator clusters an exported keyword list on token overlap and flags pairs that share an intent and most of their words, which is the planning-time version of this check. Results-page comparison then settles the synonym pairs that word overlap cannot see.
Keep a keyword map with one row per intent
The output of clustering is a keyword map: one row per intent, one URL per row, and every variant that belongs to that page listed beside it. A new brief is checked against the map before it is written. If its query is already in a row, the work is an update to that row’s URL, not a new page.
| Primary query | Variants on the same page | Page type | URL | Owner |
|---|---|---|---|---|
| customer onboarding checklist | onboarding checklist, client onboarding checklist | Guide | /blog/customer-onboarding-checklist | Content lead |
| onboarding checklist template | onboarding checklist excel, onboarding template | Template | /blog/saas-onboarding-checklist-template | Content lead |
| churn rate | what is churn rate, churn rate definition, customer attrition rate | Guide | /blog/churn-rate | Content lead |
| churn analysis software | churn analytics tool | Product page | /product/churn-analysis | Product marketing |
A brief template that blocks the collision
Put these fields in the brief template and the check stops depending on someone remembering it:
The fifth field is where intent mistakes are caught. Classifying each target keyword’s intent before a page type is chosen, which the Intent Classifier does in bulk for a keyword list, stops a blog post being briefed for a query whose results page is all product pages.
In the wider plan, this sits inside a B2B SEO strategy built in sequence: cluster the keywords, assign pages, write the link rules into the brief, then publish. Done in that order, most cannibalisation never exists.
How to measure whether a keyword cannibalization fix worked
Measuring a cannibalisation fix means comparing the surviving page against the combined baseline of both pages, for the contested query and for everything the weaker page used to earn. Looking only at the contested query hides the most common failure, which is losing long tail.
| Fix | Primary measure | Watch for |
|---|---|---|
| Differentiate | One URL leads the contested query in most weeks | Either page losing clicks on its own non-overlapping queries |
| Demote | The preferred URL takes the contested query’s impressions | The demoted page losing traffic it needs for users |
| Consolidate | Merged page clicks against both pages’ combined baseline | Long-tail queries from the old page that no longer appear |
| Do nothing | Both pages keep their clicks next quarter | The ranking URL starting to change hands |
Use the same windows each time. Compare the four weeks after the change with the four weeks before, then twelve weeks against the same twelve before, and against the same period last year if the topic is seasonal. Annotate the change date in whatever reporting you use, so a later dip is not mistaken for the fix failing.
Success, for the consolidation case in the worked example, would look like the merged page’s clicks for the contested query exceeding the combined clicks both pages earned before, with the moved sections still collecting the long-tail queries that came across. If the long tail does not reappear on the merged page, the section that earned it was either cut or buried, and it is the first thing to check.
A keyword cannibalization plan for week 1, month 1 and quarter 1
A cannibalisation programme for a small or mid-sized site fits into one quarter: a week to find and decide, a month to fix the worst cases, and a quarter to change the process so the list does not regrow.
- Week 1. Export query and page data for the last three months. List every query with two or more URLs above the impression threshold. For the top twenty by impressions, run the full Search Console procedure, compute the weaker page’s share, and write a decision against each.
- Month 1. Ship the differentiations and demotions first, because they are reversible and cheap. Then the consolidations, one at a time, each with its content moved, links updated and redirect in place, and each with review dates set.
- Quarter 1. Add the brief fields above to the template. Cluster the next quarter’s keyword list before any page is assigned. Review the four-week and twelve-week results of every fix, and rerun the export to confirm no new pairs have appeared.
Finding the pairs worth acting on is part of a wider content audit, where cannibalisation is one of the reasons a page ends up in the merge column. Treat the two as the same exercise rather than running a separate cannibalisation project.
Before you demote or consolidate a pair, check which page your own site is backing. The Internal Link Mapper separates editorial links from navigation links, and a page with forty inbound links, all from the footer, is not the page your content is voting for. It does not replace Search Console; it narrows where you look.
Keyword cannibalization is a planning failure that shows up in search results months later. Diagnose it from Search Console, one query at a time, by looking for an unstable ranking URL or two URLs stuck on page two, not from titles that look alike. Check what the weaker page earns before touching it, prefer differentiating to merging, and when you do merge, move the content first, then the internal links, then the redirect. Then add the collision check to the brief template so the next collision is caught before it is written.
The rule I apply before touching any pair: check what the weaker page earns on its own, before deciding anything about the overlap. A page that ranks badly for its target and well for thirty things nobody planned is doing more work than the cannibalisation report suggests.
The order I use is differentiate, demote, consolidate. The first two can be undone in an afternoon. A consolidation, in practice, cannot, because the redirected page’s history does not come back if you change your mind.
Frequently asked
How do I know if I have keyword cannibalization?
Is keyword cannibalization bad for SEO?
How do I fix keyword cannibalization?
Should I use a canonical tag or a 301 redirect for keyword cannibalization?
Should I noindex a cannibalizing page?
Can two pages from the same site rank for the same keyword?
What is the difference between keyword cannibalization and duplicate content?
How long does it take to see results after fixing keyword cannibalization?
I take on a small number of engagements at a time. If you are past product-market fit and want to talk through what this would look like for your situation, the calendar is open.
Book a call