Why two of your pages compete for the same search

Keyword cannibalisation is what happens when two or more pages on the same site are built to answer the same search. Not similar searches — the same one. A clinic with a page called 'Dental implants in Pune' and another called 'Implant treatment, Pune' has two pages competing for one job, and the site now presents a search engine with a choice it did not need to make.

The damage is subtler than the word suggests. Nothing eats anything. What happens is that the signals that would have accumulated on one strong page are split across two weaker ones: the internal links point to both, the external links that arrive land on whichever one someone happened to find, and the engine picks one to show for the query with no particular reason to prefer the one you would have chosen. Sometimes it alternates between them over time. The site has not been penalised, and there is no manual action to appeal; it has simply divided its own effort and made its own best page harder to identify.

Almost never by decision. The common route is time: a page written three years ago about a service, then a newer, better page written about the same service by someone who did not know the old one existed, because it was no longer linked from the navigation. Another route is the blog post that grew into a de facto service page — an article about how a treatment works that gradually acquired pricing and a booking link until it was doing the same job as the service page.

E-commerce produces its own version. A category page for a product type and a filtered view of the same category, both indexable, both titled almost identically. Regional expansion produces another: a city page for Pune and a city page for Pimpri that describe the same service in the same words with the place name swapped, which leaves them competing for each other's queries and for the unqualified one. In each case, nobody set out to build a duplicate. The duplicate is a byproduct of the site being edited by more than one person over more than one year.

The cheapest diagnostic needs nothing but a list of your own pages and their title tags, which you can read out of the pages themselves. Put the titles in a single column, sort them alphabetically, and read down. Near-duplicates surface immediately, because two pages built for the same query almost always have titles that differ by a preposition or a synonym. This is a mechanical scan and it finds most real cases in a small site's worth of pages.

Extend it by grouping by intended query rather than by wording. For each page, write down the one search you would want it to answer, in the words a customer would type. Two pages with the same sentence in that column are the finding, whatever their titles say. This second pass catches the case the sort misses: a page called 'Our approach to implants' and one called 'Dental implants in Pune' look nothing alike alphabetically and are aimed at exactly the same person. Doing this by hand is slow and it is also the part no tool can do for you, because only you know what each page was for.

Most published advice on cannibalisation starts somewhere you may not be able to start: look at which queries each page ranks for, find the ones where both appear, watch for positions swapping between them over time. That is a good method and it needs position data over time, which no page's markup contains and no search engine publishes for free to anyone who asks.

There is a free route to part of it. Search Console reports queries with the pages that received impressions for them, for a property whose owner has verified it and connected access. Filter to one query and see two of your own URLs listed, and you have direct evidence rather than an inference from titles. What it will not give you is a full picture of every affected query, because the report samples and because it only covers queries where you already appeared. The honest summary is that the title-and-intent scan is available to everyone and finds the obvious cases; the query-level confirmation is free but gated on the owner connecting it; and the comprehensive competitive view is a paid product. Knowing which of those you are working from matters, because it determines how confident the fix should be.

Consolidate. Pick the page that should win, move anything worth keeping from the other into it, and redirect the loser to the winner permanently. This is the right answer most of the time and it is the one people avoid, because it means deleting work. The cost is real: any external link pointing at the redirected URL now passes through a redirect, internal links need updating, and if you chose the wrong survivor you have made the weaker page the permanent one. Choose the survivor on merit — usually the page that is better written and better linked — not on which is newer.

Differentiate. Keep both, and change them until they genuinely answer different questions. The blog post explains how the treatment works and who it suits; the service page covers cost, duration and booking. This is right when both pages have a real audience, and it fails when 'differentiate' turns into rewriting two titles while the bodies stay interchangeable. The test is whether you can state, in one sentence each, a different question they answer.

Canonicalise. Leave both pages in place for visitors and tell the engine which one to index, using a canonical link on the duplicate pointing at the preferred page. This suits the e-commerce filtered-view case, where the variant genuinely needs to exist for users. Its cost is that it is a hint rather than an instruction, and a canonical pointing at a page that is not really equivalent is a signal you will not be able to debug easily later.

The decision is usually settled by asking whether both pages need to exist for a human being. If a visitor would be confused to land on either — if they are two attempts at one page — consolidate. If a visitor would reasonably want both, differentiate. If a visitor needs the variant but a search engine does not, canonicalise. Reaching for canonical tags first is the common error, because it feels less destructive than deleting a page while leaving the underlying duplication in place.

Afterwards, be realistic about verification. You can confirm from the pages themselves that the redirect resolves, that the canonical points where you intended, and that the titles now differ. You cannot confirm from your own markup that the consolidation improved anything, because that would need position data over time from a source outside your site. If Search Console is connected, the useful check is whether one URL now appears for the query where two used to. Without it, you have made a change that is defensible on structural grounds and whose effect on results you will not directly observe — which is an acceptable place to be, as long as nobody later reports it as a measured gain.