Content pruning. How removing the dead weight can lift the rest of the site.

What pruning actually is

Content pruning is the deliberate removal or consolidation of underperforming pages so the site as a whole looks tighter to Google. The work has two parts: an audit that identifies the dead-weight pages, and a decision tree that picks the right action for each one. The four actions are delete-and-redirect, merge into a stronger sibling, refresh, or leave alone with a documented reason.

Pruning is the opposite move to publishing. Most content strategies focus only on adding pages; pruning is about subtracting them. A healthy content programme does both. The publishing side adds the pages that earn rankings and revenue. The pruning side removes the pages that drag the site down.

Worth saying out loud. Pruning is uncomfortable. Every page on the site was written by someone, took time and money, and felt important when it shipped. Deleting it can feel like an admission that the original decision was wrong. Sometimes it was; sometimes the topic just stopped earning. Either way, the right move for the site is to remove the page, not preserve it out of sentimentality.

Why pruning lifts the remaining pages

Three reasons removing weak pages can lift the rest of the site.

• The helpful-content systems read the site as a whole. Google's helpful-content updates from 2022 onward apply a site-wide quality read, not just a page-by-page one. A high ratio of unhelpful pages drags down the read for the whole site, including the pages that are individually strong. Removing the unhelpful pages improves the site-wide read.
• Internal-link equity gets concentrated on fewer URLs. A site with 200 pages spreads its internal links across all 200; a site with 80 well-chosen pages concentrates the same volume of links on fewer destinations. Pruning improves the per-page link equity for the URLs that remain.
• Crawl budget gets spent on the pages that matter. For large sites, crawl budget is finite. Pruning the pages Google never bothers to recrawl frees the budget for the pages that do change and do matter. Small sites do not have a crawl budget problem, but the principle still applies as a site-quality signal.

The pages that get pruned do not usually have many inbound visitors anyway, so the traffic loss is small. The pages that remain pick up the headroom. Net traffic across the site after a clean prune is almost always up.

The pruning audit

Five inputs drive the audit. Combine them and the dead-weight pages become obvious.

1. Twelve-month traffic from GA4

Pages with zero or near-zero organic sessions over the last twelve months are the strongest pruning candidates. The cutoff worth using: fewer than ten organic sessions in twelve months for most service sites; fewer than one hundred for content-heavy sites.

2. Twelve-month impressions from Search Console

A page that has not picked up impressions in GSC over twelve months is invisible to Google's index. Either the page is not in the index, or it is so deeply buried that it never surfaces. Either way it is not contributing to topical authority.

3. Backlink profile

Does the page have any inbound external backlinks? Pages with inbound links are pruning candidates but with extra care: the link equity must be preserved by 301-redirecting to a relevant existing URL, not by deleting outright. Ahrefs, Semrush or GSC's link report cover this.

4. Strategic role

Does the page play a structural role in the cluster (a pillar, a sibling that holds the topical breadth, a conversion-funnel page that paid traffic relies on)? Pages with a documented strategic role are not pruning candidates even if their organic numbers are weak.

5. Refresh feasibility

Could the page be refreshed back to relevance with two or three hours of work? If yes, refresh is the better path. If no (because the topic is dead, the keyword is unwinnable, or the page duplicates a sibling), pruning is the path.

Score each page against the five inputs and the action becomes clear. The audit usually flags 10 to 20 percent of a site's pages for some kind of action.

The four-option decision tree

Each page flagged by the audit gets routed into one of four actions.

Option 1: Refresh

Use this when the page has at least some impressions, the topic is still relevant, and a rewrite can close the gap. The content refresh chapter covers the workflow. Most pages that look like pruning candidates at first glance are actually refresh candidates.

Option 2: Merge into a stronger sibling

Use this when the page covers a topic that already lives on another URL but adds some content the sibling lacks. Combine the unique content from the weak page into the stronger sibling, then 301-redirect the weak URL to the sibling. The link equity transfers; the duplicate intent disappears.

Option 3: 301-redirect to a relevant URL

Use this when the page has inbound links or some rank history but no unique content worth merging. Pick the closest topically-relevant existing URL and 301-redirect to it. The link equity transfers; the page disappears from the index. See 301 vs 302 redirects for the redirect mechanics, and canonical tags explained for the parallel signal.

Option 4: Noindex (rarely delete outright)

Use noindex for pages that must exist for users but should not be in the index: privacy policy, terms, internal-search results, paginated archives. See the noindex glossary entry. Use outright delete (HTTP 410) only when the page has no inbound links, no rank history, and no remaining purpose. Most pages worth pruning are better served by a 301 to a sibling than by a hard delete.

The decision tree resolves every flagged page. No page should sit in pruning limbo with "to decide later" against it. Make the call, log the action, schedule the rollout.

The rollout plan

Pruning is a small migration. Treat it like one.

1. Batch the actions. Group the pruning decisions by action type: a batch of refreshes, a batch of merges, a batch of 301 redirects, a batch of noindex changes. Each batch gets its own rollout window.
2. Map the redirect chain. One column for the old URL, one column for the destination URL. Verify no redirect points at another URL being redirected (avoid redirect chains, which Google can lose track of past three hops).
3. Update internal links first. Before flipping the redirects, update internal links pointing at the to-be-removed URLs so they point at the new destinations. This avoids unnecessary redirect hops for crawlers and users.
4. Roll out in waves of 25 to 50 URLs. Not all at once. Waves make any unexpected ranking response measurable to a specific batch rather than the whole prune.
5. Monitor for 30 days. Watch the rankings of the surviving pages, the crawl errors in GSC, and the redirect chain integrity. Adjust if any specific batch underperforms.

Common mistakes

Perth and WA context

Three patterns from running pruning audits for Perth and WA clients.

Trade sites often have legacy blog backlogs. A Perth plumbing or electrical site that has been publishing weekly for five years usually has 200-plus blog posts, most of which were never strategic to begin with. A pruning audit on these sites typically routes 30 to 40 percent of posts to merge or 301-redirect into the relevant service pages, with a small handful refreshed. See trades SEO and SEO services in Perth for the broader service context.

Multi-location sites accumulate doorway-style suburb pages. Sites that built out a suburb page for every Perth and Peel suburb six years ago without local context end up with 80 thin pages that never ranked. The right move is usually to merge them into a smaller set of richer suburb pages (one per genuine service area, not one per postcode). See multi-location strategy and SEO Mandurah for the consolidation pattern.

Healthcare and legal sites need extra documentation on pruned pages. For YMYL topics, removed content sometimes needs a documented reason (regulatory change, outdated medical advice, superseded case law). The pruning log doubles as a compliance audit trail. See healthcare SEO, legal SEO and E-E-A-T explained for the relevant context.

For the wider content-strategy frame, see the Content Strategy pillar. For the refresh path that most pruning candidates actually belong on, see content refresh strategy. For the cannibalisation fix that often comes up during pruning, see how to fix keyword cannibalisation. For the technical-side mechanics that pruning relies on, see canonical tags explained and 301 vs 302 redirects.