Keyword cannibalization: how to find, fix and prevent it

What keyword cannibalization is, and when two rankings are fine

Keyword cannibalization is when two or more of your pages compete for the same search and the same need. Neither ranks as well as one clear page would. Two pages ranking for one search is not a problem by itself. The need behind the search decides.

The precise version of the idea comes from Koray Tuğberk Gübür. In 2021 he called it ranking signal dilution: "the error that two web pages compete with each other for the same canonical query". His canonical query is the one wording that best sums up all the variants of a need. So the test is about the need, not the exact words. In 2026 he named the small version, where one paragraph on a page overlaps another page, micro-cannibalization.

Google sees it the same way. In September 2025, John Mueller of Google answered a question about pages that rank for the same searches. Search Engine Journal reported his words: "pages aren't duplicates just because they happen to appear in the same search results page". And: "Reduce unnecessary duplication and spend your energy on a fantastic page, sure."

The three-condition test

Put those two views together and you get a test. A pair is cannibalization only when all three conditions are true: the same search, the same need, and both pages weaker for it.

Cannibalization is also not the same as duplicate content. Two pages can share a need with completely different text, and two near-copies can serve different needs. Whether a search deserves its own page in the first place is a decision with its own lesson: when a search deserves its own page.

Why your second page competes with your first

Search engines show few results per site for one search and drop near-duplicates. So two of your pages for one need fight for the same one or two places. They also split the links and clicks one page would have had.

What Google has said about results from one site

Google names two systems in its guide to its ranking systems. The site diversity system "generally won't show more than two web page listings" from the same site in the top results. Its deduplication systems show only the most relevant of results that are very similar.

The idea is old. A Google patent application filed in 2010 describes the trade-off between "result quality", more results from one relevant site, and "result diversity", results from many sites. It notes that engines limit the results shown from one host. A patent shows what Google designed, not what runs today.

Research had the same idea first. In 1998, Jaime Carbonell and Jade Goldstein at Carnegie Mellon described maximal marginal relevance, which scores each next result by how much it adds over the results already picked. Charles Clarke and colleagues at Waterloo built the same rule into a measure in 2008. A result list scores lower when it repeats what is already there (novelty and diversity in retrieval evaluation). Your second page on the same need is, to such a system, a repeat.

Engines also spot near-copies cheaply. Google's near-duplicate detection patent, filed in 2001, gives each document fingerprints and treats two pages as near duplicates when a fingerprint matches.

What Bing says, for search and for AI answers

Bing's Webmaster Guidelines are blunter, and they now cover Copilot answers too. Section 6 says: "Duplicate URLs dilute signals and reduce Bing's confidence in selecting a URL for grounding results or citations." Section 17 adds that "URLs focused on a primary topic are more likely to be selected for grounding results". Grounding is the step where an AI answer picks the pages it quotes.

Fewer, clearer pages are also cheaper for an engine to crawl, store and choose between. Koray wrote in 2024: "Decrease the total page number to prevent ranking signal dilution". The full idea is in cost of retrieval.

How to find keyword cannibalization in Search Console, step by step

Open the Performance report, pick a search in the Queries tab, then open the Pages tab. Two or more of your pages with impressions for that one search is a suspect pair. It takes three clicks and costs nothing.

1. Open Performance, then Search results. Set the date range to the last 3 months, so one odd week does not decide.
2. Open the Queries tab and sort by impressions. Start with the 50 searches that matter most to you, not the long tail.
3. Click one search. It becomes a filter on the whole report.
4. Open the Pages tab. Each row is a page Google showed for that search. One row is fine. Two or more rows is a suspect pair.
5. Write down each page's impressions, clicks and position in the worksheet at the end of this lesson.
6. Compare two date ranges. Use the date filter's Compare option, for example the last 28 days against the 28 before. If the page with the most impressions changes between the two, Google is swapping owners.
7. Repeat for the next search, then run every suspect pair through the three-condition test.

Why the Pages tab tells the truth

Search Console counts impressions two ways, and this is the detail most guides skip. The Performance report help says the chart is aggregated by property: "if two results from the same site appear for one query, they count as a single impression". The table grouped by Pages is aggregated by page. So when you filter by a search and open the Pages tab, each of your pages that showed gets its own count.

