---
title: "Content Freshness for AI Answers: What to Update and What to Leave Alone"
url: https://hostmy.blog/content-freshness-ai-answers/
date: 2026-09-15
modified: 2026-09-03
lang: en
author: "Aditya Sharma"
description: "The median cited page is 298 days old. Age is not the problem, neglect is. Here is the triage, with commands to find your stale pages."
categories:
  - "RankReady"
image: https://hostmy.blog/wp-content/uploads/2026/09/hmb-card-1867-1024x538.jpg
word_count: 1386
---

# Content Freshness for AI Answers: What to Update and What to Leave Alone

The median cited page is 298 days old. Roughly ten months.

Read that before you plan another quarter of new posts. The pages being quoted are not the ones published on Tuesday.

The second number is the one that changes behaviour. Stale pages are roughly three times more likely to lose citations they already held. Age is fine. Neglect is expensive. Those two findings sit together, and most content calendars get both of them backwards.

## Old is good, untouched is not

Put the two findings side by side and a maintenance rule falls out.

| Page state | Position |
| ---------- | -------- |
| Published last week | Too new to have accumulated anything |
| Published 10 months ago, updated since | The strongest position of the four |
| Published 10 months ago, never touched | Losing what it had, at roughly 3x the rate |
| Republished with a new date, unchanged content | A date change with nothing behind it |

The fourth row is the one people reach for, because it is the cheapest. Bulk-updating `dateModified` across an archive takes one query and changes nothing about the page. Nothing on the page improved, and now your one honest signal about maintenance is noise.

The rule is simpler than a calendar. Fewer new posts, more real revisits.

## Find your stale pages before you decide anything

Start from the sitemap rather than from memory, which is the whole idea behind [finding the stale posts before an assistant stops citing them](/find-stale-posts/). Your instinct about which pages are old is usually wrong by a year.

`curl -s https://yoursite.com/post-sitemap.xml -o /tmp/sm.xml

python3 - <<'PY'
import re, datetime
xml = open('/tmp/sm.xml').read()
rows = re.findall(r'<url>.*?<loc>(.*?)</loc>\s*(?:<lastmod>(.*?)</lastmod>)?.*?</url>', xml, re.S)
today = datetime.date.today()
out = []
for loc, mod in rows:
if not mod:
out.append((9999, loc, 'no lastmod')); continue
d = datetime.date.fromisoformat(mod[:10])
out.append(((today - d).days, loc, mod[:10]))
for days, loc, mod in sorted(out, reverse=True)[:25]:
label = 'never' if days == 9999 else f'{days}d'
print(f'{label:>7} {mod:<12} {loc}')
PY`

That prints your 25 most neglected URLs, oldest first. Anything past roughly 400 days with real traffic goes on the list.

Then check what a single page claims about itself:

`curl -s https://yoursite.com/your-post/ | grep -o '"date\(Published\|Modified\)":"[^"]*"'`

Two identical timestamps on a two year old post means either nothing has changed or your theme never passes the modified date through. Those have different fixes, and you should know which one you have.

If every page in your sitemap shares one identical `lastmod`, something in your build is stamping the whole archive on deploy. That field is currently telling nobody anything:

`curl -s https://yoursite.com/post-sitemap.xml \
| grep -o '<lastmod>[^<]*</lastmod>' | sed 's/<[^>]*>//g' \
| cut -c1-10 | sort | uniq -c | sort -rn | head`

## Update these four things

A real update changes what the page says. Four categories cover almost all of it.

**Anything with a date attached to it.** Version numbers, pricing, product names, screenshots of interfaces that have since been redesigned, and statistics with a year in them. These decay on a schedule you can predict.

`curl -s https://yoursite.com/your-post/ | grep -oE '\b20(1[0-9]|2[0-6])\b' | sort | uniq -c | sort -rn`

Any year older than about two is worth reading in context.

**Dead outbound links.** A page pointing at four 404s reads as abandoned to a human and to a parser.

`curl -s https://yoursite.com/your-post/ \
| grep -oE 'href="https?://[^"]+"' | sed 's/href="//; s/"$//' \
| sort -u | while read -r u; do
printf '%s %s\n' "$(curl -s -o /dev/null -w '%{http_code}' -L --max-time 8 "$u")" "$u"
done | grep -v '^200'`

