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.

Take an invented example.

You wrote a comparison of newsletter platforms a while ago. It answered one question: which one should you start on?

Walk the audit once.

Prices have moved. One feature has changed. The pages competing with you still argue about which platform to choose, and readers still ask that.

Your post still answers it. The outline holds.

That’s a light refresh. Update the facts, check the links, let the date follow the work.

Now walk it again, with a different finding.

The competing pages have moved on. They show readers how to move a list they already have.

Your post helps someone pick a starting point. It says nothing to someone who has already started.

Every sentence in it might still be true. The answer still misses the question.

That’s a structural refresh. Add the missing comparison. Reorder whatever buries the point.

Same post, two verdicts.

The facts didn’t decide it. The question did.

Let the date follow the real revision.

It can fail in either direction.

The first failure is a date that moves when nothing else did.

Google’s own self-check for people-first content asks whether you’re changing dates to make pages seem fresh when the content hasn’t substantially changed.

Its sitemap guidance says the last-modified date gets used if it’s consistently and verifiably accurate, and that a new copyright year isn’t a significant update.

The second failure runs the other way.

A price, a claim, or a conclusion changes. You save the page. There’s no note and no new timestamp.

That’s a stealth edit. A reader who saw the original can’t tell anything moved.

The cause is ordinary. Most systems treat a save as a save, so a typo and a reversal look identical unless you file the second as a correction.

Spelling fixed in silence is harmless. A fact fixed in silence isn’t.

This is the less obvious failure, because the page looks tidy while the record breaks.

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.

Your fix lives on the page. It doesn’t travel by itself.

The feed entry a reader already fetched stays as it was. The newsletter already sent stays sent. The syndicated copy stays old until someone changes it, and cached copies stay until they’re cleared.

Each one holds its own copy, apart from your record.

So for a correction of substance, list where the old version went. Decide what each copy needs.

Keep a line saying which ones you notified, and when.

A correction that only touches the origin hasn’t reached everyone who read the error.

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.

Before you change the page, write down its numbers.

The date, the numbers, what you changed. That note is the baseline.

Then leave it alone for a while. Crawling can take anywhere from a few days to a few weeks, so the first days won’t tell you much.

Compare the page against its own past, over matching periods.

If the line holds flat, that’s still information.

The audit may have misjudged which kind of refresh the post needed.

Then you audit again, knowing a little more.

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.