You audit your content and half of it is 3+ years old. Many articles reference tools that have since changed radically: “ChatGPT” guides from the GPT-3.5 era, “Vercel deployment” walkthroughs with a UI that no longer exists, “Tailwind v2” tutorials when v4 is current. They still rank, some still pull traffic, but readers click, see outdated info, and bounce.
Fastest fix: rank your URLs by monthly impressions ÷ months since last real edit, then do a substantive refresh on the top 20 (update the stale facts in the body, not just the date). One published-content study of 50K+ pages found refreshed pages produced 268% organic click growth versus 22% for brand-new pages, and content refreshes routinely return more per hour than net-new writing. The catch: it has to be a real refresh. As of June 2026, Google’s December 2025 core update specifically demoted “fake freshness” (a bumped dateModified over an unchanged body), and AI Overviews and ChatGPT read the actual body text, not your metadata.
Why this happens
Ordered by hit rate, highest first.
| # | Cause | Fastest way to confirm |
|---|---|---|
| 1 | Editorial focus shifted to publishing new, not refreshing old | Editorial calendar is ~90% new / 10% refresh; nobody tracks a refresh count |
| 2 | No system to identify which articles are stale | Ask “which articles need refreshing?” and the only answer is “I’d have to read them all” |
| 3 | Old articles still rank, so they feel “fine” | Search Console: many 18-month-old URLs cluster at positions 6-15 with low CTR |
| 4 | Refreshes are seen as boring maintenance | The “interesting work” backlog is full; the maintenance backlog is empty or stagnant |
| 5 | Fear of breaking a page that ranks | URLs with real traffic, untouched for 24+ months, preserved by “don’t touch it” |
| 6 | A date-bump script was tried and backfired | Many pages have a dateModified newer than their last real git edit, with no CTR gain |
1. Editorial focus shifted to publishing new instead of refreshing old
Shipping new articles feels productive; refreshing feels like going backward. The dashboard counts published posts, so that is what the team optimizes. Compare your new-to-refresh ratio against a mature publisher’s — many run closer to 50/50, or weight toward refresh once the library is large.
2. No system to identify what needs refreshing
With 300 articles you cannot re-read all of them every quarter, and without tooling there is no way to surface “these specific URLs are stale.” This is the one cause worth fixing with code (Step 6 below) because it makes every other fix repeatable.
3. Older articles still rank, so they feel “fine”
A page on page one feels healthy. But position 8 at ~1.2% CTR versus position 4 at ~6% CTR is a large gap in clicks for the same query. “Still ranking” hides the opportunity cost. There is also a newer cost: pages that go 90+ days without a substantive update see roughly a 40-60% drop in AI citation rates, and AI Overviews (powered by Gemini 3 by default since January 2026) plus ChatGPT skew their citations toward recently updated pages.
4. Refreshes are perceived as boring
Authors prefer writing new things. Re-screenshotting, fact-checking, and fixing dead links read as maintenance, so without an explicit assignment they never happen and refresh work goes underground.
5. Fear of breaking what’s working
“This ranks well — what if I change it and lose the ranking?” Usually the opposite happens: a substantive refresh on the same URL keeps the backlinks, history, and topical signals and typically improves position. You lose ranking by making the page worse or by changing the URL, not by improving the content.
6. Date-bump tricks were tried and discounted
Someone ran a script to set every dateModified to today. CTR didn’t move, and on recency-sensitive queries it may have hurt. As of June 2026 this is a documented anti-pattern: Google measures the magnitude of the content change, and a new timestamp over a near-identical body is ignored at best and treated as a deceptive trust signal at worst (site-wide patterns can draw a manual action). The burnout from that experiment is now blocking real refreshes.
Shortest path to fix
Ordered by ROI. Step 1 prioritizes; Steps 2-4 refresh correctly; Steps 5-6 make it a system.
Step 1: Sort by traffic ÷ age and refresh the high-value stale pages
For each article:
- monthly impressions (Search Console, last 3 months)
- months_since_last_real_edit (git log, not dateModified)
- refresh_value = impressions / months_since_last_real_edit
Sort descending. Top 20 are your highest-value refresh candidates.A 2-year-old page with 5,000 monthly impressions outranks a 4-year-old page with 500 as a candidate. In Search Console, use the Compare date-range mode (for example last 3 months vs the prior 3 months, or year-over-year) and sort by impression or click decline to spot decaying pages fast. Queries sitting at positions 8-20 are the classic quick-win refresh targets.
Step 2: For each candidate, do a real refresh
A real refresh means the body now describes the current state of the topic — that is what both Google’s crawler and AI extraction pipelines actually read:
1. Read the article and list every claim that is now wrong or outdated
2. Update screenshots where the UI changed
3. Update version numbers and pricing (the most commonly stale facts)
4. Fix example links that 404 or moved; update internal links to current URLs
5. Replace any dated statistics — a 2023 stat under a "2026 update" badge is a red flag
6. Add 1-2 new examples or data points from the current product/state
7. Rewrite the conclusion if the recommendation actually changedPlan 1-2 hours per refresh. If a “refresh” takes 10 minutes, the body didn’t change enough to earn a fresher date.
Step 3: Update the date honestly — and keep visible and schema dates consistent
---
title: "..."
publishedAt: 2023-08-15 # original date, preserved
lastModified: 2026-06-21 # real edit date, today
---Google cross-references your visible byline date, the datePublished/dateModified in your Article schema, the sitemap lastmod, and its own crawl history, then picks the date it trusts. Keep these consistent: the visible “Updated” date and the schema dateModified should match, and your sitemap lastmod should fire only on meaningful edits, not on every trivial commit. Conflicting signals are what break date selection — one site that displayed both a publish and an updated date saw Google keep showing the old 2021 publish date in the SERP and lost about 22% of its CTR. If Google keeps surfacing the wrong date, reduce the number of competing dates on the page rather than adding more.
Step 4: Make the refresh visible
Add one short change-note near the top:
> **Updated June 2026:** rewrote the pricing section for the latest plans,
> replaced the old dashboard screenshots, added a section on the v4 features.This tells readers what changed and gives Google’s content-change detection a clear, honest signal. Keep it specific (“rewrote the pricing section”) rather than a generic “Updated for 2026” badge, which on its own is exactly the pattern the December 2025 core update targeted.
Step 5: Schedule recurring refresh cycles
- Top 20 by traffic -> every 6-12 months
- Top 50 -> every 12-18 months
- Long tail -> every 36 months, or retire / leave evergreen alone
- Tool / UI articles -> refresh when the platform redesigns, not on a fixed clockThe top-tier cadence tightened in 2026 because AI search rewards recency: most of ChatGPT’s frequently-cited pages were updated within the last ~30 days, and citation rates fall off sharply past 90 days. Put these on a calendar; unscheduled refreshes don’t happen. Evergreen pages that genuinely don’t need touching should be left alone — editing for the sake of a date is wasted effort.
Step 6: Build a “stale check” into quarterly audits
# scripts/audit-stale.mjs — surface the refresh queue automatically
# Flag an article when ALL of:
# - last real git edit > 18 months ago
# - has any Search Console impressions in the last 90 days
# - mentions a fast-moving tool/platform (ChatGPT, Cursor, Vercel,
# Tailwind, Gemini, Next.js, ...) from a watchlist
# Output the list, sorted by refresh_value, as the quarterly refresh queue.A quarterly cadence plus a visible, ranked queue turns refreshing from accidental into systematic. Base the age on the real git edit date, not dateModified, so a past date-bump can’t hide a stale page from the audit.
How to confirm it worked
- Date selection: search
site:yourdomain.com <article title>and confirm the SERP shows the new “Updated” date, not the old publish date. If it still shows the old one, your dates are conflicting (revisit Step 3). - Rankings: in Search Console’s Compare view, watch the refreshed URL’s average position and CTR over the 4-8 weeks after the edit. A real refresh on a position 6-15 page typically moves it up within a crawl cycle or two.
- Re-crawl: use the URL Inspection tool to confirm Google has re-crawled the page since your edit; “Request indexing” if it hasn’t picked it up after a few days.
Prevention
- Refresh cadence by traffic tier: top 20 every 6-12 months, top 50 every 12-18 months.
- Real refreshes only — a date bump over an unchanged body is detected and discounted, and risks a trust hit.
- Keep the refresh queue in your quarterly audit; visibility removes the “fear of breaking it” excuse.
- For tool/UI articles, trigger refreshes off platform redesigns, not the calendar.
- Track refresh count as an editorial KPI alongside new-article count.
- Refresh on the same URL — the backlinks and history are the equity a new URL throws away.
Related
Tags: #Content ops #Site quality #Site audit #Troubleshooting #Stale content