Keyword cannibalization in Search Console data looks like a swap. One page ranks for a query, then months later a different page of yours holds it, and the combined clicks are lower than what the first page earned alone. Two of your URLs competing for one query is common and often harmless; the swap, and the loss around it, is the part worth finding.
Which means the diagnosis needs two periods that are far enough apart to contain both states. That's the part Search Console's 16 months makes awkward.
Get early access Free during early access. No card required.
Why the by-hand version is so slow
Search Console can show you this, one query at a time. Filter the performance report to a query, switch to the Pages tab, and read which URLs appear. Repeat for the next query. There's no view that lists every query with more than one ranking page, so finding cannibalization by hand means already suspecting where it is.
Then the row limits bite. The queries with the clearest cannibalization are frequently mid-tail terms that sit well below the top of your report, so the evidence is in exactly the rows the interface truncates.
How Month17 finds it
Month17's MCP server has a cannibalization_check tool. Give it a start and end date and it returns every query where two or more of your pages have rows, each with its clicks, impressions, and average position, sorted by how many pages are involved. Run it over one period, run it over a period from two years ago, and the swaps stand out without you having to guess which queries to inspect.
Running the second half is the part that needs an archive. Month17 keeps every row with no retention limit, so "the same query, two years ago" stays a question you can ask. Both runs happen in Claude or Cursor rather than in a spreadsheet.
Detection is not a recommendation
The tool reports that several pages rank for a query. It doesn't claim they're hurting each other, because frequently they aren't. A blog post and a product page ranking for the same term can be correct, covering different intents at different stages.
Consolidaton also carries real risk. Merging two pages into one can lose the traffic the weaker page was quietly earning across other queries, and redirects rarely tranfer everything. Treat the output as a shortlist to investigate, and check what each page earns in total before you decide either of them is reduntant.
What the archive changes is only the evidence available when you make that call: two years of positions instead of a snapshot, and the ability to see whether the swap coincided with something you shipped.