Content Pruning: When Deleting Pages Is the Fastest Way to Rank

A site publishes two thousand posts over eighteen months and finishes the period ranking for almost nothing. The owner's instinct is to publish faster. The correct move is usually the opposite: work out which of those two thousand pages are actively holding the rest back, and remove them.

Why more pages can mean less traffic

Search engines do not reward a site for the number of URLs it has. They pick, per query, the single page they think best answers it. When a site has four pages aimed at the same intent, the engine has to choose between them — and "choose" often resolves to "rank none of them highly," because the signals that would push one page up are split four ways.

This is the mechanism behind a pattern that looks paradoxical from the outside: a blog's traffic flattens or falls during its most productive publishing months. Nothing broke. The site simply started competing with itself, and every new near-duplicate made the crowding worse.

There is a second cost that is easier to miss. Crawl attention is finite. A crawler that spends its budget re-fetching hundreds of thin, unchanged pages is not spending it on the twenty pages you actually care about.

Pruning is not just deleting

The word "pruning" makes people picture a delete key. In practice there are four outcomes, and deletion is the least common of them.

• Keep as-is — the page has a distinct intent and is the best thing you have for it. Most pages that earn any traffic at all end up here.
• Improve — the intent is right and uncontested, but the page is thin or dated. This is where most of the upside sits, and it costs less than a new post.
• Merge and redirect — several pages chase one intent. Pick the strongest, fold the genuinely useful parts of the others into it, then 301 the losers to the survivor.
• Delete — the page serves no intent anyone searches for, has no links pointing at it, and has nothing worth folding in. Return 410, or 404, and move on.

How to decide, page by page

Pull every URL on the site into one sheet and attach whatever data you have: impressions, clicks, and average position from Search Console; internal links pointing in; external links pointing in; last meaningful update. Then walk the list against a fixed order of questions, so the decision is mechanical rather than sentimental.

1. Does another page on this site target the same intent? If yes, this is a merge question, not a keep question — go to step 4.
2. Does the page get impressions? A page with impressions and a poor position is an improve candidate, not a delete candidate. It is already being considered; it is just losing.
3. Does anything link to it — internally or from another site? An external link is the single best reason to keep a URL alive, even if the content gets rewritten entirely.
4. If it is a duplicate: which of the cluster has the most links and the best position? That one survives. The rest redirect to it.
5. If it has no impressions, no links, and no unique intent: delete it.

The redirect rules that actually matter

A 301 from a merged page to its survivor passes along most of the value the old URL had accumulated. That is the whole point, and it is why "merge and redirect" beats "delete" whenever the old page had any history worth keeping.

But a redirect is only honoured when the destination is a genuine replacement. Redirecting fifty retired posts to the blog index, or to the homepage, is treated as a soft 404 — the engine sees that the destination does not answer the original query and drops the equity anyway. If there is no specific page that replaces the old one, let it 404 or 410 rather than dumping it on the homepage.

For pages that genuinely deserve to disappear, 410 (Gone) is a clearer signal than 404 (Not Found): it says the removal was deliberate. Either works, and 410 tends to get the URL dropped from the index sooner.

What to expect afterwards

Pruning is not instant. The engine has to re-crawl the redirects and the survivors, and consolidate the signals. Expect the picture to look worse before it looks better — total indexed pages fall immediately, which reads as a loss if you are watching that number instead of the ones that matter.

Track clicks and the positions of the survivor pages, not the page count. The goal was never to have more URLs. It was to have a smaller number of pages that each own their intent cleanly.

If you cannot say which query a page is supposed to win, that page is not an asset. It is a tax on the pages that can.

How to stop the problem coming back

Most bloated corpora were produced by a process with no memory — a content calendar, or a generator, that never checked what already existed before commissioning the next piece. The fix is a gate, not a resolution: before anything gets written, search the site for the target intent, and if two or more pages already cover it, the output is a consolidation rather than a new post.

That single rule prevents nearly all of the damage. It also makes the case for publishing less and editing more, which is the harder argument to win internally and almost always the right one.

Where to start if the site is large

Do not attempt the whole corpus at once. Take the largest obvious cluster — the topic you know you have written about repeatedly — and resolve just that one. Merge it down to a single page, set the redirects, and leave it for a few weeks so you can see what the change does before committing to the rest.

One cluster done properly teaches you more about your own site than a spreadsheet covering all of it. It also gives you a real result to point at when someone asks why the publishing schedule slowed down.

If you want a second opinion on which pages are worth keeping, we do this as a fixed-scope audit. Get in touch or message us on WhatsApp.

← Back to all articles