Keyword Cannibalization: We Found Six of Our Own Pages Fighting
A site-restricted search returned six of our guides for one concept. The unrestricted search returned none of them. That gap is the problem.
Copy this line to your agent to check whether your own pages compete.
set up https://monid.ai/SKILL.md and use mrscraper /serp/google with a site: query for one concept
We ran a cannibalization check on our own blog on 2026-09-23 and found six of our guides answering one concept. A site-restricted search returned them stacked one after another. The same search without the site restriction returned none of them anywhere on page one. Eight pages are tangled in that cluster and exactly one of them ranks for anything at all, at position fifty. This guide is that audit, run through Monid, the OpenRouter for agent tools.
What is keyword cannibalization?
Several of your own pages competing to answer one query, so that the search engine has to pick, and the thing it picks is rarely the one you would have chosen.
What actually goes wrong
Signals split. Links, engagement and relevance that would concentrate on one page spread across four. Each page individually looks thinner than the topic deserves.
The wrong page gets shown. Google picks per query, and it can pick a passing mention over your dedicated article, which then converts worse than either page would have.
It is unstable. Which page ranks flips between crawls, so your position data on that term is noise and you cannot tell an algorithm change from a rotation.
What it is not
It is not "two pages mention the same word". Topical overlap is normal and desirable on a site with depth. Cannibalization is when two pages target the same intent, meaning a searcher would be equally served by either, and that distinction is the one the tooling usually gets wrong.
Why the tool in the query does not settle it
People search for this alongside a specific SEO suite, and a suite is genuinely good at it, because it already holds your position for every keyword on every URL and can therefore show two of your pages trading places on one term over weeks. A single search cannot do that. An earlier version of this paragraph also said we do not resell that suite's keyword data, which was wrong and is corrected in the Ahrefs guide: the per-call route does cover volume and difficulty. What no call covers is your own ranking history, which is exactly what a cannibalization report keys on. So the method below deliberately needs neither, and a site-restricted search plus your own files found our worst cluster with no ranking data at all.
📖 See also Google SERP Tracker and Analysis: Which SERP API Do You Need?
How do you find it without ranking data?
Two passes. One reads your own repository, the other asks Google which of your pages it would pick.
Pass one: your own corpus, no API at all
Every post carries tags. Compare them pairwise and count the overlap. Across our 124 guides, 51 pairs share two or more tags. The top pair shares four.
llm-gateway-vs-mcp-gateway × openrouter-alternatives-after-stripe
shared: llm gateway, mcp, agent tools, routing
That took no calls and no credentials. It is a structural smell, not proof, and its job is to tell you where to spend the calls.
Pass two: ask Google which page it prefers
A site-restricted search for the concept returns your own pages ranked against each other. That ordering is the search engine's own answer to "which of these is the one", and the number of candidates it lists is the size of your problem.
monid run -p mrscraper -e /serp/google \
--query '{"query": "site:monid.ai mcp gateway", "region": "us", "language": "en"}'
Read the count first. One or two of your pages is a topic. Six is a decision Google is making on your behalf every time somebody searches.
Pass three, optional: the unrestricted query
Run the same concept without the site restriction. This tells you whether any of it ranks at all. On our cluster the answer was none of it, which is the uncomfortable pairing described further down.
How do you check a cluster through one key?
Three steps and one judgement call.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main
Step 1. Shortlist from your own files
pairs = [(a, b, shared) for a, b in combinations(posts, 2)
if len(shared := set(a.tags) & set(b.tags)) >= 2]
Sort by overlap size. The top of that list is your call budget for step two.
Step 2. One site-restricted search per concept
The endpoints. mrscraper/serp/google, per call, takes query, region, language.
For each concept, query site:yourdomain.com <concept> and record which of your URLs come back and in what order. One call per concept, not per page, so a twenty-concept audit is twenty calls.
Step 3. Decide per cluster
Three outcomes and three actions:
| What you see | What it means | What to do |
|---|---|---|
| One page of yours | Healthy | Nothing |
| Two, clearly different intent | Normal depth | Differentiate titles, cross-link |
| Three or more, same intent | Cannibalized | Merge, or give each a distinct target |
Step 4. Re-check after you act
The site-restricted search is cheap enough to re-run monthly. It is also the only way to tell whether a retitle actually changed which page Google prefers, because your own intent is not evidence.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to for each of these concepts, run a site-restricted google search on our domain, list which of our URLs come back in order, and flag any concept where three or more of our own pages appear.📖 See also Automate SERP Tracking
What did our own site look like?
Bad, in a specific and instructive way.
Six pages, one concept
site:monid.ai mcp gateway, ten results, six of them our guides:
1 /blog/guides/llm-gateway-vs-mcp-gateway
2 /blog/guides/what-is-an-mcp-gateway
3 /openrouter-for-agent-tools ← our landing page
4 /blog/guides/openrouter-alternatives-after-stripe
5 /blog/guides/bright-data-mcp-what-you-are-installing
6 /blog/guides/mcp-server-live-web-data-agents
8 /blog/guides/api-marketplace-for-ai-agents
Seven of our URLs in the top eight results for one concept on our own site.
And zero of them rank
The same endpoint, the same day, without the site restriction:
| Query | Organic results | Ours on page one |
|---|---|---|
mcp gateway | 9 | 0 |
what is an mcp gateway | 8 | 0 |
llm gateway vs mcp gateway | 8 | 0 |
mcp vs api for ai agents | 7 | 0 |
openrouter alternatives | 9 | 0 |
Eight pages on a topic, and none of them on page one for any of its five main queries. Our ranking data agrees: of those eight pages exactly one ranks for anything anywhere, at position fifty, on a term worth ninety searches a month.
The uncomfortable pairing
It would be comforting to say the cluster is cannibalized therefore it does not rank. That is not a claim this measurement supports. A young domain not ranking for a competitive concept is the expected state regardless, as our own link profile makes plain. What the measurement does support is narrower and still worth acting on: we have split whatever authority the topic earns across eight pages instead of concentrating it on one or two, so if the topic ever becomes winnable we have pre-committed to losing it.
The part we did not expect
Our own product landing page appears at position three on that list, and at position one on two other site-restricted queries. The guides are not only competing with each other. They are competing with the page we actually want people to reach.
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
mrscraper/serp/google | Google results as JSON | query, region, language | Organic rows with rank and global rank | Site-restricted cannibalization checks | Per call |
context.dev/web/search | Google results with page content | query, numResults | Rows with inline markdown | Reading what the competing pages say | Per result |
api.strale.io/x402/sitemap-parse | Sitemap reconnaissance | url | Counts and path segments | Enumerating your own pages | Per call |
firecrawl/map | Every page a site links to | url | URLs with titles | Auditing a site you do not own | Per call |
ahrefs/site-explorer/refdomains | Which pages earned links | target | Linking domains | Choosing which page survives a merge | Per result |
Every row was verified with monid inspect on 2026-09-23. The table gives billing shape rather than figures, because shape drives design and current numbers live on monid.ai/tools.
The last row is the one that decides a merge. When two pages must become one, the one with the links wins regardless of which is better written.
When is overlap fine?
Four cases, and the first is most of them.
Different intent, same subject. A definition page and a comparison page on the same technology serve different searchers. Ours are a legitimate example of this, and they are still on the list above, because sharing four tags is how a structural check flags them. Judgement beats the heuristic.
A hub and its spokes. A pillar page and the detailed articles under it are supposed to co-occur. The test is whether the spokes each own a query the hub does not.
A landing page and an article. These have different jobs, and the landing page outranking the article on a product term is correct. It stops being fine when the article was written to attract a reader the landing page then never receives, which is worth checking rather than assuming.
Deliberate near-duplicates for different audiences. Rare, and usually a mistake. If you cannot name the two audiences in one sentence each, it is a mistake.
And the disclosure: this is Monid's blog and we resell the endpoints here, including a SERP route that costs a fraction of a cent per check. We also just published our own worst content cluster, which is not a flattering use of it.
Conclusion
Keyword cannibalization is easier to find than people think and the check costs almost nothing. Two passes did it here: a tag-overlap scan over our own files that needed no API and surfaced 51 suspicious pairs, then one site-restricted search per concept that showed Google ranking six of our guides against each other, with our product landing page sitting among them at position three.
What matters more than the tooling is the count. One of your pages for a concept is health, two is depth, and six is a decision you have handed to a search engine. Our eight-page cluster returns exactly one ranking position across five of its main queries, at fifty, on a ninety-a-month term. We are not going to claim the cannibalization caused that, because a young domain would struggle there anyway. We are going to fix it, because splitting a topic across eight pages guarantees that winning it later is harder than it needs to be.
Free next step: run one site-restricted search on your own domain for the concept you most want to own, and count how many of your own URLs come back. If the answer is more than two, you have found your next content decision without opening a single dashboard. Start at monid.ai.
FAQ
Should you just use a dedicated SEO tool for this?
If you have one, yes, for the part it does better: a suite already knows your position for every keyword on every URL, so it can show you two pages swapping places on one term over time, which no single search can. What this method gives you that a suite does not is independence from ranking data. Our cluster has almost no rankings at all, so a report keyed on "URLs competing for terms you rank for" would have shown very little, while the tag scan and one site-restricted search found eight tangled pages immediately. Use both if you can, and use this when you are early enough that ranking data is sparse.
Should you merge the pages, redirect them, or differentiate them?
Differentiate first, because it is reversible and cheap: give each page a distinct primary target, rewrite the title to lead with it, and make the internal links say which page is for which question. Merge when two pages genuinely answer the same question and neither can be narrowed without becoming thin, and then redirect the loser to the winner rather than deleting it. Choose the winner on links, not on quality, since links are the thing you cannot move; the referring-domains endpoint in the table answers that in one call.
Is it a problem when a landing page outranks your articles?
Usually not. A product page ranking for a product term is the outcome you want, and an article that ranks just below it is doing its job of catching the informational variant. It becomes a problem in one specific case: when the article was written to attract a reader who then has no path to the landing page, or when the article outranks the landing page on the commercial term, which sends buyers to an explainer. Ours appeared at position three among six guides on one site-restricted query, which is worth watching rather than fixing today.
How many pages on one topic is too many?
There is no universal number, but the site-restricted search gives you a usable rule: if you cannot look at the list it returns and say in one sentence what each page is for, you have too many. Three pages with three crisp jobs are fine. Six pages where two of them are "sort of about gateways" are not, regardless of how good each one is individually. The count matters less than whether the intents are separable, and the fastest way to find out is to try writing the one-sentence job for each and notice which one you cannot finish.
Last updated September 2026.
