Keyword cannibalization and when to merge, redirect or prune

Keyword cannibalization is a problem only when two or more of your URLs serve the same search intent and Google keeps swapping between them, or ranks them lower than one consolidated page would rank. If both pages need to exist, point a canonical from one to the other or rewrite them for different intents; if one does not need to exist, merge it into the other and 301 redirect it, and remove a page outright only when it has no value and no close relative to redirect to.

That same decision covers content pruning. Whether the trigger is two pages competing for one query or an archive full of thin, dated posts, the options are the same: improve, merge, redirect, keep out of the index, or delete. This guide works through how to confirm the problem first and then how to pick among them.

Telling healthy overlap from competition

Two pages that use the same words are not competing if they answer different questions. A product category for "standing desks" and a guide on how to choose a standing desk share vocabulary but serve someone ready to buy and someone still researching. Both should exist. A category and its subcategory overlap in wording by design, as long as each has a distinct scope. And two of your pages ranking together near the top means more of the results page is yours. Google's ranking systems guide describes a site diversity system under which "we generally won't show more than two web page listings from the same site in our top results," so two listings is close to the most a site can expect for one query.

The intent test is one question: would one excellent page fully satisfy someone searching either query? If yes, both queries belong on one URL. If someone searching one query would land on the other page and feel it was about something else, they deserve separate pages. A pricing question, a cost question and a "how much is it" question want the same page. A comparison against competitor A and a comparison against competitor B probably want two, because people choosing between different pairs need different evidence.

Read the results page before deciding what format a query needs. Search the query and look at what ranks. Product and category pages mean the searcher wants to buy, and a blog post will struggle however good it is. Listicles and comparisons mean people want options weighed. SERP features hint at format rather than depth: a video block suggests people want to see something done, not that they want a short answer. A low difficulty score is no opportunity if every ranking page is a type your site cannot build. The search intent section of 6 fundamental SEO principles shows how one word can carry several intents.

Google does not document "cannibalization" as a mechanism. What its documentation describes are canonicalization and deduplication systems that pick which of several similar pages to show. The pattern SEOs call cannibalization is observed in data: the ranking URL for a query alternates, two URLs sit lower together than one used to, or a thin page outranks the page you want to rank.

Confirming it in Search Console

Search Console shows which of your URLs Google surfaces for a query and how that changes over time. A working sequence:

1. In the Performance report, filter to the exact query.

2. Open the Pages tab and note every URL with impressions.

3. Set a range of three months or more, then filter to the query plus one URL at a time and compare the daily charts. Alternation looks like impressions handing off from one URL to the other and back.

4. Compare average position for each URL on that query. Two URLs hovering together on page two, for a query one strong page could win, fits the pattern.

5. Run both URLs through URL Inspection. If the Google-selected canonical for one of them is the other, Google already treats them as duplicates.

Two limits apply. Search Console leaves out anonymized queries, which Google's deep dive into Performance data defines as queries not "issued by more than a few dozen users over a two-to-three month period." Overlap on low-volume queries can therefore be invisible when you filter by query, so filter by page as well. And crawls of titles and H1s or site: searches only produce leads, pages built around the same head term, which still need checking against Search Console.

At scale, export query and page pairs through the Search Console API and flag queries where two or more URLs each take a meaningful share of impressions and the top URL changes from week to week. That list is the starting set for the decision below.

Choosing the fix

Work through the questions in order:

Do the pages serve the same intent?
|-- No  -> Differentiate titles, H1s and internal anchors. Keep both.
|-- Yes -> Do both rank well together?
           |-- Yes -> Leave them alone.
           |-- No  -> Do users need both URLs (print view, sorted or
                      filtered variant, campaign landing page)?
                      |-- Yes -> Keep both, rel=canonical from the
                      |          secondary to the primary.
                      |-- No  -> Does the weaker page have content,
                                 links or traffic to keep?
                                 |-- Yes -> Merge its best parts into
                                 |          the stronger URL, then 301.
                                 |-- No  -> Is there a closely related page?
                                            |-- Yes -> 301 to it.
                                            |-- No  -> 404 or 410.

The same logic applied to a whole archive gives a fuller set of outcomes:

Merging without losing what the old page earned

A merge has the most moving parts, and the choice of surviving URL decides how much is kept. Check, for each candidate:

• Referring domains. Redirects pass signals, so links alone need not decide it, but a large gap in link profiles favors the stronger URL.

• Which URL ranks for more of the query set, not only the head term.

• Conversions and assisted value.

• URL permanence. An evergreen slug beats one with a year or a campaign name in it.

• Content quality. Content can move between URLs more easily than links and history can.

