A post can be old without being wrong.
It can also be edited last week and no longer useful.
That is the distinction a timestamp cannot make.
Some work goes stale fast. Pricing, tax guidance, news commentary, anything a regulator can change: that deserves a look every few months, not every year.
Technical documentation, tutorials, and operating procedures can wait longer.
Foundational definitions and reference pieces can wait longer still.
Those are review horizons, not rewrite schedules.
The calendar asks you to re-verify.
It doesn’t get to choose the remedy.
Three signals open the same door. A ranking that has been sliding. Traffic falling against the post’s own history. Or simply the date arriving.
Whichever one knocks, don’t start with new ideas.
Start with an audit.
Look at where the post actually ranks now.
Read the pages competing with it, as they exist today rather than as they were.
Name what changed in the subject since you published.
Check the facts. Check the outbound links.
Then hold the old answer against the question readers are bringing now.
That comparison is the whole decision, and it usually produces one of two verdicts.
A light refresh has a narrow job.
Date stamps, updated figures, a few new internal links, a copyedit pass.
It skips the structural questions because the outline still holds.
A post with a sound angle and a stale price does not need to become a different post.
A changed field asks more.
When competitors now answer a different question, when the comparison a reader needs isn’t there, when the answer sits four screens below the fold — the outline is the problem.
Send it back to the structural stage.
That is the gate that catches the wrong angle, the missing comparison, and the section order that buries the point.
Then let it run the rest of the way: a copyedit for voice and claims, the technical and search work, the internal links the piece now needs, and a check of the rendered page before you walk away.
The difference isn’t effort for its own sake.
It is the difference between correcting a fact and restoring an answer.
Let the date follow the real revision.
A typographical fix doesn’t earn a new version. A change to facts, figures, or procedure does.
And not every correction asks a post to become new again.
For a small factual error, add a dated corrections note at the foot of the page.
Name the original statement, name the corrected fact, give the date.
The record should show what changed — not merely that somebody opened the draft.
That is the public half of an edit, and it costs almost nothing to keep.
Set the review horizon when you publish, so the trigger exists before you need it.
Audit when it arrives.
Route the work by what the audit found, not by how much time you happen to have.
Change the date after a real deployment.
Then read the page a reader receives, rather than the record in your CMS.
An old post may need a new fact.
It may need a new structure.
Freshness is not a date. It is a claim that still meets the question.