Content Pruning in 2026: How I Delete 30% of Client Pages and Gain Traffic

The nicest email we got all year had the subject line "thank you for the deletes". It came from the CEO of a 12-year-old SaaS company whose blog we had just taken a chainsaw to. We removed or hid roughly 4,200 of their 6,800 indexed URLs over three months. Their organic clicks climbed from a flat 14,000 a month to a little over 19,000 inside eight weeks.

Clients rarely write to celebrate things being removed. People want to see new posts going up, not old ones coming down. But content pruning has quietly become the single most reliable lever we have for moving traffic on an ageing site, and after the spring 2026 update cycle it matters more than it ever did.

This is the actual playbook. The Search Console query that does most of the work, the four-bucket decision tree we run every URL through, the mistakes we have made (one of them killed a 700-visit-a-month page we should never have touched), and an honest correction to a piece of advice that gets repeated everywhere and is wrong.

What is content pruning?

Content pruning is the process of reviewing every indexable URL on a site and assigning each one to a single fate: rewrite it, redirect it, hide it from search, or delete it. That is the whole thing. It is not a synonym for deletion, and that misunderstanding is why most teams avoid it.

Done properly, a pruning audit sends roughly half its candidate URLs to be rewritten rather than removed. The point is not to be ruthless. The point is to be honest about which pages are still earning their place, and which ones are quietly dragging the rest of the domain down with them.

A few things pruning is not:

• It is not a one-off spring clean. We run a light prune quarterly for active clients and a deep one once a year.
• It is not only about thin content. Some of the worst offenders are long, well-written posts chasing a topic the site has no business ranking for.
• It is not the same as "refresh your old posts". A refresh assumes the page deserves to keep existing. A prune asks that question first.

Here is the uncomfortable bit. Most sites we audit have somewhere between 20% and 40% of their indexed URLs in the "should not exist" bucket. Not 5%. Not 10%. The numbers are big because most content programmes have run for years without anyone asking whether the posts they shipped in 2019 still pull their weight.

Why pruning hits harder in 2026 than it did in 2022

We have been pruning content for clients since 2019, but the maths changed in the last eighteen months. Three things moved at once.

The helpful content system is now baked into core ranking. Google folded its standalone helpful content classifier into the core ranking systems with the March 2024 core update. On its own blog, Google said it expected the work to cut "low-quality, unoriginal content in search results by 40%", and after the rollout completed on 19 April 2024 it revised that up, telling everyone you would now see "45% less low-quality, unoriginal content in search results". The practical consequence: there is no separate "helpful content recovery" path anymore. It is just ranking. A pile of weak pages can weigh on the parts of your site that are genuinely good.

Google's own guidance tells you to self-assess. Its creating helpful content documentation hands site owners a long list of questions and says "evaluating your own content against these questions can help you gauge if the content you're making is helpful and reliable". It also tells you to audit the pages that dropped during a downturn. Notice what that is. It is a pruning brief, written by Google.

AI Overviews are eating informational clicks. This is the big one. A Pew Research Center study published on 22 July 2025 tracked real browsing behaviour and found that when an AI summary appeared, users clicked a traditional search result in just 8% of visits, against 15% when no summary was present, nearly twice as often. The link inside the AI summary itself got clicked in only 1% of visits. If a definitional page used to bring you 200 visits a month and now brings 12, it has stopped earning its index slot. We have written more about how this plays out in our coverage of the AI Overviews click-through rate drop.

The net effect: in 2026, doing nothing with old content is the expensive option. Pages that trickled in traffic in 2022 are now silently taxing the whole domain.

The decay query we run in Search Console every week

This one query does about 80% of the work. We run it in Google Search Console for every client domain, weekly, and dump the results into a sheet for review. Search Console gives you up to 16 months of performance history, which is enough to spot a real decline rather than a seasonal wobble.

The filter set:

