---
title: "Content Pruning for AI: What to Delete, Redirect or Refresh"
url: https://hostmy.blog/content-pruning-for-ai/
date: 2026-09-20
modified: 2026-09-07
lang: en
author: "Aditya Sharma"
description: "Stale pages are roughly 3x more likely to lose citations. Here is the decision table for every old post on your blog."
categories:
  - "AI Search"
image: https://hostmy.blog/wp-content/uploads/2026/09/hmb-card-1881-1024x538.jpg
word_count: 1451
---

# Content Pruning for AI: What to Delete, Redirect or Refresh

Stale pages are roughly 3 times more likely to lose citations. The median cited page across 153,425 citations was 298 days old, and 61.9 percent of dated cited pages came from 2025 or 2026.

Read those two facts together and the target becomes specific. Not brand new, and not abandoned. Roughly ten months old and demonstrably maintained.

Most blogs with four years of archives have three hundred posts sitting well outside that band. Every one of them is a delete, a redirect, a refresh, or a deliberate leave-alone. This is how to sort them.

## Get the list before you get opinions

Everything below runs on one export. WP-CLI on the server, or a CSV out of your database.

`wp post list --post_type=post --post_status=publish \
--fields=ID,post_date,post_modified,post_name,post_title \
--format=csv --posts_per_page=-1 > posts.csv`

Sort by `post_modified` ascending and the oldest untouched content rises to the top. Without server access, [ranking the whole archive by staleness through the REST API](/find-stale-posts/) produces the same list.

`sort -t, -k3 posts.csv | head -50`

Add two columns by hand or from analytics: sessions in the last twelve months, and whether the post has any external links pointing at it. Four columns is enough to make every decision on this page.

Four outcomes, first match wins

Four outcomes, first match wins

No traffic, no links, covered better elsewhere
redirect to the better page

No traffic, no links, topic dead
delete, return 410

Traffic or links, factually out of date
refresh properly, update dateModified

Traffic, links, still accurate
leave it alone

The fourth row exists to stop the audit turning into busywork. A page that is still correct does not need editing to prove it is alive.

## The decision table, four outcomes and no fifth

Run each row through this in order. The first matching row wins.

| Condition | Action | Why |
| --------- | ------ | --- |
| No traffic, no links, topic covered better elsewhere on your site | Redirect to the better page | Consolidates the signal, keeps any residual value |
| No traffic, no links, topic dead and not covered elsewhere | Delete, return 410 | Nothing to preserve, and it dilutes the site |
| Traffic or links, but factually out of date | Refresh properly, update dateModified | This is where the 3x stale penalty applies |
| Traffic, links, and still accurate | Leave alone | An unchanged correct page is not a problem |

The fourth row exists to stop the exercise turning into busywork. A page that is right does not need editing to prove it is alive, which is the same line drawn in [the line between a real update and a date bump](/content-freshness-ai-answers/).

The third row is where nearly all the value is, and it is also where the temptation to cheat lives.

## A date bump without an edit is a lie in a machine-readable format

The stale finding tempts people into a nightly `dateModified` refresh across the whole archive. Do not do it.

The signal being sent is a claim about your own content, expressed in JSON-LD, that the content changed. Making that claim falsely on three hundred pages is a different order of problem from an overenthusiastic meta description, because it is structured data that other systems parse as fact.

There is also a practical reason. If every page on the site claims it changed yesterday, the field carries no information about any page. You have spent the signal.

Update the date when the words changed. The schema fields that make this readable are in [Article, Speakable and FAQPage in practice](/schema-markup-guide-ai/).

## A real refresh changes the first third of the page

41.9 percent of citations came from the first 30 percent of the page. The mean cited position in that set of 9,968 cited sentences was 37 percent down.

So a refresh that adds two paragraphs to the conclusion has updated the part of the page least likely to be read. Work in the opening instead.

Three edits, in this order.

First, put the answer in the opening. Whatever question the page exists to answer, answer it in the first two paragraphs and then explain.

