You pull up Search Console for a query you care about and two of your own URLs are sitting there, both picking up impressions, both a little unsure which one is supposed to win. That's the symptom this piece is for: pages competing for same keyword rankings on your own site, and you're not sure yet whether that's a problem or just noise. By the end you'll be able to tell which of four things is actually going on, confirm it with a real check instead of a guess, and pick between consolidating, differentiating, or redirecting. You'll also know how to tell, a few weeks later, whether the fix actually worked.
Before any of that: two URLs showing up for one query is a reason to look, not a reason to act. Keyword cannibalization is a harmful overlap, not just an overlap, and the two aren't the same thing. A broad query can genuinely surface two different useful pages. Reports that cover weeks or months can mix duplicate ranking pages that only overlapped briefly. So the first job isn't picking a cannibalization fix. It's collecting the right evidence.
What to check before you decide anything
This is a narrower check than a full organic traffic drop investigation, but it borrows the same habit: look before you touch anything. Open Google Search Console and go to Performance, then Search results. Set search type to Web, pick a date range you can defend, and pull in clicks, impressions, CTR, and average position. The default view covers the last three months, and that's worth changing deliberately rather than leaving on autopilot.
Click into the query you're worried about, or add a query filter for the exact term. If you want a family of related terms, use "queries containing," but know that's a different check than an exact match. With the filter applied, switch to the Pages tab and look at which URLs are credited, how many clicks and impressions each one gets, and whether the leading URL changes if you compare one period against another. If you run this for a client, do it per priority query rather than pulling one site-wide export and skimming it.
Keep your comparisons apples to apples. Search Console lets you compare date ranges and filter by country and device, and it's worth using weekly or monthly windows rather than daily ones, since day-of-week swings can make a stable query look volatile. A quick look at the live search results for the query is a useful sanity check too, though remember what you see depends on your location, device, and search history, so it won't match every searcher's results exactly.
This isn't the same check as a branded vs non-branded traffic split, which answers a different question about who's typing your name into the search box. Then open both pages side by side. Who is each one for, what job is it doing, and is the format actually different: an explainer next to a template, or a general guide next to a page for one region or audience. Note anything one page ranks for that the other doesn't. Write down, in one line each, the query or intent cluster, the URLs involved, whether the overlap looks like duplication or a genuine difference, which page you'd keep, the action you're leaning toward, and the baseline numbers you're comparing against. That line is what makes the call defensible later, to a client or to your own team, instead of "the tool flagged it." It's the same discipline behind a proper content audit, just narrowed to one query.
A couple of things trip people up here. Search Console's site-level average position reflects your topmost ranking result for that query, not an average across every URL you have ranking. And a lot of performance gets credited to whichever URL Google picked as the canonical, not necessarily the one a visitor actually lands on. That's on top of how many queries are hidden from you entirely once Search Console anonymizes the low-volume ones. So a query filter that shows only one URL doesn't prove there's no overlap, and two URLs both appearing over a long date range doesn't prove they were ever on the same results page on the same day. Treat average position as a signal, not a literal rank for two separate pages.
Rank-tracking tools can help you find duplicate ranking pages faster. Ahrefs lets you check which keywords in Site Explorer have more than one of your URLs ranking. Semrush's cannibalization view flags a keyword as "affected" once more than one of your pages ranks anywhere in the top 100, and it calls the URLs sharing that keyword "cannibal pages." Both are useful for surfacing candidates. Neither one is telling you the overlap is actually hurting you: that's still your job, using the pages-and-queries check above.
The overlap is two live articles answering the same question
What it looks like. Similar titles, similar outlines, and if you read both start to finish, they'd satisfy the same reader in the same way. Sometimes one is thinner or a year or two out of date, but nothing structurally separates them.
How to confirm it. Filter Search Console on the shared query and check Pages, then repeat for a few related terms. Does either page bring in demand the other doesn't touch, or drive a conversion the other doesn't? Recheck after matching country, device, and time period, in case what looked like switching was really a seasonal or regional pattern.
The fix. Pick a winner based on which page is more complete, more accurate, and already performing better, not which one is newer. Pull anything genuinely useful from the loser into the winner. If the losing page has no independent reason to exist, redirect it permanently, straight to the winner. If neither page is actually good enough to be the destination, fix the survivor first, then redirect. This is a content call followed by a URL call, not a title rewrite you hope solves it.
An old article and its replacement are both still live
What it looks like. You published a newer, more complete guide, but the original is still sitting there, maybe still pulling in a few backlinks or a trickle of direct traffic. It might just be one of the decaying pages nobody's gotten around to revisiting.
How to confirm it. Compare what each page actually covers and which queries each one pulls in. Is there anything in the old piece the new one is missing? Does the old page serve a real archival purpose, like documenting a past version of a product or a policy that's since changed, or is it just an earlier draft of the same idea?
The fix. If the old page has no ongoing job, carry over anything worth keeping and redirect it permanently to the current version. If it genuinely needs to stay up on its own, for example because it's referenced as a historical record, leave it and don't force a merge just to tidy things up. Don't redirect an unrelated old post just because it feels good to clean house.
Two pages are answering different questions inside one broad term
What it looks like. A definition page next to a template, or a general guide next to a page written for one region or one type of customer. Both show up for the broad term, but each one is really answering a narrower question underneath it.
How to confirm it. Read both pages and look at their other queries in Search Console, not just the shared one. Would a real reader pick one page over the other depending on what they actually needed? Check the search results for the broad term and for the narrower variants, and see whether Google itself is already treating them as different answers.
The fix. In most of these cases, keep both. What needs fixing is clarity: make sure the title, the opening, and the examples on each page unmistakably signal its separate purpose, so neither page is quietly promising the other's answer. Don't merge two pages just to get down to one URL per keyword. That instinct can cost you long-tail coverage or a conversion path you'd otherwise keep. Check back on these periodically to make sure the separation is still holding.
The pages are technically different URLs but the same content
What it looks like. Parameter variants, a staging copy that never got cleaned up, or a site that's sending mixed signals about which version of a page is the real one. This is a canonicalization issue, and it can exist right alongside a genuine content overlap without being the same problem.
How to confirm it. Check each URL's indexing status and which one Google has picked as canonical, then compare the rendered content and any redirect behavior already in place. Confirm your canonical tags and your sitemap are pointing at the same preferred URL, since Search Console often credits performance to the canonical, not the specific duplicate a visitor hit, so the Pages report alone won't show you the full technical picture.
The fix. If the alternate URL shouldn't exist for users either, redirect it permanently to the version you want to keep. If both need to stay reachable and the content really is duplicate or close to it, add a rel="canonical" tag pointing at your preferred URL, and give that preferred page a self-referencing canonical too, so the signal is consistent everywhere. Google treats canonical tags as strong signals and sitemap inclusion as a weaker one, and it still makes the final call on which URL to show. Don't reach for robots.txt blocking, the removal tool, or noindex as a shortcut here. Google is explicit that those aren't the right tools for picking a canonical, and a canonical tag is never the fix for two pages that are genuinely different: that's a content decision, not a technical one.
None of these match
Sometimes you work through all four and nothing quite fits. Before you touch anything, go back and narrow the query down to one clear intent, match country and device across your comparison, and look at a shorter, more recent window instead of the full three months. Check whether Search Console is crediting everything to a canonical URL you hadn't accounted for. If the pages genuinely serve different purposes and the numbers were just noisy, write down "no consolidation needed" and move on, but keep an eye on it. That call, whether to refresh, rewrite, prune, or redirect, is worth revisiting the next time you run this check. If you're still not sure, the safer move is to leave both pages alone and gather another period of data rather than make a change you can't easily undo on the strength of one keyword or one snapshot. For a client, this is worth saying out loud: what you saw, why it's inconclusive, and what evidence would change your mind.
Choosing the cannibalization fix
Whether you consolidate, redirect, or delete a page deserves a written rule, not a fresh judgment call every time someone flags a shared keyword.
| What you found | What to do | What to watch for |
|---|---|---|
| Two distinct, useful pages sharing a broad query | Keep both, sharpen the differentiation | Protect each page's own search demand and purpose |
| Two pages that are genuinely redundant | Consolidate into one | Carry over anything worth keeping before you retire a URL |
| A page is being retired and a clear destination exists | Permanent redirect | Send it straight to the destination, no chains |
| Same content on two reachable URLs | Consistent canonical signals | Canonicalizing isn't a fix for two genuinely different pages |
| Not enough evidence yet | Watch and gather more data | A shared keyword alone isn't proof of harm |
When you do redirect, point the old URL straight at its replacement with a permanent, server-side redirect, and avoid chaining multiple redirects together. Plan to keep that redirect in place for a while, generally at least a year, so the destination has time to pick up the value of the old URL. Make sure your redirect, your canonical tags, and your sitemap are all pointing at the same preferred page. A mixed signal here undoes the fix.
Two shortcuts are worth naming so you don't reach for them under deadline pressure. Noindexing a page that still has its own real search demand doesn't consolidate anything, it just takes a working page out of the running. And swapping out a keyword here and there on one of the two pages won't separate them if their actual substance is answering the same question. On the other side, canonicalizing two pages that are genuinely different can quietly erase the separate value you were trying to protect in the first place.
Confirming the fix worked
Write down your baseline before you touch anything: the query or intent cluster, both URLs, a date range you'll compare against later, clicks, impressions, and average position for each page, any other queries either page pulls in, and the outcome you actually care about, whether that's clicks, leads, or something else. There's no fixed number of clicks or a set percentage that proves cannibalization was real, so don't wait for one.
Once the change is live, check the mechanics before you check the results. Does the retired URL land on the intended page without bouncing through another redirect first? Does that destination actually work and answer the query? If you kept a duplicate and used a canonical tag instead of a redirect, is the tag pointing where you expect, and does Google's own indexing report agree with you, rather than just trusting your own tag.
If the overlap traces back to a recent migration, the same before-and-after discipline you'd use to recover organic traffic after a migration applies here too. Then wait for enough new data to accumulate and repeat the same query filter and Pages check you ran at the start, using the same search type, country, and device settings so you're comparing like with like. Account for anything else that changed at the same time, like a seasonal swing or an unrelated site update. Look at the surviving page's full query set and the site's combined performance for that topic, not just whether the old URL disappeared from the report. A successful redirect usually shows the relevant traffic shifting toward the destination over time. Two pages you deliberately kept separate might keep showing up for the broad term together, and that's fine, since that was the point.
Report the outcome in proportion to what you actually saw. A clearer picture of which URL owns the query, or a real lift in clicks or conversions, says more than "the second URL is gone." Stable performance after a consolidation can still be a good outcome. And if a short window looks great, hold off on crediting the fix alone until you've seen it hold. If the page you expected to win still isn't the one showing up, or the whole query cluster is sliding, go back and check the content fit, the redirect or canonical setup, and whether you lost some genuine demand you didn't account for.
If you're doing this across a client roster
The mechanics above hold for one page or fifty. What changes across a roster is the discipline: the same decision record, the same baseline-then-recheck rhythm, applied consistently client to client instead of improvised fresh each time a client flags pages competing for same keyword. Keeping that record also gives you something concrete to show a client when they ask why a page got merged or redirected, instead of asking them to trust a tool's flag on your word.
