Find Keyword Cannibalization Candidates in Search Console
Use query-filtered page data or a joint query-by-page export to investigate overlap without mistaking multiple ranking URLs for proof of harm.
Several pages receiving impressions for one query is an overlap signal, not proof of harmful keyword cannibalization. Investigate whether the pages serve the same reader task and whether the current arrangement creates a specific problem before merging or excluding anything.
Start with one query and its pages
Open Search Console's Search results performance report, choose a consistent date range and search type, then filter to an exact query. Switch to Pages to see the URLs observed for that filtered query. Keep country/device filters consistent when comparing periods.
A containing/regex filter can group related queries, but it answers a broader question than an exact-query filter. Name the group clearly. Use the GSC regex builder to prepare and test literal lists rather than silently mixing several intents.
Use data that preserves the relationship
| Input | What it contains | Can it establish query/page pairs? |
|---|---|---|
| Queries tab export | Query-level totals | No |
| Pages tab export with no query filter | Page-level totals | No |
| Pages export filtered to one known query | Pages observed for that query | Yes, when the filter is retained as context |
| API results grouped by query and page | Joint query/page rows | Yes, within the returned data's limits |
Joining two separate aggregate tabs by row number does not recover their relationship. A COUNTIF on a query-only export also cannot reveal which pages appeared for that query.
The Search Analytics API supports grouping by both dimensions. Its results are limited to available/top data; it is not an exhaustive record of every query. Preserve dates, search type and filters in your export notes.
A fictional example
query,page,clicks,impressions
invoice approval checklist,https://example.com/checklist,18,300
invoice approval checklist,https://example.com/approval-guide,7,160
These synthetic rows show overlap. They do not show that either page lost traffic because of the other. Inspect the content and observed results:
| Question | Possible finding | Decision |
|---|---|---|
| Do both pages offer the same checklist? | Nearly identical reader task and material | Consider consolidation with a relevant redirect |
| Is one a calculator and one an explanation? | Useful distinct purposes | Clarify each purpose and link between them |
| Is one an old print/parameter duplicate? | Same content in two views | Review canonical policy |
| Is the overlap occasional and both pages useful? | No demonstrated user/business problem | Leave it and observe |
The query-by-page overlap checker accepts joint data and groups candidates for review. Its output is not a verdict that the pages harm one another.
Evaluate before changing URLs
Read both pages, check their intended queries and compare relevant outcomes. Average position is an aggregate, not a fixed rank. Two values between 5 and 30 do not prove “split link equity.” A traffic decline after publishing a related page also has possible alternative explanations.
If consolidating, preserve useful content, choose the destination deliberately, update internal links and verify redirects. Use canonical annotations for appropriate duplicate representations; do not use noindex merely to hide every secondary result. See canonical diagnosis.
Record the decision
Exact query or named query group:
Source dimensions and reporting filters:
URLs observed:
Reader task of each page:
Evidence of a problem, or reason to leave alone:
Action and publication date:
Comparable later observations and other changes:
Add the intended page responsibilities to your keyword map. Monitor equivalent periods without promising that a merge or title change will stabilize a particular position. A defensible outcome can be deciding that the overlap is useful.