Content Refresh & Decay

Every page you publish starts losing ground the day it goes live. Competitors publish better versions, Google changes what the results page looks like, searchers want something slightly different, and your facts quietly go out of date. That slow slide is content decay, and on a mature site, catching it is often higher-return work than publishing something new (our view, based on how much existing pages already have going for them: links, history, rankings).

This guide is the maintenance half of the on-page module. Its partner, Content Pruning, covers what to remove.

What decay looks like#

Decay has four common causes, and each leaves a different fingerprint in Search Console:

Two things look like decay but aren't. Seasonality: compare year over year, not month over month, for anything seasonal. Data breaks: see the warning below.

Finding decay in Search Console#

1. Open Performance > Search results, click the date filter and choose Compare. Use the last 3 months against the same 3 months a year earlier.
2. Switch to the Pages tab and sort by the clicks difference. Your biggest losers are at the top.
3. Click a page, then the Queries tab, to see exactly which queries lost clicks or position.
4. Check Insights > Query groups if your property has it (added October 2025): groups "trending down" surface whole topics losing interest.

For the AI Overview curve, open the Generative AI performance report (available to all sites since August 31, 2026). It shows impressions in AI Overviews and AI Mode by page, but no clicks or queries, so pair it with a manual look at the live results. More in SEO for AI Mode & AI Overviews.

Diagnose before you touch anything#

For each decaying page, open the current top five results for its main query and answer four questions:

• What do they have that you don't? New data, a tool, a video, a clearer table, first-hand testing.
• Has the format changed? If page one turned from guides into comparison pages, a refresh of your guide won't fix it.
• What's wrong on your page? Dead links, old screenshots, retired features, prices, version numbers, years.
• Is a sibling page competing? Two of your URLs swapping places for the same query is cannibalization, not decay.

Refresh, rewrite, consolidate or prune#

Does the page still target a query people search and you can win?
├─ No  → Does it have links or traffic worth keeping?
│        ├─ Yes → CONSOLIDATE into the closest live page (301)
│        └─ No  → PRUNE (404/410, or noindex if it must stay)
└─ Yes → Does another page of yours target the same intent?
         ├─ Yes → CONSOLIDATE into the stronger URL
         └─ No  → Does the current format still match the SERP?
                  ├─ No  → REWRITE (new structure, same URL)
                  └─ Yes → REFRESH (update facts, add what's missing)

• Refresh: same structure, updated substance. The most common outcome.
• Rewrite: the intent or format changed, so the page needs a new structure. Keep the URL so it keeps its links and history.
• Consolidate and prune: covered step by step in Content Pruning.

What counts as a substantive update#

A real refresh changes what the reader gets. Good refreshes usually include several of these:

• Correcting facts, figures, prices and version numbers, with dated sources
• Replacing screenshots and code that no longer match the product
• Adding a section for a subtopic the current top results cover and you don't
• Adding something non-commodity: your own data, a test, a worked example
• Removing advice that is now wrong (and saying so, if readers relied on it)
• Tightening the opening so the answer comes first
• Updating internal links, including from newer related posts to this one (Internal Linking)
• Updating the title and meta description if the promise changed (check them in the SERP preview tool)

What doesn't count: changing the year in the title, swapping synonyms, reordering paragraphs, or adding 300 words of filler.

Dates, done honestly#

Google's helpful content guidance includes this self-check: "Are you changing the date of pages to make them seem fresh when the content has not substantially changed?" Date bumping is a known tactic, it's named as something to avoid, and it costs readers' trust when they find a "2026" page with 2023 screenshots.

Google's date documentation asks for a visible, labeled date ("Published" or "Last updated") and structured data with datePublished and dateModified, kept consistent with each other.

const jsonLd = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  headline: post.title,
  datePublished: post.publishedAt, // never changes
  dateModified: post.updatedAt, // only changes on a substantive edit
  author: { "@type": "Person", name: post.author.name, url: post.author.url },
};

<p>
  Published {format(post.publishedAt)} · Last updated {format(post.updatedAt)}
</p>

Three rules keep it honest:

1. Only move updatedAt on substantive edits. Fixing a typo is not an update. Store the date in your CMS or frontmatter rather than deriving it from the file's last-modified time, which changes on every deploy.
2. Keep sitemap lastmod truthful. Google uses lastmod only "if it's consistently and verifiably" accurate. Changes to main content, structured data or links count as significant; a copyright-year change doesn't. Inflate it and Google may stop trusting it for your whole sitemap.
3. Change the year in a title only when the content earns it. Google lists obsolete dates in titles as a reason it rewrites title links, and the fix is updating the page, not just the title.

After publishing a substantive refresh, use URL Inspection > Request indexing to prompt a recrawl.

A refresh cadence#

There's no official cadence. Here is a starting calendar for a 50-page site that works in our experience:

Run the Search Console comparison monthly to catch sudden drops between scheduled reviews. Pages that are stable and accurate don't need touching just because their review date came up: a review that ends in "still correct, no change" is a good outcome, and the date stays as it is.

Measuring the result#

1. Annotate the date in Search Console (right-click the Performance chart > Add annotation, available since November 2025).
2. Wait 4 to 8 weeks, then compare clicks for the page and its main queries against the same length of time before the refresh, and against the same period last year for seasonal topics.
3. Look at queries, not just totals. A good refresh often wins new queries the old page never ranked for.
4. Be patient with big changes. Google's core updates documentation (since December 2025) says smaller, unannounced core updates can reflect improvements, so you don't have to wait for a named core update, but some gains only show up after one.

Keep a simple log (URL, date, what changed, clicks before and after). After a dozen refreshes you'll know which kinds of change move the needle on your site.

Next: AI-Assisted Content Without Penalties, using AI in your writing and refresh workflow without crossing Google's spam lines.