detect_cannibalization

Cost: 10 credits.

detect_cannibalization reads your latest pull_gsc_data and finds keyword cannibalization: queries where two or more of your own pages each pull a meaningful share of the impressions, splitting the ranking signal. Consolidating or clearly differentiating those pages usually lifts the query. Run pull_gsc_data first.

What it does

From the pull's current window, it groups rows by query and flags a query when two or more of its pages each clear both floors: at least 10 impressions and at least a 10% share of that query's impressions. A dominant page plus a negligible straggler is not flagged — only genuine competition. Groups are ordered by total impressions, biggest query first.

Rows for the same page that differ only by a #fragment are folded into one page before any of that is read, so a page competing with its own section anchors is not a group.

Queries for your own brand are excluded, and counted

Several of your pages ranking for your own brand name is normal — it is what Google's sitelinks look like in this data — and consolidating those pages would be self-harm. So branded queries are taken out of the list.

They are not taken out silently. The reply names how many were excluded and which queries they were, because your biggest query disappearing without explanation is its own problem. This matters most when the list ends up empty: "no cannibalization found" can mean nothing was contested, or that everything contested was branded — the exclusion line under it is what tells you which, so read it before concluding the site is clean.

Example

Ask your MCP client in plain language:

Do I have any keyword cannibalization on example.com?

Input

Returns

A list of cannibalized queries, each with its competing pages and their impressions, clicks, and average position (main contender first), followed by the branded-query exclusion line when there was one. If no query is contested, it says so (and you are still charged for the delivered analysis).

Where the data supports it, a query also carries a consolidation recommendation: which URL to keep and which to canonicalize or merge into it, with the positions and impressions that decision was read from. It is deliberately omitted when the competing pages are within about half a SERP page of each other, or when a lower-ranking page is earning more clicks than the better-ranked one — naming a keeper there would be a guess, and the wrong keeper means consolidating away the page that was working.

Your home page is never the page it tells you to fold. A home page ranks for many queries at once, so canonicalizing it into one of them trades away every other query it holds — and rel=canonical is a strong signal to Google rather than a setting you can cheaply take back. When your home page is one of the competitors it is named and explicitly left out of the decision; when it is the only page behind the leader there is no recommendation at all. It can still be the page you are told to keep.

Every reply ends with the same four-line footer the other two discovery tools carry: the window that was analyzed against the one before it, a caveat when either window hit the row cap, when the pull was taken plus a sentence once that is old, and — when your Search Console credential has stopped working — a warning to reconnect.

Inherited limits

This analysis sees only what pull_gsc_data brought back. A pull pages through a window and stops at 100,000 (query, page) rows at the very most — usually sooner, at a storage budget measured on the rows themselves, and the reply names the row count each window was cut at — and a truncated pull also truncates the denominator each impression share is measured against, so on a large property a page's share can read higher than it is — the analysis prints a caveat when the pull hit that cap.

Both windows also end 3 days before today rather than running up to it, so the newest days are not analyzed yet. See pull_gsc_data for both limits in full.