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

TL;DR

• After the March 2026 core update, decay is the harshest I have seen. Sites that never prune are getting flattened, regardless of how clean their backlink profile looks.
• On average across my clients I delete or noindex 25-35% of indexed URLs in the first pruning pass. The traffic almost always goes up within 6-12 weeks.
• The Helpful Content System is alive. Google folded it into the core ranking system in March 2024, which means there is no "HCU recovery" anymore. It is just core ranking.
• The decision tree is four buckets: rewrite, redirect, noindex, delete. Pick one per URL. Do not invent a fifth.
• The "decay candidates" GSC query I run weekly: URLs with impressions in the trailing 16 months but fewer than 3 clicks in the last 28 days.
• One client thanked me for deleting 4,200 of their pages. Their CEO said it was the only SEO change in two years that moved revenue.
• Pruning is not about being ruthless. It is about being honest. Most pages I delete should never have been published.

The thank-you email that started this post

Last month a client emailed me with a subject line that said "thank you for the deletes". They run a 12-year-old SaaS blog with about 6,800 indexed URLs when I took them on. I deleted or noindexed 4,200 of them across three months. Their organic clicks went from a flat 14,000 a month to just over 19,000 in eight weeks. Their conversions tracked with that.

That email is not common. Clients rarely write to celebrate things being removed. But I have done some version of this exercise for every single SEO retainer I have run in the last two years, and the pattern is consistent. Pruning works. Especially now, after the spring 2026 update cycle, when ranking volatility is the highest it has been in years.

This post is the actual playbook. The GSC queries I run. The decision tree I follow per URL. The mistakes I have made (one of them cost a client a 700-visitor-per-month landing page that I was too quick to redirect). If you run an SEO retainer, manage a content team, or just have a blog that is older than three years and feels heavy, this is for you.

Why content pruning hits harder in 2026 than it did in 2022

I have been pruning content for clients since 2019, but the calculus changed in the last 18 months. Three things shifted.

The Helpful Content System is now part of the core algorithm. Google merged it into the core ranking system in March 2024 and confirmed it again across 2025 and 2026 updates. There is no separate "HCU recovery" path anymore. If your site has a lot of unhelpful pages, the whole domain carries the weight. Google's helpful content guidance{target="_blank" rel="noopener noreferrer"} explicitly tells site owners to "evaluate your content against these questions" and improve or remove what does not meet the bar.

The March 2026 core update{target="_blank" rel="noopener noreferrer"} ran for 12 days and 4 hours. That is one of the longer rollouts on record. The pattern I have seen across 18 client domains: sites with bloated archives lost ground. Sites that pruned in the six months before lost less, and several gained. I covered the winners and losers in detail, but the short version is that thin-content sites took the worst of it.

AI Overviews now strip clicks from anything informational that is not the absolute best answer. If a page used to bring in 200 visits a month for a definitional query and now brings in 12, the page is no longer earning its index slot. Pruning is the only sane response. Either rewrite to be the best answer, or get out of the way. I have written more about how AI citations skew toward the first 30% of content, and how that changes which pages are worth keeping.

The net effect: in 2026, doing nothing with old content is a more expensive choice than ever before. Pages that brought in trickle traffic in 2022 are now silently dragging the whole domain.

