Important: A flagged pair is a prioritization signal, not
an automatic merge decision.
## Questions this page should answer
1. Which page pairs overlap too much in intent?
2. How severe is the overlap based on similarity and matching signals?
3. Which pairs should we merge, re-scope, or relink first?
## Before you analyze
* Make sure [Project Knowledge](/settings/project/knowledge) is synced recently.
* Start with high-value page types (money pages, category hubs, key guides).
* Review the top summary cards before reading pair-level rows.
## What this page gives you
* Summary cards:
* `Analyzed pages`
* `Detected pairs`
* `Similarity threshold`
* `Min overlap matches`
* Pair table with:
* `Page A`
* `Page B`
* `Similarity`
* `Overlap Matches`
## How to read the top cards
* `Analyzed pages`: how many indexed pages were checked.
* `Detected pairs`: number of overlapping pairs found.
* `Similarity threshold`: minimum semantic similarity required to flag a pair.
* `Min overlap matches`: minimum shared matches required before a pair appears.
Use this interpretation:
* High detected-pair count with stable page volume means structural overlap debt.
* Lower threshold values increase recall but add noisier pairs.
* Higher minimum overlap values reduce noise but can hide borderline conflicts.
## How to read the pair table
`Page A` and `Page B` are the two pages that may compete for the same intent.
* `Similarity`: semantic closeness score shown as a percent.
* `Overlap Matches`: number of overlapping signals found between the pair.
Prioritize pairs where:
* Similarity is high.
* Overlap matches are high.
* Both URLs target high-value funnel stages.
## What to do with flagged pairs
Use one of these actions for each pair:
1. Merge pages when both target the same core intent.
2. Split intent clearly by rewriting angle, scope, and title.
3. Strengthen canonical internal linking when both pages should exist.
4. Update metadata and headings to reduce ambiguity.
## Quick weekly checklist
1. Review highest-similarity pairs first.
2. Decide merge, split, or relink per pair.
3. Add implementation tickets with page owners.
4. Recheck overlap after updates are published and knowledge is synced.
## What to fix first
| Pattern in cannibalization table | What it usually means | Recommended action |
| ------------------------------------------- | ---------------------------------------- | -------------------------------------------- |
| High similarity and high overlap matches | Clear intent conflict | Merge or re-scope one of the pages |
| High similarity on commercial URLs | Revenue-impacting competition | Resolve this pair in the current sprint |
| Many pairs in one folder | Topic architecture is too fragmented | Consolidate cluster structure and linking |
| Repeated pairs after previous fixes | Knowledge sync or implementation gap | Re-sync knowledge and validate shipped edits |
| Low overlap but still high similarity score | Borderline conflict or broad topic scope | Tighten angle and search intent per page |
## Team routine
1. Weekly: triage new high-risk pairs.
2. Bi-weekly: verify shipped fixes reduced overlap.
3. Monthly: review recurring conflict clusters and template causes.
## Keep in mind
* This view depends on indexed project knowledge quality.
* Not every overlap is harmful if user intent and funnel stage are distinct.
* Fixes should be validated in rankings and conversion behavior, not only similarity scores.
## Where to go next
* [Project Knowledge](/settings/project/knowledge)
* [Interlinking](/data/technical/interlinking)
* [URL indexing](/data/technical/url-indexing)
* [SEO audit](/data/technical/seo-audit)
Use this page to detect pages that compete for the same intent based on project knowledge similarity.