How do you detect keyword cannibalization from a Search Console export?

Keyword cannibalization can be spotted in a Search Console export as a query where two or more of your pages each hold a share of the impressions. To find it, build a table of queries and pages, then list queries where a second page passes a threshold. The list shows where impressions went, not whether pages compete.

• Google's Search Console help points to the Pages tab for seeing which URLs were shown for a specific query (Google, Search Console Help, read 30 October 2026).
• When data is aggregated by page, Google counts each unique URL in a result separately (Google, Search Console Help, read 30 October 2026).
• Google's site diversity system generally won't show more than two web page listings from the same site in its top results, though it may show more when its systems judge that especially relevant to a particular search (Google, Search Central documentation, read 30 October 2026).
• The Search Console API accepts a rowLimit from 1 to 25,000, defaults to 1,000, and returns top rows rather than every row (Google, Search Console API reference, read 30 October 2026).
• Penlid's check lists a query when at least two of its pages each hold at least 10% of the query's page impressions and at least 100 impressions (Penlid, keyword cannibalization check, read 30 October 2026).

Does Search Console show keyword cannibalization?

Search Console's Performance report has no keyword cannibalization view: the phrase is an SEO term, and none of the Google pages we read defines it. For one query, Google's help says View the Pages tab to see which URLs were shown. Penlid's tool page says Search Console’s own report cannot show one table of queries and pages; no Google page we read says this, so treat it as Penlid's statement.

Detecting cannibalization from an export therefore means building that missing table yourself, with one row for each query and page and, to see which page led, one row for each day. The free keyword cannibalization check reads such a table in your browser.

How do you get a table of queries and pages?

You get a table of queries and pages from the Search Console API, from the BigQuery bulk export, from a Data Studio (formerly Looker Studio) report or from a third-party Sheets add-on, and each route limits the rows differently.

A table built through the API holds top rows, not every row: Google's reference says the API does not guarantee to return all data rows but rather top ones, and its guide warns that asking for more detail means our system may drop some data. In BigQuery, add up rows with the same query and URL first (our advice, since Google's table reference mentions rows with repeated keys), and compute average position as SUM(sum_position) / SUM(impressions) + 1, because sum_position is zero-based. For why the Performance report's table stops at 1,000 rows, and where more rows come from, see the guide to getting more than 1,000 rows out of a Search Console export.

The check reads up to 200,000 rows or 12 MB of table text, so use a shorter range or one section of the site if it refuses a file.

When does the check list a query as split across pages?

The check lists a query when at least two of its pages each hold at least 10% of the query's page impressions and at least 100 impressions, thresholds that Penlid chose and calls judgment calls. A page's share is its impressions divided by the total for all of the query's pages in the table, and pages under the thresholds are counted but not named. The two tests do different jobs (our reading of the rules; the tool page gives no reasons for them): the share test ignores a page that sits beside a dominant one, and the impressions test stops a handful of impressions from listing a small query.

Shares are of page impressions, not of searches. Google says Each unique URL in a Search result is counted separately when data is aggregated by page, so two of your pages in one result are two impressions, and the total behind the shares can exceed the number of searches.

A date column adds the days on which the top page switched, which separates a query one page always leads from one where two pages trade places. The tool's rules:

• A day counts only when the query had at least 10 impressions that day across all its pages.
• A day when two pages tie for the most impressions has no top page and is skipped.
• The newest day in the file is left out, because Google says The newest data can be preliminary (see why the last days in Search Console change).
• A switch is a counted day whose top page differs from that of the counted day before it; the total is a count of days in the file, not of ranking changes.

Is a query with two of your pages always a problem?

No, because Google's own systems can show one site more than once, and two pages can serve different searchers. Google's ranking systems guide says we generally won't show more than two web page listings from the same site in our top results and that we may still show more than two listings. Sitelinks, which Google describes as links from the same domain that are clustered together under a text result, can put several of your pages in one result (our reading of that definition). Penlid's tool page gives the plainest case: a guide and a product page can both serve one query because searchers want different things.

So read each listed query before acting on it (our advice, not Google's): compare the split (a page just over the threshold is a different case from two pages of similar share), check who led, and ask whether a searcher who wanted one page would be served by the other.

How do you check that fixing a split worked?

You check a fix by comparing the page you changed with pages you left alone over the same days, because the changed page's own numbers also move with everything else. Penlid's did-it-work check does this, and its methodology page measures a change over the 28 days before it and the 28 days after it, calling the result not measurable when fewer than three untouched pages are left. Google's help suggests that, to measure a change, you confirm whether your improvement in Search maps closely in timing to your site changes, compared with similar earlier periods, which is timing evidence only (our reading); the guide to telling whether a content update worked covers the method.

If you merge by redirecting one URL to another, Google calls a redirect A strong signal that the target of the redirect should become canonical. That describes a signal, not a result: none of the Google pages we read says a merge raises clicks.