Second, get the claim sentence under the ceiling. Mean cited sentence length was 9.27 words, median 10, and [no sentence longer than 18 words was cited once](/18-word-ceiling/) in the whole set. The 6 to 10 band carried 45.2 percent. Split any 28 word opening claim into a short claim and a separate qualification.

Third, fix the facts that went out of date, and say in the post that they were checked. A date without a visible change reads as maintenance theatre to a human reader even when the schema is honest.

## Heading structure is worth fixing while the file is open

Sequential headings, H2 then H3 without skipping a level, showed a 2.8x lift.

Old posts are usually where the structure went wrong, because they were written before the site had a template. H3s used as visual emphasis, an H4 with no H3 above it, two H1s.

Resist the urge to add more of them. Reordering the existing headings costs nothing and adding six new ones has a measured price.

## Deleting is a real option and 410 is the honest status

A post with no traffic, no links and no unique information is not an asset. Redirecting it to a vaguely related page to preserve some imagined value creates a redirect that points somewhere the visitor did not want.

Return 410 Gone when the content is genuinely gone with no successor. Redirect only when there is a real successor covering the same question.

`curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/old-post/`

Check the outcome after you act. A 404 where you meant 410 is survivable. A 200 on a page you thought you deleted is not.

## Freshness does not substitute for being reachable

None of this matters on a page an agent cannot fetch.

Measured on our own infrastructure, a site returned 429 to GPTBot while its robots.txt said Allow, reproduced 3 times out of 3, with the block sitting at the web server layer because static assets were refused too while robots.txt and the sitemap returned 200. A refresh programme on a site in that state is effort spent behind a closed door.

Check first, then prune. The command sequence is in [four gates, in the order that matters](/ai-seo-checker-curl/), and the full request chain is in [each hop from prompt to fetch to cited line](/ai-crawlers-request-by-request/).

## Expect the pruned set to look nothing like your top rankers

Only 23.05 percent of cited URLs ranked in the organic top ten. For ChatGPT the figure was 4.2 percent. Ahrefs, looking at 863,000 keywords, found AI Overview citations from top-10 pages fell from 76 percent to 38 percent.

So the pages worth refreshing are not automatically the ones at the top of your Search Console report. Include the mid-table pages that answer a specific question completely, because those are the shape the citation data keeps rewarding.

Homepages sit at about 4 percent of citations, which is the argument for leaving the front page out of this exercise entirely. The reasoning is in [why the front page is the weakest candidate](/homepage-wrong-page-for-ai/).

One more sorting signal is worth adding to the spreadsheet: readability, broken down in full in [the four checks an assistant runs before quoting you](/ai-seo-checker-curl/). Old posts written in a smoothed magazine register sit in the thinnest cited band, and rewriting one of those plainly is often a bigger change than updating its facts.

## A pace that is sustainable

Three hundred posts is not a weekend. Ten a week, steadily, is.

Do the deletes and redirects first, because they are fast and they shrink the problem. Then refresh in order of traffic, highest first, so the work compounds while you are still enthusiastic about it.

Keep a note of what you changed and when. Six months from now the question "did this page get a real edit or just a date bump" needs an answer you can trust.

## Where the plugin helps

What RankReady will not do is decide which posts deserve a refresh, that judgement is yours, and it is the part of this work that cannot be automated honestly.

What it does handle is the freshness signals the exercise depends on: `datePublished` and `dateModified` in Article schema tied to real edits, an author box, Markdown versions of your posts, robots.txt with Content Signals, and llms.txt if you want one. Setup is about five minutes, alongside whichever of Rank Math, Yoast, AIOSEO or SEOPress already owns your titles, meta descriptions and sitemap. It is on [the WordPress.org directory](https://wordpress.org/plugins/rankready-ai-llm-seo/).

## The question that makes the list shorter

Open your export and sort by last modified. Look at the fifty oldest.

For each one, ask whether you would send a new reader to it today. How many survive that question, and what have the rest been doing on your site for the last three years?