Keyword cannibalization in WordPress: find it with GSC, fix it with intent

To find keyword cannibalization in WordPress, filter your Google Search Console Performance report to one query and open the Pages tab — if two or more of your own URLs collect impressions for it, you have a candidate. The part most guides skip: a candidate is not a problem. Two of your pages showing up for one search only costs you traffic when they split clicks on the same intent while both underperform, and the real cases are fixed by intent — you merge same-intent pages and pull different-intent pages further apart.

Every fix inside Contexta — the WordPress plugin we make — runs off a site's own Search Console data, so this particular false alarm crosses our desk constantly: a tool flags "cannibalization," the owner merges two pages, and a page that was quietly ranking on its own vanishes. Detection is the easy half. The judgement — is this actually hurting me, and if so, merge or differentiate — is where sites lose traffic they didn't need to.

How do you find keyword cannibalization with Google Search Console?

There are two ways, one for a single keyword and one that scales to a whole site. For a quick check, open the Performance report, filter by a query you care about, then click the Pages tab: if more than one of your URLs shows impressions for that exact query, they are competing for it. That is the manual spot-check every guide describes, and it is fine when you already suspect a specific term.

The version that scales is an export-and-count pass. Pull the query-and-page report (or the BigQuery bulk export if your long tail runs past the 1,000-row in-dashboard cap), sort by query, and count the distinct pages attached to each one. Any query with two or more of your URLs is a candidate — but only flag it when both URLs clear a small impression floor (we use roughly 10 impressions each) and both sit inside the top 20, because a page ranking at position 60 for a query isn't stealing anything from the page at position 5. Of the three lists you can build from an export, this is the one truncation damages most — the page-and-query view hits the row cap first, so a CSV-based audit finds the obvious duplicates and quietly misses the tail.

Doing that pivot by hand every month is the part that quietly dies by the third cycle. Contexta's Problem Map imports your Search Console data and surfaces cannibalization cases automatically, ranked by estimated lost clicks per month alongside the CTR losers and page-2 pages, so the candidates worth judging are already at the top of the list instead of buried in a spreadsheet you rebuild by hand.

Is it really cannibalization, or a false alarm?

Most flagged candidates are harmless, so before you touch anything, run the harm test — two of your URLs ranking for one query only costs traffic when three things are true at once. First, both pages target the same search intent, not just the same word. Second, their positions are unstable — swapping week to week, or both stuck outside the top few — which is Google signalling it can't decide which page to trust. Third, their combined clicks are lower than the stronger page alone would plausibly earn if it owned the query.

If Google consistently ranks one of your pages well and the other trails far behind without moving, that is not cannibalization — that is Google correctly picking your best page, exactly what you want. Merging in that case throws away a page for no gain. The single most common mistake we see is treating the Pages tab's "two URLs" as a verdict when it's only a question.

When several candidates do pass the harm test, fix them in the order that recovers the most traffic, not the order they appear. Rank each by clicks at stake — impressions times the CTR gap — the same prioritisation that drives fixing high-impression, low-click pages, so a query leaking hundreds of clicks a month gets your morning before one leaking a dozen.

Merge or differentiate? Let the query intent decide

The entire fix reduces to one question: do the two competing URLs satisfy the same search intent? You answer it from Search Console itself, not from a gut read of the titles. Pull each URL's own top-query list — the Queries tab filtered to that page — and compare them. If the two pages share most of their high-impression queries, they're answering the same question and belong together. If each page owns a distinct cluster of queries the other doesn't rank for, they're doing different jobs and should stay separate.

This is why "cannibalization" is over-diagnosed. Two URLs can share a topic without sharing an intent: a "best running shoes for flat feet" guide and a "how to know if you have flat feet" explainer overlap on the word flat feet but answer entirely different searches. The word-match makes them look like rivals; the query lists prove they aren't. In the broader Search Console workflow — where cannibalization is one of three action lists you build from a single export — this intent check is the step that decides which fix a row gets.

How do you merge two cannibalizing pages?

Merging is a four-step move, and the order matters. Pick the winner first — the page with the better position, more backlinks, or the more complete content — and commit to it as the single surviving URL. Fold the useful, non-duplicate content from the weaker page into the winner so nothing worth ranking is lost. Then set a 301 redirect from the loser's URL to the winner, and update every internal link that pointed at the old page so it points at the survivor directly.

Use a 301, not a canonical tag, when you're genuinely retiring the weaker page. A canonical is a hint Google can ignore and it leaves both URLs live and crawlable; a 301 is a directive that consolidates the signals and removes the duplicate from the index for good. Keep the canonical route only when both pages must stay reachable for users — a printable version, or a product variant — where deleting one isn't an option. Two near-miss pages both stalled in positions 11–20 will often clear onto page one once their split authority is merged into one stronger page, which is the upside that makes the work worth it.

When should you differentiate instead of merge?

Differentiate whenever the two pages passed the intent check as different — merging them would delete a page that earns its own traffic. The move is to sharpen each page toward the query cluster it actually owns: rewrite the title and H1 to name that page's specific intent, reshape the body to answer that question directly, and cross-link the two pages with anchors that describe the distinct job each does. You're not fixing a duplicate; you're making the difference obvious to Google, which was hedging because the pages looked too alike.

Be honest about the cost — differentiating is slower and more hands-on than a redirect, and it doesn't pay off for a week or two while Google re-crawls and re-reads both pages. It's still the right call when both pages have real, separate demand. One caveat before you rewrite: a page under-clicking at position 1–3 might be losing the click to an AI Overview rather than to a rival URL of yours, a case worth ruling out in rank-1 pages that still lose clicks before you blame cannibalization at all.

How do you stop cannibalization from coming back?

Give every page one job and check before you publish the next one. The durable prevention is editorial, not technical: before assigning a target query to a new post, search Search Console for that query and see whether an existing page already ranks for it. If one does, the new content either extends that page or takes a deliberately different angle — never a second page chasing the same intent by accident, which is how most cannibalization is born in the first place.

Then keep internal links pointed at the page you've chosen to own each query, with anchor text that matches its intent. Consistent internal linking is the cheapest signal you can send about which page is the answer, and it's the one most sites leave to chance. Audit the export quarterly, run the harm test on any new candidates, and the problem stays small instead of compounding across a year of published posts.