1. Date range: last 16 months (the maximum the standard interface allows).
2. Compare: last 28 days against the previous 28 days.
3. Page filter: contains /blog/, or whatever your content directory is.
4. Sort by clicks, descending.

Then we score the decline. A URL that has lost more than 60% of its clicks period on period is a candidate. So is any URL with fewer than three clicks in the last 28 days but more than a hundred impressions over the trailing 16 months. That second group is telling you something specific: Google thinks the page is worth showing, and people keep declining to click it.

For anything over about 5,000 URLs we pull this through the Search Console Search Analytics API rather than the interface, because the UI tops out at 1,000 rows and the API lets you group by page and query and pull the lot in batches. The interface also quietly deduplicates rows when you filter by page and query together, which makes your export look smaller than reality. It took us an embarrassingly long time to work that out.

If you want to read your Search Console data properly before you start cutting, our breakdown of the newer Search Console features covers the filters most people skip.

The four-bucket decision tree: rewrite, redirect, noindex, delete

Every candidate URL runs through these four questions in order. The first "yes" wins. Pick one fate per URL and move on. Do not invent a fifth bucket.

Bucket 1: Rewrite

Ask: does this URL target a query the business actually wants to rank for, and is the topic still relevant?

If yes, rewrite it. Do not redirect, do not delete, keep the URL. The signals: it targets a commercial or high-intent keyword that still gets searched, it has at least one referring domain worth keeping, the topic sits in your lane, and the current version is just outdated, thin, or badly structured.

For SaaS and service businesses this is the biggest bucket. Roughly half to sixty percent of candidates land here. The trap is the lazy rewrite. If you only swap the dates and a couple of sentences, the page decays again within six months and you have wasted everyone's afternoon. We budget the same time for a serious rewrite as for a fresh post, because that is genuinely what it takes. A strong rewrite needs proper on-page SEO structure and a single, clear primary query the page exists to answer.

Bucket 2: Redirect

Ask: is there a stronger page on this site that already covers, or could cover, the same intent?

If yes, 301 it across. Choose the target carefully, because Google has long treated off-topic redirects as soft 404s. Send a post about "best CRM for plumbers" to your homepage and Google will very likely ignore whatever equity you thought you were rescuing. Good targets: a pillar or hub on the same broad topic, a newer post that supersedes the old one, or a service or product page that matches the intent. Bad targets: the homepage, an unrelated category page, anything that does not visibly cover the original query.

We redirect roughly 15-20% of candidates. Always a 301, never a 302, and always to a topically close page. We also check the original had at least one referring domain or a measurable trickle of traffic first. If it had neither, do not redirect it. Just delete it. Redirects add overhead and clutter your next audit.

Bucket 3: Noindex

Ask: does this URL need to exist for users, but it has no business showing up in search?

If yes, add a noindex robots meta tag and leave the page live. Google's documentation on blocking indexing is blunt about what happens next: "when Googlebot crawls that page and extracts the tag or header, Google will drop that page entirely from Google Search results, regardless of whether other sites link to it." Common candidates are author archives with nothing but a bio, tag pages with three or four posts, internal search results, thank-you and confirmation pages, and legal pages that need to exist but do not need to rank.

One mistake we see constantly. People block the URL in robots.txt as well as adding the noindex tag, thinking they are being thorough. They are doing the opposite. Google spells it out: "for the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file." If Googlebot cannot crawl the page, it never sees the tag, and the URL can stay indexed for months with a blank description. If you want to get crawl directives right more broadly, our robots.txt optimisation guide walks through the common own-goals.

Bucket 4: Delete

Ask: no traffic, no backlinks, no internal demand, no business reason to exist?

If yes, delete it. And here is where we are going to correct a piece of advice that gets repeated in nearly every pruning article, including, embarrassingly, an earlier version of this one.