What "content pruning" actually means (and what it doesn't)

Content pruning is the process of reviewing every indexable URL on a site and assigning it to one of four buckets: rewrite, redirect, noindex, or delete. That is it. It is not a synonym for deletion. Half the pages in a good pruning audit get rewritten, not removed.

What it is not:

• Not a one-time cleanup. I run a light prune quarterly for every active client, and a deep prune once a year.
• Not just about thin content. Some of the worst offenders on a site are long, well-written posts that target a topic the site has no business ranking for.
• Not the same as "refresh your old posts". A refresh assumes the page should keep existing. A prune asks that question first.

If you only take one thing from this post: most sites I audit have 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 programs have been running for years without anyone asking whether the posts they published in 2019 are still worth the crawl budget.

The decay candidates GSC query I run every week

This is the query that does 80% of the work. I run it in Google Search Console for every client domain, weekly, and dump the results into a sheet for review.

The filter set:

1. Date range: last 16 months (the maximum GSC allows for the standard interface)
2. Compare: last 28 days vs the previous 28 days
3. Page filter: contains /blog/ (or whatever the content directory is)
4. Metric: clicks descending

Then I export and sort by a custom decay score. The formula:

decay_score = (clicks_28d_ago - clicks_now) / clicks_28d_ago

Any URL with a decay score above 0.6 (meaning it has lost more than 60% of its clicks) is a candidate. Any URL with fewer than 3 clicks in the last 28 days but more than 100 impressions over the trailing 16 months is also a candidate. These are pages Google has decided are worth showing but users do not want to click.

I usually pull this through the GSC Search Analytics API{target="_blank" rel="noopener noreferrer"} for sites over 5,000 URLs, because the UI tops out at 1,000 rows. The API lets me group by page and query dimensions and pull the full set in batches. For smaller sites, the export works fine.

A tip that took me embarrassingly long to figure out: GSC's UI deduplicates rows when you filter by page and query at the same time, which makes the export look smaller than reality. The API does not have this limit. If your site is over a few thousand URLs, use the API.

For the broader context on how to read your GSC data correctly, my guide to branded vs non-branded queries in GSC covers the filters most people get wrong.

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

Every candidate URL goes through this in order. The first "yes" wins.

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. Do not redirect, do not delete. Refresh the content from scratch if you have to. Keep the URL.

Signals a page is a rewrite candidate:

• It targets a commercial or high-intent keyword that still gets searched
• It has at least one referring domain worth keeping
• The topic is in your site's lane (i.e. you can actually claim expertise)
• The current version is just outdated, thin, or poorly structured

Rewriting is the most common bucket for SaaS and service businesses. About 50-60% of candidate URLs in my audits end up here. The trick is to rewrite hard, not just touch up. If you are only changing the dates and a few sentences, the page will decay again in six months. I usually budget the same time per rewrite as a fresh post, because that is what it takes.

A strong rewrite needs proper on-page SEO structure, real first-hand experience signals from the E-E-A-T playbook, and a clear primary query the page is built 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 redirect. Pick the redirect target carefully. Google has been more aggressive about treating off-topic redirects as soft 404s since 2022. If you redirect a post about "best CRM for plumbers" to your homepage, Google may simply ignore the link equity.

Good redirect targets:

• A pillar page or hub that covers the same broader topic
• A more recent post that updates or supersedes the old one
• A service or product page that matches the search intent

Bad redirect targets:

• The homepage (almost always treated as a soft 404)
• An unrelated category page
• Anything that does not visibly cover the original query

I usually redirect 15-20% of candidate URLs. Always 301, never 302. Always to a topically close page. And I always check the original URL had at least one referring domain or a measurable trickle of traffic. If the URL had zero of both, do not redirect, just delete. Redirects add server overhead and complicate future audits.

Bucket 3: Noindex

Ask: does this URL need to exist for users (legal, internal navigation, support), but it should not appear in search?

If yes, add a noindex meta robots tag and keep the page live. Google's own removal documentation{target="_blank" rel="noopener noreferrer"} lists noindex as the preferred method when you want the page reachable but invisible to search.

Common noindex candidates:

• Author archives that have no content beyond a bio
• Tag pages with fewer than 4-5 posts
• Internal search results pages
• Thank-you pages, confirmation pages
• Legal pages that need to exist but do not need to rank
• Old event pages that customers occasionally still need

Noindex is the bucket most marketing teams forget exists. They either delete things that should stay live or they leave them indexed when they should not be. The 2.4 million-page indexation issues you see on big sites are almost always one of these two mistakes at scale.

Do not combine noindex with a robots.txt block on the same URL. Googlebot needs to be able to crawl the page to see the noindex tag. Block the crawl and Google will keep the URL indexed for months, just without a description.

Bucket 4: Delete

Ask: does this URL have no traffic, no backlinks, no internal demand, and no business reason to exist?

If yes, return a 410 status code. Not a 404. The distinction matters.

• 404 Not Found tells Google the URL is missing, which Google interprets as "come back and check again". The URL can linger in the index for months.
• 410 Gone tells Google the URL is permanently removed. Google drops it from the index much faster.

For a deep prune, I configure the server to return 410 for the deleted URL paths. On WordPress, the easiest way is a small plugin (the "410 for WordPress" type) or a few lines in the .htaccess or Nginx config. On Webflow, Squarespace, and Shopify the options are more limited and you usually fall back to a 404 plus removing the URL from the sitemap.

Delete bucket sizes vary by site age. On a 10+ year old blog, I have deleted 40-50% of indexed URLs. On a 3-year-old SaaS blog, more like 10-15%.

For the broader technical context on how Google crawls and indexes these signals, the technical SEO fundamentals guide covers crawl budget, indexation, and how 410s flow through the pipeline.

Mistakes I have made (so you don't have to)

I am going to be honest here because the standard "how to prune" post pretends this is a clean exercise. It is not.

The redirect-everything-to-the-homepage mistake. Early in my career I redirected about 300 obsolete blog posts to a client's homepage. Within three weeks Google had treated almost all of them as soft 404s. The link equity I thought I was preserving was gone. The lesson: a redirect that does not match user intent is the same as a delete, just with more server load.

The 700-visitor-per-month landing page I killed. I redirected an old comparison page on a SaaS client because it looked thin in our audit sheet. The page only had 400 words but it was ranking position 3 for a niche term and bringing in 700 monthly visits. I had not segmented the export by traffic before making the call. I always do now. Any URL bringing in more than 50 monthly visits gets manually reviewed, no matter how it scores on automated thinness checks.

The over-aggressive noindex pass. On another client I noindexed all tag pages with fewer than 10 posts. I should have noindexed only the ones with fewer than 4. We lost a decent chunk of long-tail rankings from tags that were actually useful entry points. Restoring them took a month for Google to fully re-crawl and reinstate.

Not warning the dev team about 410s. A client's dev team saw a spike of 410s in their monitoring and rolled back the deletes thinking it was a bug. The whole prune got reverted. Now I always brief the dev team in advance and label the 410 pages clearly in the changelog.

Mistakes I have made are a recurring theme on this blog. The case study from nashbio's 90-day climb is a good example of what going slow and methodical looks like in practice.

A worked example: how I pruned 4,200 pages from a SaaS blog

Let me walk through the actual project that prompted that thank-you email.

The client: B2B SaaS, 12-year-old domain, 6,800 indexed URLs in the blog directory, mostly published between 2014 and 2021. Organic traffic had been flat for two years and had dipped about 14% after the August 2025 helpful content alignment.

Week 1: Audit and segment.

I pulled the full URL list through the GSC API plus a Screaming Frog crawl, joined it with Ahrefs referring domain data, and built a sheet with the following columns per URL: clicks last 16 months, clicks last 28 days, impressions last 28 days, referring domains, internal links pointing in, word count, last modified date, top organic query, and intent type (informational, commercial, brand, off-topic).

Week 2: Decision pass.

Went through every URL and tagged it as rewrite, redirect, noindex, or delete. The split:

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

The high delete share is typical for older blogs where editorial standards drifted. About 2,800 of those deletes were product update posts from 2014-2018 that referred to product features that no longer existed.

Week 3-4: Execute deletes and noindex first.

Deletes went out in three batches of about 1,300 URLs each, separated by 48 hours. The dev team configured 410 responses and removed the URLs from the XML sitemap. The noindex batch went out in one push. I monitored Search Console daily for crawl error spikes and indexation drops.

Week 5-8: Redirects and rewrites.

Redirects went out in batches mapped to topical clusters. Rewrites were prioritised by current impressions, with the highest-impression decay candidates rewritten first. We got through about 200 rewrites in the first 8 weeks and continued at a pace of 50 per month after.

Result at 8 weeks.

Organic clicks moved from a flat 14,000 a month to 19,200. Conversions tracked with that, up about 31%. The client's CEO sent the thank-you email. Their internal team had been pushing for more content production for two years. The exercise proved the opposite was the lever.

Not every prune produces a 38% lift. I have had some come in flat for the first 12 weeks and then climb. I have had a couple where the gains were closer to 8-12%. But I have not yet run a deep prune on an aged site that lost traffic over a 12-week window. The downside risk is very low if you are careful with redirects.

How AI search changes the pruning calculus

A pattern I have started seeing in late 2025 and into 2026: pages that used to be safe "long-tail trickle" assets are now zero-click candidates because AI Overviews and ChatGPT answers are eating the informational queries.

What used to be an okay page is now a pruning candidate purely because the click yield has collapsed even though impressions are stable. I check this by looking at the impressions-to-clicks ratio over time. If a page had a 6% CTR in 2023 and a 0.4% CTR in 2026 for the same queries, the value of keeping it indexed has dropped close to zero. Unless I can rewrite it to be cited as a source in AI answers, it goes.

My framework for the AI angle:

• Rewrite as an LLM citation target if the page targets a query that AI is summarising and you can be the canonical source. The LLM optimisation playbook covers what citation-ready content looks like.
• Delete or noindex if the page targets pure definitional queries that are now answered above the fold by AI and you have no realistic chance of being the cited source.
• Consolidate if you have 3+ pages on the same topic that fragment your authority. Pick the strongest, merge the value, redirect the rest.

This is a meaningful shift. In 2022 you would keep almost anything that brought in 30 monthly visits. In 2026 that same page might be a net negative on the domain because it is dragging down the perceived helpfulness score and bringing in users who immediately bounce.

Tools and signals I trust (and the ones I ignore)

Trust:

• Google Search Console (the source of truth for impressions, clicks, and indexation status)
• Screaming Frog for crawl-level data (status codes, canonical chains, redirect maps)
• Ahrefs or Semrush for referring domain counts per URL
• The Internet Archive Wayback Machine{target="_blank" rel="noopener noreferrer"} to check what a page looked like at past snapshots, especially before any major drops
• Google's own Search Quality Rater Guidelines{target="_blank" rel="noopener noreferrer"} as the closest thing to a rubric for what "low quality" actually means to Google. The September 2025 update added explicit AI Overview evaluation criteria, which is worth a read.

Ignore:

• Generic "content score" numbers from SEO suites without context. They tend to flag well-performing pages as thin because they only count word count and keyword density.
• AI-generated "audit summaries" that recommend deletion without showing the underlying data. I have seen these recommend deleting pages that were a client's top-converting blog posts.
• Any tool that suggests pruning based purely on page age. Age is not a signal of quality. Some of my best-performing client pages are 8 years old.

For more on the tools and where they help versus hurt, the technical SEO audit checklist for SaaS teams breaks down what to use when.

What to do this week (numbered action plan)

If you have been putting off a content audit, here is the smallest useful first step. You can do this in an afternoon.

1. Open Google Search Console and export the last 16 months of page-level performance for your blog directory. Filter to /blog/ or wherever your content lives.
2. Open the file in a sheet. Add a column for clicks per month (clicks divided by 16).
3. Sort ascending. Look at every URL with fewer than 3 clicks per month over the last 16 months. Count them.
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 URLs. Open each one. Tag them as rewrite, redirect, noindex, or delete using the decision tree above.
6. Pick the 10 clearest delete candidates (no backlinks, no traffic, off-topic, obsolete). Return 410s for those URLs. Remove them from the sitemap.
7. Wait 4 weeks. Check GSC for any unexpected impressions drops on other pages.
8. If nothing bad happened, repeat with the next 50. Then the next 100. Build the muscle before doing the full audit.

For sites coming off the March 2026 cycle, this is the single highest-leverage move you can make right now. Combine it with a proper core update recovery plan and you have a real shot at recovering ground before the next rollout.

If you want me to look at your blog and tell you roughly what percentage of your indexed URLs are pruning candidates, the free SEO audit covers it. Or if you would rather have me run the whole exercise as part of an SEO retainer, the services page has the details.

Pruning is not glamorous. It does not make a great LinkedIn post. But it has been the single most reliable lever I have for moving traffic on aged sites, and the spring 2026 update cycle has only made that more true. Most blogs do not need more posts. They need fewer, better ones.