Keyword Cannibalization Is a Yes or No Question. Here Is How We Ask It 4,000 Times
Every page ranking for keyword cannibalization is published by a company selling the tool that detects it, and not one gives you a numeric rule for deciding whether two URLs actually compete. Here is...
Two URLs cannibalize each other when they answer the same search intent, not when they share a keyword. That is a yes or no question about a pair of pages. You can now ask it of every candidate pair on a site, get a probability back on each one, and act only on the pairs the number is confident about. The cost of the asking is measured in fractions of a cent.
If you want the model behind that sentence explained first, read our plain English breakdown of Jev and come back. This post is about the question, not the model.
The short version
- The standard detection method, one keyword ranking on two URLs, is a keyword test standing in for an intent test. It produces false positives by construction.
- Ahrefs argues explicitly that a count-based trigger is the wrong rule, and they are right.1 The problem is that nothing replaces it, so most teams end up with no rule at all.
- All four pages ranking for this term are published by companies selling the software that finds the problem.1234 None of them prints a number you could hand to two people and get the same answer twice.
- The replacement question is "do these two URLs answer the same search intent?" asked per pair, returning a probability, across the whole candidate set instead of a sample.
- Split that judgment into several smaller questions instead of one. On identical held-out data, one question scored 89.4 percent and a five-question composite scored 95.0 percent.5
- BoringToolsKit reports 1,204 pages and 4,816 typed judgments in under three minutes at $0.0048 for a weekly triage run.6 That is their measurement, not ours.
- You are trading accuracy for coverage. Independent benchmarking puts Jev at a Decision Score of 67.8 on pick-one questions against Gemini 3.8 Flash at 74.1, at roughly a twenty-eighth of the price.7 The trade only makes sense because the alternative is auditing a sample.
Why the usual cannibalization test is wrong
Open any guide and the method is the same. Filter Search Console for queries where more than one URL has impressions, then treat the overlap as the finding.
That test asks whether two pages share a keyword. Cannibalization is whether two pages compete for the same searcher. The gap between those two questions is where the false positives live.
A category page and a buying guide can both rank for the same head term without competing. One serves someone choosing, the other serves someone comparing. A pillar page and its own supporting article will almost always share query impressions, because that is what a hub and spoke structure does. Filtering on shared keywords flags both as problems.
Ahrefs is the only page in the set that says this cleanly. Its guide rejects the count-based trigger and insists you confirm the overlap is actually costing traffic before you consolidate.1 That is correct advice, and it is also the end of the article. The reader is left with a warning about false positives and no mechanism for separating them from true ones.
Backlinko gets as far as "if you have more than one page listed for a query, it could be an issue."3 Yoast's softest signal is a page sitting beyond the top five positions.4 SE Ranking's threshold is a red number inside its own interface, applied to a default sample of the thirty highest volume keywords.2 SE Ranking also states, against its own interest, that checking a single case by hand takes thirty to sixty minutes.2
Why the vendors cannot fix this
The structural reason explains the shape of every article you have read on this topic.
A crawler company cannot publish the sentence "you do not need to read these 4,000 rows." Its product is the row count, and an article that reduces your export to forty decisions reduces the reason to renew.
A studio that runs the audits has the opposite incentive. What we sell is the judgment, not the crawl. So we can publish the rule.
The question shape
A decision model takes program state plus a typed question and returns a typed answer with a calibrated probability. It cannot write a sentence. It can answer "yes or no, and how sure" hundreds of times a second.8
Cannibalization fits that shape exactly.
"Do these two URLs answer the same search intent?"
State is the two pages: title, headings, the first few hundred words of body, and the primary query each already ranks for. The answer is a probability between 0 and 1. No essay, no reasoning, no summary. One number per pair.
Two notes before you run it.
Do not evaluate every pair. A 1,000 page site has 499,500 possible pairs. You do not need them. Pull query level data from the Search Console API, which returns up to 25,000 rows per request and does not guarantee completeness beyond the top ones,9 then build candidate pairs only where two URLs both show impressions for the same query. On most mid-sized sites that leaves a few thousand pairs. Four thousand is normal for a site with a mature blog, and it is where the title of this post comes from.
The model does not crawl. It cannot fetch a URL, count affected pages, or retrieve Search Console data.10 In BoringToolsKit's published run the crawling was done by LibreCrawl, self-hosted, with every deployed fix re-checked in a real browser.6 The model judges only what your pipeline hands it. The same split applies to every job in this family, including the internal linking audit we run in 45 seconds and the technical audit that runs past the crawl limit.
What the asking costs
BoringToolsKit published a measured run. On a 1,204 page site, their pipeline produced 4,816 typed judgments in under three minutes, at $0.0048 for the weekly triage run, on model version jev-1.13.0. Crawling was handled by LibreCrawl, not by the model.6
That is their measurement of their pipeline. Yours will differ with page length, because you pay for input tokens and a long page costs more state. The order of magnitude is the point. List price at launch was $0.042 per million input tokens with output free, which is the vendor's own published figure.11
Compare that to the labor anchor. An in-depth audit by an experienced professional or an agency runs from 20 to 200 hours.12 At SE Ranking's own stated pace of thirty to sixty minutes per manual check,2 4,000 pairs is not a task anyone has ever completed. Which is why nobody checks 4,000 pairs. They check thirty and call it an audit.
One more mechanical detail changes how you write the pipeline. Questions sent in a single call are evaluated in parallel, so asking five questions instead of one costs more tokens and almost no additional time.8 That fact is what makes the next section practical rather than theoretical.
Question design beats model choice
This is the part that matters more than which model you pick.
On 20 September, an independent write-up tested the same judgment two ways on identical held-out data. Asked as one question, Jev scored 89.4 percent. Split into five smaller questions and composed in code, the same model on the same data scored 95.0 percent. Claude Haiku moved the opposite way: its best single signal was 94.2 percent, and its five-question composite dropped to 93.2 percent.5
Read that twice. A 5.6 point swing came from how the question was written, not from which model answered it. The direction was model dependent, which means decomposition is something you test on your own data rather than assume.
So do not ask one big question. Here is the cannibalization judgment split into five. Each returns its own probability.
- Do these two pages target the same primary query intent? The core signal. Intent, not keyword.
- Would a searcher issuing that query be fully satisfied by either page on its own? This is what separates a hub from a duplicate. A pillar page and a spoke share the query and fail this one, because the spoke does not satisfy the broad query alone.
- Do the two pages make substantially the same recommendations and claims? Catches rewrites and near-duplicates that survived a migration.
- Is the difference between them a difference of audience or funnel stage rather than of wording? Inverted in code. A yes here is evidence against cannibalization.
- If only one of these could be shown, would the other add anything a reader needs? The consolidation test, stated as a reader question rather than a ranking one.
Compose them in your own code, not in the model. Weight question 1 heaviest, treat question 4 as a veto, and keep every probability stored separately so you can audit which signal drove a decision. Never average them into a single number you cannot take apart later.
Where you set the threshold
A probability is useless until you attach a policy to it. Here is ours, with real numbers, then the method for picking your own, because these are not universal.
Above 0.85: auto-add to the merge candidate list. Not merged. Added to a list a person approves in a batch.
Between 0.55 and 0.85: route to a person. This is the band where the model is telling you it is genuinely unsure, and that information is the product. The jevseo open source project uses 0.55 as its human review floor, which is a published precedent rather than a round number we invented.13
Below 0.55: leave the pair alone. Do not queue it. Do not look at it. The whole value of the run is that it removes work.
Try it
Where would you draw the line?
4,000 judgments, each returned with a confidence. Move the two lines and watch how much work gets done without you, and what it costs you in wrong calls.
2,679
acted on automatically
67 percent of the run, with about 160 expected to be wrong.
1,104
queued for a human
28 percent of the run. This is the pile that decides whether the whole thing saves you time.
222
left alone
Too uncertain to be worth anyone's attention this round.
The lesson is in the second box. Push the accept line high enough to make the error count comfortable and the review queue grows until a person is doing the job again. The threshold is a business decision about how much a wrong call costs you, and it belongs in your code, not in the model.
Now the part the vendors skip. How do you pick 0.85?
Label a sample by hand first. Take 150 to 200 candidate pairs from your own site, have someone who knows the site mark each one cannibalizing or not, then run the model over the same pairs. Sort by the model's probability. The point above which your hand labels agree with the model on roughly nineteen out of twenty pairs is your upper threshold. The point below which almost nothing in your sample was a true positive is your lower one.
You will probably land somewhere other than 0.85 and 0.55, and that is the correct outcome. A news site with heavy topical overlap needs a higher bar than a twelve page services site. Recalibrate when the site changes shape, not on a schedule.
Two rules hold wherever the lines land. Set the upper threshold by how expensive a mistake is, not by how good the model looks. And never let the middle band sit empty. If nothing routes to a person, your thresholds are wrong, not your site.
What you do with a yes
A confirmed pair has four possible outcomes and they are not interchangeable.
Merge. Right when both pages are thin and neither has meaningful links or rankings. Move the useful content into the stronger URL, 301 the weaker one, update internal links pointing at the old target. The default for blog pairs.
Redirect without merging. Right when one page is redundant and has nothing worth moving. Faster than a merge and easier to reverse, because you have not edited the surviving page.
Consolidate under a hub. Right when you have three or more pages that each answer part of a query. Build or designate the pillar, point the fragments at it, and rewrite each fragment to answer its own narrower question rather than the broad one. This is question 2 from the decomposition doing its job.
Differentiate. Right when both pages have earned rankings and losing either would cost you. Change the target intent of one rather than deleting it. Retitle it, restructure the opening to answer a different question, adjust internal anchors. Nobody gets deleted.
The mistake we see most is treating merge as the only option because it is the one every guide describes. Differentiation is the right call more often than the literature suggests, particularly on ecommerce catalogs and anywhere two pages both convert.
What you never automate
Three categories come out of the automatic path no matter what the probability says.
Money pages. Anything that takes a payment, books a call, or captures a lead. A 0.97 on a pair of service pages is a recommendation to a person, never an action. This is the one rule we never relax, and it is why our technical SEO work routes commercial URLs to a human queue regardless of confidence.
Anything with a ranking you would lose. If either URL in the pair holds a position that drives real traffic, the pair goes to a person. The model does not know what that ranking is worth to the business. It does not retrieve analytics and it does not calculate impact.10
Any redirect you cannot easily reverse. A 301 you can undo next week is low risk. A merge that deletes source content, or a redirect chained through a URL pattern you are also changing, is not. If reversing it takes an engineer, a person approves it first.
The honest accuracy trade
You are not getting better judgments. You are getting more of them.
Jevals ran 31,500 scored decisions across seven models. On Choice tasks Jev scored 67.8 against Gemini 3.8 Flash at 74.1. On yes or no tasks it scored 69.0 against 73.0. It runs at roughly a twenty-eighth of the price.7
That is a real accuracy gap and we are not going to talk around it. A frontier model would judge each pair better.
The trade is worth making for one reason. The alternative is not a frontier model judging 4,000 pairs. It is a person judging thirty and extrapolating. A slightly less accurate judgment applied to the whole site, carrying a confidence score that tells you which judgments to distrust, beats a better judgment applied to a sample chosen for convenience.
The recommended architecture follows from that. Run the cheap model across everything for coverage and monitoring, then take the uncertain cases and the failures and re-run those through a frontier model or a person.14 The cheap pass is triage. It is not the verdict.
Two limits belong here, because leaving them out is how these posts go wrong. The model does not explain itself. It returns a number and nothing else, so when a judgment looks wrong you have no reasoning to inspect, only the five separate probabilities you had the sense to store.14 And the widely quoted zero hallucination figure describes schema conformance, not correctness. Type errors being impossible is not the same as answers being right, and the launch coverage says the zero is not empirical.15
If you want the broader version of this argument, including where typed decisions sit alongside generative models in search work, our guide to AI and LLM SEO covers the full pipeline.
Frequently asked questions
What is keyword cannibalization?
Keyword cannibalization is when two or more pages on the same site answer the same search intent, so search engines have to choose between them and neither builds full authority for the query. The common definition, two pages ranking for the same keyword, is a leaky proxy for it. Pages frequently share keywords without competing for the same searcher.
How do you find keyword cannibalization?
Pull query level data from Search Console and build candidate pairs wherever two URLs show impressions for the same query. That gives you a shortlist, not a finding. Then judge each pair on intent rather than keyword overlap, either by hand at roughly thirty to sixty minutes per case or by asking a typed yes or no question per pair.
Is keyword cannibalization always bad?
No. A pillar page and its supporting articles share query impressions by design, and that is a working hub and spoke structure rather than a problem. It is only a problem when both pages answer the same intent and a searcher would be satisfied by either one alone. Ahrefs makes the same point and insists you confirm the overlap is costing traffic before consolidating.
What is a keyword cannibalization checker actually checking?
Most check for shared ranking keywords across URLs and surface the overlap in a list. That is a keyword test, not an intent test, which is why the lists contain false positives. The threshold that decides what appears in red is generally not published, so two tools hand you two different lists from the same site.
How do you fix keyword cannibalization?
There are four fixes and choosing between them matters more than the detection. Merge when both pages are thin. Redirect when one is redundant. Consolidate under a hub when several pages each answer a fragment of the query. Differentiate when both have earned rankings you would lose, by changing the target intent of one rather than deleting it.
Is keyword cannibalization the same as duplicate content?
No. Duplicate content is substantially identical text on more than one URL, which is a text-matching problem. Cannibalization is two pages competing for the same searcher, and it happens constantly between pages that share almost no wording. You can have either without the other, and the fixes differ.
How many pages can you check at once?
Coverage is limited by your crawler and your Search Console export, not by the judgment step. BoringToolsKit reports 1,204 pages and 4,816 typed judgments in under three minutes at $0.0048 for a weekly triage run. The Search Console API returns up to 25,000 rows per request and does not guarantee completeness beyond the top ones, so the API bounds your candidate set.
Should you automate the fix as well as the detection?
Not fully. Detection scales cleanly because a wrong flag costs you a few seconds of review. A wrong merge costs you a ranking. Auto-act only above a threshold you calibrated against hand-labeled pairs from your own site, route the uncertain middle to a person, and keep money pages, protected rankings and hard-to-reverse redirects out of the automatic path entirely.
- Ahrefs, "Keyword Cannibalization: What It Is and How to Fix It", 2026. ahrefs.com
- SE Ranking, "Keyword Cannibalization: How to Find and Fix It", 11 September 2026. seranking.com
- Backlinko, "Keyword Cannibalization: How to Find and Fix It", 2026. backlinko.com
- Yoast, "Keyword Cannibalization: What It Is and How to Fix It", 2026. yoast.com
- XenoSpectrum, "Jev, TypeSafe and the BERT classifier: what decomposition does to accuracy", 20 September 2026. xenospectrum.com
- BoringToolsKit, "What an SEO Audit Costs in 2026", updated 19 September 2026. boringtoolskit.com
- Jevals, independent benchmark of 31,500 scored decisions across seven models, 18 September 2026. jevals.com
- Valyu AI, "How to Use Jev: A Practical Guide to TypeSafe's System One Model", September 2026. dev.to
- Google, "Search Analytics: query", Search Console API reference. developers.google.com
- Screpy, "What a System One model does and does not do in an SEO pipeline", 2026. screpy.com
- TypeSafe AI, "Introducing System One Models and Jev", 15 September 2026. typesafe.ai
- AgencyAnalytics, "How Much To Charge For An SEO Audit", 14 August 2025. agencyanalytics.com
- jevseo, open source project README, confidence gate at 0.55, September 2026. github.com
- Arize AI, "TypeSafe's Jev as an LLM judge", September 2026. arize.com
- MarkTechPost, "TypeSafe AI Releases Jev", 19 September 2026. marktechpost.com
Figures and citations checked on 21 September 2026. The thresholds in this post are ours and are calibrated per site. Copy the method, not the numbers.
Audit stuck in a spreadsheet?
Send us your domain. We run the judgment calls across every URL, not a sample, and hand back a sorted fix list with the uncertain pages flagged for a human.
- Cannibalization, intent and thin-page calls across the whole crawl
- Redirect and internal link maps you can ship
- Scoped estimate within 48 hours
Want to discuss ai search optimization for your business?
Start a project and we'll talk through where you are, what's working, and the highest-leverage moves for the next 90 days.



