Content pruning and consolidation

What too much content actually costs

The damage is not that weak pages exist. It is what their existence does to the pages you care about.

When several of your pages address roughly the same query, engines have to choose between them, and the choice is often unstable. None of them accumulates the signals a single strong page would have gathered, and internal links that should reinforce one page get spread across four. You end up competing with yourself and losing to a competitor who wrote once and wrote well.

There is a second, quieter cost. A large library sets a maintenance burden nobody signed up for. Freshness matters, and a site with hundreds of pages nobody has read in three years cannot realistically keep them current. Cutting the library to what you can actually maintain is what makes ongoing freshness possible at all.

• Several pages splitting the signals that should concentrate on one
• Internal links diluted across near-duplicates
• Crawl attention spent on pages with no chance of ranking
• A maintenance load large enough that nothing gets updated

The decision framework, page by page

Every page gets one of five decisions, and the decision is made from data rather than from how anyone feels about the page.

Keep, for pages performing well: leave them alone. Improve, for pages with a real query behind them that are underperforming: these are usually the best return in the whole project, because the demand is proven and only the page is weak. Merge, for pages overlapping another: combine the useful parts into the stronger URL and redirect. Redirect, for pages with nothing worth keeping but with links or traffic pointing at them. Remove, only for pages with no traffic, no rankings, no links and no strategic reason to exist.

The inputs are traffic over a meaningful period, ranking positions, referring links, conversions, and whether the page duplicates another. The last one is judgement, not a tool output, which is why this is not a job you can automate end to end no matter what the software claims.

Merging properly, which is where the value is

A merge done badly is just a deletion with extra steps. Done well it produces a page stronger than either input.

The method is to choose the destination on evidence rather than preference, usually the URL with the strongest link profile and the better existing rankings. Then take the genuinely useful material from the pages being retired, rather than concatenating them, because a merged page that reads like two articles stapled together performs worse than either original. Then redirect every retired URL to the destination, not to the homepage, which is a redirect that engines commonly treat as a soft removal.

Internal links then need repointing at the destination. Leaving them aimed at redirected URLs works for visitors and wastes a little of the signal, and on a large site the cumulative effect is worth the hour it takes to fix.

Measuring it without fooling yourself

This is easy work to claim a false win on, because something is always moving on a large site.

So the baseline is recorded before anything changes: traffic and conversions for the pages being touched, for the destination pages, and for the site overall. And we agree a measurement window long enough for re-crawling to have happened, which on a large site means a couple of months rather than a fortnight.

We also write down what else is happening in that window. If a campaign launches, a season turns or a competitor drops out, that goes in the report next to the result. A pruning project measured across a seasonal peak will look spectacular and mean nothing, and we would rather show you the caveat than let you plan around a number that will not repeat.

When we will tell you not to do this

Pruning suits sites with years of accumulated content and a flat or declining trend despite continued publishing. Outside that, it is the wrong tool.

On a small site, there is nothing to consolidate and the answer is almost always to write better pages rather than remove existing ones. On a young site, low traffic usually reflects age and authority rather than bloat, and cutting pages removes the base you are trying to build.

There is also a case where the diagnosis looks right and the cause is elsewhere: a technical problem suppressing the whole site, or a traffic mix that never had commercial intent to begin with. Pruning will not fix either, and running it anyway would bill you for work that cannot address your problem.