A content refresh is not "change a few words and bump the date" — search engines are wise to that, and readers deserve better. This checklist sequences a substantive refresh: verify, expand, correct, relink, and only then re-date. It operationalises our guide to refreshing old articles and is part of SEO checklists for articles.
- A refresh is substantive or it is nothing: verify intent, expand coverage, correct the facts, re-link — and only then update the date.
- Google's people-first guidance warns against changing dates to make content seem fresh when it has not substantially changed.
- Keep the old version before you start, and log what changed so the next refresh begins from evidence, not memory.
- If two tired articles cover one topic, merge instead of refreshing both — this checklist shows where that line sits.
Before you touch the article
- Confirm it is a refresh candidate: impressions in Search Console (ideally position 8–30) or a clear decline — not a page whose problem is indexing or orphaning.
- Record the baseline: note current clicks, impressions, and average position for its main query. Without a baseline you cannot judge the refresh later.
- Re-read today's SERP: has intent, format, or angle shifted since publication? (intent routine)
The refresh itself
- Fill coverage gaps: compare against the current top three; add the genuinely missing sub-answers as proper sections.
- Update every checkable fact: prices, dates, versions, statistics — re-source each from the primary source, not from your own old text.
- Remove what aged badly: dead tools, retired advice, screenshots of interfaces that no longer exist.
- Rewrite the introduction with the Answer–Problem–Map pattern (intros that hook).
- Refresh the title and meta description to match current intent and earn the click.
- Repair outbound links: click every external link; replace dead ones with live primary sources.
- Add internal links both ways: link out to newer siblings the article predates; note two newer articles that should link back to this one, and edit them.
- Check media: replace blurry or dated images; confirm alt text still describes what is shown.
After publishing the refresh
- Update the "last updated" date — now, and only now, because the change is substantive.
- Log it: page, date, what changed, baseline metrics. One line in a spreadsheet.
- Set a review point: check Search Console in 4–6 weeks against the baseline; record the verdict in the same log.
Merge instead when…
Two situations should divert you from this checklist to a merge: a sibling article now targets the same intent (the refreshed pair would cannibalise), or the topic itself has shrunk so the article's honest scope is one section of a bigger page. The decision framework lives in keyword cannibalization. Merging done well — fold in, redirect, relink — is a refresh of the topic rather than of the page.
Sources (5)
Google Search Central guidance on dates and freshness (developers.google.com/search/docs/appearance/structured-data) — dates should reflect substantive change; Search Console Performance baselining per Google's own help documentation.
- Google Search Central — Creating helpful, reliable, people-first content
- Google Search Central — SEO Starter Guide
- Google Search Central — How to specify a canonical URL
- Search Console Help — URL Inspection tool
- Google Search Central — Google Search Essentials
Documenting what 'substantive' means
Because the final step — updating the date — is the one open to abuse, define "substantive" for your site in advance and hold the line: at least one of (a) a section added or materially rewritten, (b) checkable facts updated throughout, (c) intent realigned with today's SERP, (d) media or examples replaced with current ones. A refresh meeting none of those is a copyedit, and copyedits do not earn a new date. This discipline protects you twice: readers learn your dates mean something, and your refresh log stays an honest record of interventions you can actually learn from.
Scheduling refreshes across a year
Spread the load by tier. Tier 1 (your top ten traffic pages): reviewed every six months. Tier 2 (impressions but page-two positions): reviewed when the checklist's candidate signals appear, roughly quarterly scanning. Tier 3 (the long tail): an annual pass, mostly hunting stale facts and merge candidates. Most small sites discover their real capacity is one proper refresh a week; a calendar that admits this outperforms an ambitious plan abandoned by March.
Refresh notes: three scenarios
The almost-there article (position 9–14, rising impressions): your refresh is surgical — coverage gaps and the introduction, nothing else. Over-editing a nearly-working page is the classic own goal. The proud old workhorse (high traffic, ageing facts): the danger is sentimental — the article's structure may no longer match how the topic is searched. Re-run the intent check as if you had never seen the page, and be willing to restructure. The zombie (some impressions, no clicks, no links, topic half-dead): run the checklist's first step brutally honestly. Many zombies should not be refreshed at all; they should be merged into a living sibling or retired, and the checklist's merge criteria exist to make that call without nostalgia.
One page, refreshed well: an anatomy
A typical full pass on a 1,800-word guide looks like this in the log: intent re-verified (SERP now leads with a comparison table — added one); two coverage gaps filled (a "costs" section and a "common mistakes" section, +420 words); six facts updated with fresh sources; the introduction rewritten around the answer; four dead outbound links replaced; three internal links added to newer spokes and two link-backs placed; date updated; baseline 214 impressions/day at position 16.4, review set for five weeks. Ninety minutes. That entry — specific, bounded, measurable — is what "content maintenance" actually means on a well-run small site.
Refresh vs. rewrite: drawing the line
Publishers ask where refreshing ends and rewriting begins, usually while staring at an article they are tempted to bulldoze. The working line: a refresh keeps the article's intent, structure spine, and URL, and improves everything hung on them. If your plan changes the target query, replaces more than about two-thirds of the substance, or re-angles the page at a different audience, you are rewriting — which is fine, but log it as a rewrite, because rewrite outcomes are judged differently (slower, riskier, occasionally transformative) and your future self deserves honest data about which intervention your site responds to. The checklist above serves both, but the refresh steps assume continuity; a rewrite should additionally re-run the intent routine from scratch, as if the page were new.
Keep the old version
Before any substantial refresh, save a copy of the current page — a dated file or a screenshot of the text. If the refresh misfires, you will want the original's exact wording and structure for comparison; if it succeeds, the copy becomes evidence in your log of what changed. Memory romanticises drafts; files do not.
The two-minute version
Short on time? Verify intent, fix one stale fact, add one link each way — and log it as a light pass, honestly dated only if a fact genuinely changed.
Frequently asked questions
How long does a proper refresh take?
Thirty minutes for a light factual update on a short article; 60–90 minutes for a full intent-and-coverage refresh of a guide. Budget by value: your highest-impression pages deserve the full treatment.
Can I refresh an article that has zero impressions?
You can, but diagnose it first — zero impressions usually means indexing, intent, or linking problems that a text refresh will not fix. See the diagnosis guide.
Should I change the publish date too?
No. Keep the original publish date visible and update only the last-updated date. Honest dating is part of reader trust and matches Google's guidance.
What if rankings dip right after a refresh?
Short dips during re-evaluation are common. Judge at 4–6 weeks against your baseline; intervene only if the dip persists and a re-read of the SERP shows an intent error.
How many articles can I refresh at once?
As many as you can log properly. Attribution gets murky if you also restructure the cluster the same week; stagger structural changes.
Pick one decaying article and run the full sequence this week — verify, expand, correct, re-link, then re-date. Judge the result in Search Console after four to six weeks, not after four days.
When did you last make a substantive change — not a date change — to your most-visited old article?
