When four pages should have been one

Search engines are trying to pick the single best page for a query. When you have four pages targeting that same query, you've forced the engine to choose among your own options, and worse, you've divided whatever authority you've earned across all four. Links, relevance, engagement — the signals that would make one page strong are scattered across a cluster, so instead of one page with a full tank, you have four pages running on a quarter each. None of them reaches the threshold to compete with a rival who put everything into a single page.

This isn't a hypothetical for me. In late July 2026 I measured a real cluster on my own domain out of Google Search Console: four thin, AI-generated posts — mcp-certification, microsoft-mcp-mcse, microsoft-mcp-certification, and mcp-it-certification — all chasing the same 'MCP certification' search. Between them they pulled about 858 impressions across 48 queries in 28 days, and converted exactly zero of those impressions into clicks. Every one of the four sat at position 15 to 25, stranded on page two or three, because Google couldn't decide which of my near-identical pages to trust and so trusted none of them enough to put on page one.

This is counterintuitive because more pages feels like more coverage, more surface area, more chances. For genuinely distinct topics it is. But for the same intent dressed in different words, more pages is just more division of a fixed pool of strength. The engine doesn't reward you for trying four times; it makes your four attempts compete, and split signals lose to concentrated ones. Recognizing that a cluster is cannibalizing rather than covering is the whole diagnosis.

Four pages on the same intent aren't four chances to rank. They're one signal split four ways — and a split signal loses to a concentrated one.

Consolidation starts with a hard choice: which single page should exist as the answer to this intent? Usually it's the strongest already — the one with the most accumulated authority or the best content. In the MCP cluster the choice was easy, because mcp-certification was the strongest of the four at position 15.5, so it became the survivor. But sometimes the winner has the cleanest URL or the best title, and you migrate the best material from the weaker pages into it. The point is to commit to one canonical page that will carry the topic, and treat every other page in the cluster as something to be folded into that one, not maintained alongside it.

Being the survivor didn't mean keeping the survivor's old content, though. Its prior text described 'MCP Certification' as a currently-earnable, globally recognized credential with an exam — which is simply false; Microsoft decommissioned the standalone MCP designation in 2019 and retired the last MCSA/MCSD/MCSE exams on 2021-01-31. So consolidation doubled as a correctness fix: I replaced a page that was quietly lying to searchers with one accurate 2026 guide that honestly serves both meanings of the phrase, and folded the other three into it. The cluster didn't just get concentrated; it got true.

The folding itself is deliberately boring. Each redundant page gets a single field set on it — redirect_to, pointing at the survivor's slug — and that's the whole edit. On the next deploy a build step reads those fields and emits an nginx 301 for each old URL, so anyone or any crawler landing on a folded page is sent to the survivor, and the accumulated value of the old page forwards to it. Instead of four pages each holding a quarter of the strength, you get one page inheriting the whole pool. A redirect is what converts cannibalization back into concentration, and here it's driven by a database column rather than a hand-edited config.

The same row does a second quiet job: the sitemap generator excludes any page whose redirect_to is set, so consolidation also drops the redirected URLs from the sitemap and stops advertising pages that no longer answer. There's a landmine in the timing, though — setting the field is a database write, but the 301 doesn't actually fire until a deploy regenerates the nginx snippet, and then you have to purge the CDN and prerender caches or the old page keeps serving from cache. So the command runs as a dry-run by default and only writes when I pass a flag, because I want to read the full list of what it's about to fold before anything ships.

The failure mode on the other side of cannibalization is over-consolidation — folding pages that only look redundant and actually serve different searchers. When I consolidated a larger cluster of near-duplicate 'AI tools' listicles into one winner, I deliberately left several neighbors alone: the page about AI models, which ranks on its own around position 16, because AI models are not AI tools; and the pages for a voice generator, for Android apps, and for business use, each of which answers a genuinely different query. A page that pulls its own real traffic on a distinct intent has earned its own place and must not be swept into a redirect just because its title rhymes with the survivor's.

So the rule I follow is that cannibalization is proven from data, not assumed from titles. Two pages are candidates for folding only when the search console shows them fighting for the same queries and both losing; if one of them is quietly winning its own intent, it isn't part of the pile-up, it's a separate business I'd be foolish to shut down. Consolidation is subtraction, and subtraction is only safe when you're certain the thing you're removing wasn't doing work you couldn't see.

Consolidation is a hypothesis — you believe these four pages are the same intent and one should carry it — and hypotheses about search are sometimes wrong. So I do it in the reversible way. The redirect is a single field in a table, and the same command that sets it has a revert flag that clears it, which means the consolidation can be undone by removing the row if it turns out one of the folded pages was serving a genuinely distinct need I'd misjudged. I'm not deleting the old pages and destroying the evidence; I'm redirecting them, which keeps the door open to split them back apart if the data says I over-consolidated.

This matters because you can't always tell from the outside whether two pages are truly redundant or subtly different in a way that matters to real searchers. Doing the consolidation reversibly means you can act on your best judgment now and correct it later without a costly rebuild. It's the same ethic that governs every risky change I make: take the version of the action you can take back, because some fraction of your confident calls will be wrong, and you want the undo button when they are.

The result of consolidating that cluster was a single page that could actually compete, because it was finally running on the combined strength of the four it replaced. Nothing about the topic changed; I didn't write anything dramatically better. I just stopped making my own pages fight each other and let one of them have the whole pool. The gain came from subtraction, which is the part that's hard to accept when your instinct says the way to rank for more is to publish more.

It's the same lesson I keep relearning from a different direction: volume is not value, and more pages is not more reach when the pages dilute each other. Sometimes the highest-leverage SEO move is to have less — fewer, deeper, non-competing pages instead of a sprawl that splits your own signal. Consolidation is the unglamorous, subtractive version of content strategy, and it routinely outperforms writing yet another page that would just have joined the pile-up it was meant to escape.

This piece is part of my series on search, answer engines, and content quality. The anchor is AEO and GEO: optimizing for answer engines.