**The first 30 percent of the page.** 41.9 percent of AI citations come from that opening span. If the update pass touches one section, make it that one. Put the direct answer near the top, and get those sentences under [the 18 word ceiling](/18-word-ceiling/), because nothing longer than 18 words was cited once across 11,346 cited sentences. The method is in [the rewrite moves that shorten a claim](/write-sentences-ai-can-quote/).

**Claims that are no longer true.** The most valuable edit on any old post is deleting a paragraph that was correct in 2024. Removal is an update.

## Leave these four things alone

Equally important, and less often said.

**The URL.** Changing a slug to look fresher throws away every link and every reference the page has accumulated. There is no version of this that pays.

**The published date.** Age is not the problem. A visible `datePublished` from 2024 alongside a `dateModified` from last month is the exact signal you want to be sending. Hiding the publish date hides the good half of the story.

**Evergreen mechanics.** How robots.txt group matching works has not changed and will not. Rewriting a correct explanation to feel current adds risk and no value.

**Structure that already works.** Resist the urge to add headings during an update pass. A page that grows from eight sections to sixteen has not automatically improved. Fix heading order if it skips levels, since sequential order carries a 2.8x lift, then stop.

Age is not the problem, wrong facts are

Age is not the problem, wrong facts are

Published
day 0

Median cited page
age
298 days

Facts inside go
stale
versions, prices, counts

Date bumped, nothing
edited
a machine-readable lie
Time since publication

The median cited page was already 298 days old, so republishing on a schedule buys nothing. What ages badly is the version number inside the page.

## A cadence you can actually keep

The failure mode of update advice is a plan requiring a full day per month that survives two months.

| Frequency | Task | Time |
| --------- | ---- | ---- |
| Monthly | Run the sitemap script, look at the top 10 stale URLs | 5 minutes |
| Monthly | Real update pass on the single highest traffic stale page | 45 minutes |
| Quarterly | Dead link sweep across the top 25 pages | 20 minutes |
| Quarterly | Confirm `dateModified` is moving when you publish edits | 5 minutes |
| Yearly | Delete or merge posts nobody reads and nobody links | 2 hours |

One real update a month beats twelve date changes. The last row is the one people skip and the one that helps most, because a thin archive dilutes everything around it, and [deciding what to delete, redirect or refresh](/content-pruning-for-ai/) is a separate call from deciding what to update.

## Make dateModified honest before anything else

None of the above works if the field lying underneath it is wrong.

Three things break `dateModified` on WordPress. A theme that hardcodes the published date into the schema. An SEO plugin option that suppresses the modified date to avoid looking stale, which is a setting that exists and is exactly backwards. And a caching layer serving markup generated before your last edit.

Check after you edit a post, not before:

`curl -s "https://yoursite.com/your-post/?nocache=$(date +%s)" | grep -o '"dateModified":"[^"]*"'`

If that timestamp does not move after a real edit, fix that before planning any content work. Everything in this post assumes the field reflects reality.

## The five minute version on WordPress

Keeping `dateModified` accurate in the schema, keeping the sitemap `lastmod` in step with it, and regenerating the machine readable copies of a page when its content changes is plumbing, one slice of [AI search work translated into ordinary WordPress jobs](/ai-search-optimization-wordpress/). It is repetitive, it fails silently, and it is the part that quietly undoes an update pass you actually did.

That set is what [RankReady](https://wordpress.org/plugins/rankready-ai-llm-seo/) keeps in sync. It is a WordPress AI SEO plugin that runs alongside Rank Math, Yoast, AIOSEO or SEOPress rather than replacing them, and setup takes about five minutes. Your SEO plugin keeps writing the pages it already owns.

What that maintains is crawlability and an honest freshness signal. Whether an assistant then keeps citing a refreshed page is not something a plugin can promise, and the vendors promising it are guessing.

## Start with your ten oldest pages

Run the sitemap script at the top of this post. Take the ten oldest URLs, cross reference them against your traffic, and pick the single page that is both old and still earning.

Update that one properly. Rewrite the opening, fix the dead links, cut what is no longer true, and leave the URL and the publish date exactly where they are.

Then check the crawler side, because a beautifully updated page that returns 403 to every AI crawler helps nobody. That check is layer one of [the same sweep taken end to end](/five-layer-ai-seo-audit/), and the crawler rules behind it are in [per crawler rules, and the syntax that undoes them](/block-ai-crawlers-robots-txt/).

When did you last update a post rather than replace it, and can you name the page?