The standard line is that you must return a 410 Gone rather than a 404 Not Found, because 410 deindexes much faster. That is folklore. Google's official documentation on HTTP and network errors says plainly that "all 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn't exist", and that for a previously indexed URL "the indexing pipeline removes the URL from the index". A 410 will not get your page dropped on any meaningfully different timeline to a 404. So do not spend a sprint reconfiguring your server to serve 410s for a speed benefit that Google says does not exist.

What actually matters when you remove a page:

• Return a clean 404 or 410. Either works. Pick whichever your platform makes easy.
• Remove the URL from your XML sitemap so you stop inviting Google to recrawl it.
• For permanent removal, Google's guidance on removing your information tells you to remove or update the content, password-protect it, or apply a noindex tag, and warns directly: "don't use robots.txt as a way to block your page."

Delete-bucket sizes swing with site age. On a ten-year-old blog we have deleted 40-50% of indexed URLs. On a three-year-old SaaS blog it is closer to 10-15%. For the crawling and indexing mechanics underneath all of this, our technical SEO strategies guide covers how these signals flow through the pipeline.

Mistakes we have made (so you can skip them)

Most "how to prune" posts pretend this is a tidy exercise with no casualties. It is not. Here are the ones that cost us.

The redirect-everything-to-the-homepage disaster. Early on, one of us redirected about 300 obsolete posts to a client's homepage. Within three weeks Google had treated almost all of them as soft 404s and the equity we thought we were preserving had evaporated. The lesson stuck: a redirect that ignores user intent is just a delete with extra server load.

The 700-visit page we killed. We redirected an old comparison page on a SaaS client because it looked thin in the audit sheet. Four hundred words, surely a candidate. It was sitting at position three for a niche term and bringing in 700 visits a month. We had not segmented the export by traffic before making the call. Now anything pulling more than 50 visits a month gets a manual review, no matter how badly it scores on automated thinness checks.

The over-eager noindex pass. On another account we noindexed every tag page with fewer than ten posts. Should have been fewer than four. We lost a chunk of long-tail rankings from tag pages that were genuinely useful entry points, and it took Google a month to recrawl and reinstate them.

Not warning the dev team. A client's developers saw a spike of deletions in their monitoring, assumed it was a bug, and rolled the whole thing back. Now we brief the dev team in advance and label every deleted URL in the changelog before anyone touches production.

If you want to see what going slow and methodical looks like when it works, our writing on internal linking patterns across 300 sites shows how the surviving pages should connect to each other once the dead weight is gone.

How we pruned 4,200 pages from a SaaS blog

Back to the thank-you email. Here is the project that prompted it, week by week.

The client: B2B SaaS, 12-year-old domain, 6,800 indexed URLs in the blog directory, most published between 2014 and 2021. Organic traffic had been flat for two years and dipped after the March 2024 alignment, which is exactly what you would expect from a site full of pages Google had quietly decided were unhelpful.

Week 1, audit and segment. We pulled the full URL list through the Search Console API, joined it to a Screaming Frog crawl and Ahrefs referring-domain data, and built one row per URL: clicks over 16 months, clicks last 28 days, impressions, referring domains, internal links in, word count, last modified, top organic query, and intent type.

Week 2, the decision pass. Every URL got tagged. The split landed at:

• Rewrite: 1,180 URLs (17%)
• Redirect: 980 URLs (14%)
• Noindex: 640 URLs (9%)
• Delete: 4,000 URLs (59%)

That delete share is normal for an old blog where editorial standards drifted. About 2,800 of them were product-update posts from 2014 to 2018 describing features that no longer existed.

Weeks 3-4, deletes and noindex first. Deletes went out in three batches of roughly 1,300, 48 hours apart, with the URLs pulled from the sitemap. The noindex batch went in one push. We watched Search Console daily for crawl-error spikes and indexation drops.

Weeks 5-8, redirects and rewrites. Redirects went out mapped to topical clusters. Rewrites were prioritised by current impressions, highest-impression decay candidates first. We cleared about 200 rewrites in the first eight weeks, then settled into 50 a month.

