Recipe
The keyword cannibalization report
Keyword cannibalization is what happens when you’ve written about the same thing more than once. Three posts target “how to choose a standing desk.” Google has to pick one, splits your authority across all three, and often surfaces the weakest. You see it as a page that should rank but won’t — and the cause isn’t that post, it’s the two siblings quietly competing with it. On a small blog you remember the overlaps. Past a couple hundred posts you don’t, and the overlaps are exactly where years of compounding effort leaks. This recipe reads the whole archive at once, groups posts that chase the same intent, and hands you a decision for each group. The analysis is read-only; the fixes are deliberate and reviewed.
What you need
- Spectersync synced to your blog
- An AI assistant you already use
- Your top queries from Search Console (optional, but sharpens the grouping)
The recipe
- Pull and stage. Spectersync pull, git baseline. The report reads titles, intros, and headings across every post.
- Run the report (read-only). It clusters posts by the search intent they target — not just shared words, but the question a searcher is asking — and ranks each cluster by how much overlap there is. No files change.
- Decide per cluster. For each overlap the report proposes one of three moves: consolidate (merge the weaker into the stronger), differentiate (re-angle each to a distinct intent), or redirect (one is redundant — retire it). You make the call.
- Apply the move. Merges and re-angles are body rewrites you preview with a dry-run. Retirements feed a redirect map so nothing 404s.
- Push and recheck. Push the reviewed changes; re-run the report after the next crawl to confirm the cluster collapsed to a single owner.
The prompt
The report is read-only:
Analyze this archive for keyword cannibalization. Group posts that target the
same search intent — judge by the question a searcher is asking, not surface
word overlap. For each group output: the shared intent in one line; the member
posts with a one-line note on each; which post is strongest and why; and a
recommended move — CONSOLIDATE (name the merge target), DIFFERENTIATE (give each
post a distinct angle), or REDIRECT (name the post to retire and its best
target). Sort groups by overlap severity. Ignore posts that share a topic but
serve genuinely different intents. Do NOT modify any files.The consolidation pass (run per group you approved):
Merge the listed weaker post(s) into the named target post. Fold in any unique,
still-accurate information the weaker posts contain; drop duplicate passages;
keep the target's structure and voice. Do not lengthen for its own sake. Output
the merged body and a list of which source passages you carried over. Change no
other files. The retired posts will be handled by a separate redirect step — do
not delete them here.Cost and time
| Blog size | Tokens (report) | Cost | Wall-clock |
|---|---|---|---|
| 100 posts | ~250k | $0.60 | 15 min |
| 300 posts | ~750k | $1.80 | 45 min |
| 800 posts | ~2M | $5 | 2 hr |
The report is the cheap part. Most of the time is your judgment on each cluster — which is right, because consolidating the wrong direction loses a page that was working.
Pitfalls
- Don’t merge distinct intents. “Best standing desks” and “are standing desks worth it” share words but serve different searchers. The prompt is told to leave those alone; verify it did.
- Always redirect, never just delete. A retired URL with inbound links and rankings needs a 301 to its replacement. Build the redirect map before you unpublish anything.
- Re-check after a crawl, not the same day. Search engines need to recrawl before the cluster resolves; judging too early looks like the fix failed.
Where to go next
Pair it with the topical cluster builder — once you’ve removed the accidental overlaps, deliberately structure the survivors into pillar-and-cluster sets so the consolidation compounds.