It also only shows real events. Mueller, in the same 2025 answer: "Search Console shows data for when pages were actually shown, it's not a theoretical measurement." A page that never appeared for the search will not be in the list.

Three limits to know before you trust the numbers

• Rare searches disappear under a filter. Google's Daniel Waisberg explained in a 2022 post on Search Console limits that anonymized queries "aren't issued by more than a few dozen users over a two-to-three month period". They never show as rows, so very small overlaps stay hidden.
• The screen stops at 1,000 rows. Per the same post, "The maximum you can export through the Search Console user interface is 1,000 rows of data."
• For a whole site, pull search and page together. The Search Console API returns up to 25,000 rows a request, with a ceiling of 50,000 rows per day per site per search type. Pull the search and page dimensions together, then count how many pages each search has in a spreadsheet. The same export also shows the searches no page answers well, which is where a content gap check starts.

How to check a suspect pair with a site search and the top 10

Search site:yourdomain.com plus the words to see which of your pages Google holds for them. Then search both wordings and compare the two top 10s. Shared results and the same kind of page mean one need.

The site search

Type site:yourdomain.com burr grinder into Google. Every result is one of your pages that Google has indexed and connects to those words. It is a fast way to find old posts you forgot about. It is not complete: Google's own page on the operator says it "doesn't necessarily return all the URLs that are indexed". Use it to add suspects, never to clear one.

The top 10 overlap check

Search both wordings in a private window and lay the two result lists side by side. Count the results that appear in both, and note what kind of page wins each. This is how engines group searches too. Doug Beeferman of Lycos and Adam Berger of Carnegie Mellon clustered queries by the pages people clicked in 2000, and researchers at Microsoft Research Asia did the same in 2002. A 2013 Google patent groups query refinements by the documents people click for them.

I ran this check for this lesson on 13 November 2026, on searches from two real maps we delivered: a US store selling graphic tees and a US water damage company. Top 10 organic results, US, desktop.

The store pairs are clean. Not one shared result, and different kinds of pages win. Those are two needs, so a collection and a guide can both live without competing.

The water searches show where the check breaks. On a local search the URL count lies, because Google shows a different company for each city, so almost nothing is shared. Read the titles instead. Most results for repair and cleanup are restoration pages, so Google treats them as one service. Unless a business really sells repair or cleanup as a separate job, I would give those words to the restoration page as sections. Mitigation has its own results, and the comparison search wants a comparison page.

Which fix to use: merge, redirect, re-aim or leave

Same need and both pages have value: merge into the stronger one and redirect the other. Same need and one adds nothing: redirect it. Different needs: re-aim one page, or leave both. Canonical tags and noindex are for pages that must stay for people.

Which page becomes the owner

Keep the URL with the most links in from other sites, then the one that ranks better, then the one with more clicks over 3 months. Then check its type: if Google shows collections for the search, the owner should be your collection, not a blog post.

How strong each signal is

Google's page on consolidating duplicate URLs ranks the options. A redirect is "a strong signal" that its target should become canonical, and so is rel=canonical. A sitemap entry is "a weak signal". And "these methods can stack", so a redirect plus updated internal links beats either alone. Bing's guidelines add that canonical tags "do not replace fixing underlying issues".

Before you remove anything, check the order. Our first move with a page that overlaps is to see whether it can be merged into a page that is more relevant. If it cannot, my rule decides: if a page does not have a purpose, it does not deserve to be on the website.

Merging has a known way to go wrong. In a 2025 SearchPilot test, pages that looked like duplicates served different needs, and enriching them beat removing them by nearly 20%. That is the three-condition test again: check the need before you delete. The step-by-step of merging, redirecting and updating is in pruning, merging and updating.

Store cases: collection, product and guide

In an online store the collection page owns the category search, the product page owns the model search, and the guide owns the question. Most store cannibalization is one of these pages doing another's job.