The result. Organic clicks moved from a flat 14,000 a month to 19,200. Conversions tracked with it, up about 31%. The CEO sent the email. His team had spent two years lobbying for more content production. The exercise proved the lever was pointing the other way.

We will be straight with you: not every prune produces a lift this size. Some sit flat for twelve weeks then climb. A couple have come in around 8-12%. But we have not yet run a careful deep prune on an aged site and watched it lose traffic over a three-month window. If you are disciplined with redirects, the downside is genuinely small.

How AI search changes which pages survive the cut

A pattern we started seeing in late 2025 and straight through 2026: pages that used to be safe long-tail trickle assets are now zero-click candidates, because AI Overviews and chatbot answers are absorbing the informational queries before anyone reaches a blue link.

The tell is the impressions-to-clicks ratio drifting apart over time. If a page held a 6% click-through rate in 2023 and sits at 0.4% in 2026 for the same queries, the value of keeping it indexed has fallen close to zero. The Pew numbers above are the macro version of exactly this. So we add an AI lens to the decision tree:

• Rewrite as a citation target if the query is being summarised by AI and you can realistically be the source it pulls from. Our guide to getting your brand into AI answers covers what citation-ready content actually looks like.
• Delete or noindex if the page chases a pure definitional query that AI now answers above the fold and you have no real shot at being cited.
• Consolidate if you have three or more pages fragmenting your authority on one topic. Pick the strongest, fold the value in, redirect the rest.

This is a real shift in standards. In 2022 you kept almost anything pulling 30 visits a month. In 2026 that same page can be a net negative, dragging your perceived helpfulness down while sending you visitors who bounce on arrival.

Tools and signals we trust, and the ones we ignore

We trust Google Search Console as the source of truth for impressions, clicks, and indexation status. Screaming Frog for status codes, canonical chains, and redirect maps. Ahrefs or Semrush for referring-domain counts per URL. The Internet Archive's Wayback Machine for checking what a page looked like before a drop. And Google's own Search Quality Rater Guidelines, the closest thing to a public rubric for what "low quality" means, which you can read in full as a PDF straight from Google.

We ignore a few things on principle. Generic "content score" numbers from SEO suites, because they flag perfectly good pages as thin on word count alone. AI-generated audit summaries that recommend deletion without showing the data, which have tried to talk us into deleting clients' top-converting posts. And any tool that prunes on page age, because age is not a quality signal. Some of our best-performing client pages are eight years old and have never needed touching.

What to do this week

If you have been putting off a content audit, here is the smallest useful first step. An afternoon, no more.

1. In Search Console, export the last 16 months of page-level performance for your blog directory.
2. Open it in a sheet. Add a column for clicks per month, clicks divided by 16.
3. Sort ascending. Count every URL under three clicks per month over the full 16 months.
4. If that count is more than 15% of your indexed URLs, you have a pruning opportunity worth taking seriously.
5. Take the bottom 50. Open each one. Tag it rewrite, redirect, noindex, or delete using the tree above.
6. Pick the ten clearest deletes (no backlinks, no traffic, off-topic, obsolete). Remove them and pull them from the sitemap.
7. Wait four weeks. Check Search Console for any unexpected impressions drops elsewhere.
8. If nothing broke, do the next 50, then the next 100. Build the muscle before you attempt the full audit.

Pruning is not glamorous. It will never make a good LinkedIn post. But it has been the most dependable traffic lever we own on ageing sites, and the spring 2026 update cycle has only sharpened that. Most blogs do not need more posts. They need fewer, better ones, connected well and pointed at queries the site can actually win. That work pairs naturally with a focused SEO programme rather than a content treadmill.

If you would like us to look at your blog and tell you roughly what share of your indexed URLs are pruning candidates, or run the whole exercise for you, get in touch and we will give you a straight answer.