Say a home improvement blog has two posts on charger costs: an older one at /blog/ev-charger-cost-2023 with a few more referring domains, and a newer one at /blog/how-much-does-a-home-ev-charger-cost with better content and an evergreen slug. Search Console shows impressions for "ev charger installation cost" and "home ev charger price" alternating between them. Both serve one intent, what it costs to buy and install a home charger, so this is a merge. The newer URL survives because of its slug and content. The older post's one unique section, a table of permit costs by region, moves into the survivor first. Then the old URL redirects in a single hop:

# nginx: retired URL straight to the survivor, one hop
location = /blog/ev-charger-cost-2023 {
    return 301 /blog/how-much-does-a-home-ev-charger-cost;
}
location = /blog/ev-charger-cost-2023/ {
    return 301 /blog/how-much-does-a-home-ev-charger-cost;
}

Because redirects pass signals, the older post's links keep counting through the redirect. Mapping redirects for many URLs at once follows the same rules as a move, which the site migration checklist covers.

After the merge, verify rather than assume:

• The old URL returns one 301 to the survivor, with no chain.

• Internal links point at the survivor directly, and the sitemap lists only the survivor.

• URL Inspection eventually shows the survivor as the Google-selected canonical.

• In the Performance report, impressions for the query consolidate onto one URL over the following weeks and the alternation stops.

• The redirect stays in place long term. The most valuable external links can be updated to the new URL, but the redirect already covers them.

Canonicals for duplicates that must stay

Some overlap is functional: a print view, a sorted or filtered listing, a campaign landing page that mirrors an organic one. Users need those URLs, so a redirect is wrong. A canonical on the secondary page tells Google which version to index:

<!-- on https://example.com/guides/standing-desks?sort=price -->
<link rel="canonical" href="https://example.com/guides/standing-desks">

Google's guide to consolidating duplicate URLs calls redirects and rel=canonical strong signals and sitemap inclusion a weak one, and says the signals stack when combined. They remain signals: when two pages differ substantially, or other signals point elsewhere, Google can pick a different canonical. The same guide advises against using noindex to choose a canonical within a site, since noindex removes the page from Search entirely. Canonicals are also a poor substitute for a merge between two editorial articles that say different things; if nobody needs the second page, merge it. The guide to how Google treats canonical tags covers how to check which URL Google chose.

Differentiating pages that should both live

When two pages drifted toward the same query, often because they were written years apart, the fix is to give each one a distinct job. Sharpen one toward the buying intent and the other toward research, then rewrite titles and H1s so each declares that job clearly. Titles that do not match the page's content are also one of the reasons Google rewrites them in results, as the post on why Google rewrites title tags explains.

Internal links then reinforce the split. Anchor text tells search engines which page owns which query, so anchors for the head term should all point at the page meant to rank for it, while the other page gets its own consistent vocabulary. A hypothetical before and after for a desk retailer:

The broader rules for anchors and link architecture are in the guide to internal linking at scale.

Pruning, and Google's view of deleting pages

Google's guidance treats deletion as the exception. Its page on core updates says "Deleting content is a last resort, and only to be considered if you think the content can't be salvaged." Its helpful content guidance asks whether you are removing a lot of older content mainly to make the site seem fresh, and answers "(No, it won't)". The case for pruning is quality and focus: fewer pages that each have a reason to be indexed, with internal links concentrated on them. Crawl efficiency is a reason only on very large or fast-changing sites.

Rules that keep a pruning pass safe:

• Never judge a page on traffic alone. Support pages, pages people reach mid-purchase and pages linked from emails or sales material can matter with few organic clicks.

• Check backlinks before removing anything. A forgotten post with strong links gets improved, merged or redirected to its closest relative.

• Redirect only to a page that serves the same need. Sending a specific article's visitors to the homepage does not give them what they came for. When nothing close exists, let the URL return 404 or 410. Google's documentation on HTTP status codes says indexed URLs that return a 4xx status "are removed from the index" and that all 4xx errors except 429 are treated the same, so either code works for Google.

• Use noindex for pages people need but searchers do not, such as thin tag archives. A page blocked in robots.txt cannot show its noindex to Google, a distinction the post on what robots.txt controls covers.

• Update internal links and sitemaps that pointed at removed or redirected URLs.

• Work in batches. Prune a set, watch Search Console for a few weeks, then continue.

Preventing it with a keyword-to-URL map

Cannibalization tends to start as a planning gap that surfaces months later: a new page commissioned without checking what already covers the query. A shared map with one owning URL per intent cluster catches that before anything is written. A hypothetical version for the same desk retailer:

Check the map before anyone writes a new page. If the cluster already has an owner, improve the owner instead of adding a competitor. To start, take the five queries where Search Console shows more than one of your URLs with impressions and run each through the decision flow above.