Both rows in that picture come from the map we delivered to the graphic tee store. The collection "Oversized graphic tees" owns "oversized graphic tee", 22,200 US searches a month. The guide "How to style an oversized T-shirt" owns "how to style an oversized t shirt", 720 a month, and links to the collection. The overlap check above confirmed they are two needs. Here are the six store cases I see most, with the owner for each.

The variant rule is Google's own. Its guide to ecommerce URLs asks you to "include the canonical product URL on all variant pages" and to keep the number of alternative URLs that return the same content low. Many store platforms also show one product under several collection paths. Check that every path carries a canonical tag that points at the one product URL.

Store maps have more traps than these, from brand pages to gift guides. They are in topical maps for ecommerce stores.

How a topical map gives every search one owner page

A topical map names one owner page for every search before any page exists. It also lists the variants each page covers. So a second page for the same need is caught at the plan stage, not in Search Console a year later.

Libraries solved this first

Librarians had this problem long before search engines. A thesaurus for information retrieval picks one preferred term for each concept and records every variant pointing at it. In Stella Dextre Clarke's words for ISKO, "the tags USE and UF (Use For) precede preferred and non-preferred terms respectively". The US standard for this, ANSI/NISO Z39.19, exists so that a reader looking up any variant lands on one entry.

A topical map row does the same job for pages. Its main search is the preferred term. Its "also covers" column is the UF list. A variant listed on one row can never be planned as a second page.

Google's internal documentation, leaked in 2024, points the same way: it stores the entities in each document sorted by a topicality score. A page has a first subject. A map makes sure no two pages share it.

How the map decides what gets a row

Not every search earns a row. Koray's Query Deserves a Page test, published in 2026, asks four things: high demand, different entities, low similarity to existing searches, and a pattern. A search that fails becomes a section, a table or a line on an existing page. The full test and ten real pairs are in when a search deserves its own page, and the rest of his framework is in Koray Tuğberk Gübür's topical map framework.

This is also why a keyword list breeds cannibalization: it has no owner column, so nothing stops two writers picking the same need. The difference is laid out in topical map vs topic cluster vs keyword list.

The mistakes we check for in maps people build themselves

Two pages for one need is one of the first things we check when a buyer shows us a map they built themselves. Three mistakes come up over and over. The pages do not build on each other. There are a lot of off-topic things that do not deserve to be there when they could have been part of another post. And a query does not deserve its own page: many searches are a section of a page, not a page. From there, these are the specific pairs we look for.

• Two rows with the same main search, often under different clusters.
• Two rows that differ by one word (cheap and affordable, for men and men's) with the same top 10.
• A guide row aimed at a collection search, so the blog fights the shop.
• Location or service rows that swap only the city or one word, with no facts of their own.
• A yearly row (best X 2026) planned next to an evergreen row for the same list.

Owner pages also need links in the right direction: every supporting page links to the owner with the owner's own name. That pattern is in internal links inside a topical map, and the whole build is in how to build a topical map. Or have it built: one main search per row is how our growth plan is laid out.

How to check that the fix worked

Record 28 days of clicks for the search before you change anything. Make one change. Then compare the same 28 days four and eight weeks later, against a few pairs you left alone.

Since nobody has published a controlled test, your own sites are the test. Most case stories in this space are one site, one change and no control, so a seasonal rise looks like a win. Here is a fairer way to run it.

1. Measure the search, not the page. Filter Search Console by the search and note its clicks for the last 28 days across all your pages. After a merge, the owner page should carry what both pages had.
2. Pick control pairs. Choose two or three other suspect pairs that you leave alone for now, and note their clicks too.
3. Change one thing and write down the date. A merge, a redirect or a re-aim, never three changes in one week.
4. Compare at week 4 and week 8. Use the same length of window, starting on the same day of the week. Redirects need time to settle.
5. Judge against the controls. If your fixed pair rose and the controls rose as much, the season did it, not the fix.

Record it all in the worksheet below. What a working map looks like over the months after publishing is in how to tell if a topical map is working.

The cannibalization worksheet: one row per suspect pair

The worksheet holds one row per suspect pair, from the Search Console numbers to the decision and the before and after. It opens in Google Sheets, Excel or Numbers.

Download the cannibalization worksheetCSV, 24 columns, with one made-up example row to delete

Common questions