A founder we work with got a message in July from a prospect who had read one of his posts from the previous November. Good post. Specific, useful, one of his best. It also described a fee structure that changed in January and a character limit that no longer exists.
The prospect didn't mention any of that. He just asked a question that made it obvious he was working from an outdated picture, and the founder had to spend the first four minutes of a sales call correcting his own content.
Nobody has a system for this. We have systems for capturing raw material, for filing it, for sequencing it, for checking it before it publishes. We have nothing for what happens to it after. The pre-publish checklist assumes the moment of publication is the last time accuracy matters. On a platform where a post from eleven months ago can arrive in front of a buyer at 11pm on a Sunday, that assumption is wrong.
Your oldest posts are your most-read posts
This is the part that makes decay expensive rather than embarrassing.
A post you publish tomorrow gets one distribution event. It goes to a test pool, it either travels or it doesn't, and within about a week it has done most of the work it will ever do in the feed.
But that's only one of the ways a post gets read. The other way is the read-through — the acquirer's analyst, the retail buyer, the 3PL deciding on terms, the senior operator choosing between your offer and someone else's. Every one of those people opens the profile and reads down. And a post from last October has had ten more months to accumulate those reads than a post from last week.
So the material most likely to be read by the person with the biggest decision to make about you is, mechanically, your oldest material. Decay concentrates in exactly the posts doing the most work.
That's the whole argument for building a maintenance layer. Not tidiness. The read-through is a diligence behaviour, and diligence readers are the ones most likely to notice that a number stopped being true.
The four things that decay, in order of how fast they go
Not everything you publish has a shelf life. Judgment content is close to permanent. Explanations barely age. What ages is narrower than founders assume and easier to find once you know the shape of it.
Platform mechanics. Fee schedules, character limits, program rules, review windows, what a report is called, where a setting lives, which surfaces exist. This is the fastest-decaying category by a wide margin and it's also the category ecommerce founders write about most, because it's where the specificity lives. A post that says "you get 200 characters" is not slightly out of date. It's a post that tells an operator you haven't looked recently.
Your own business facts. Revenue scale, team size, what you sell, which channels you're on, how many clients you have. Founders write "we're doing about $2M a year" in March and it's $3.4M in November and the post still says $2M. Nobody's lying. The post is just describing a company that no longer exists, and it's sitting on a profile that a prospect is using to size you.
Competitive and market claims. "Nobody in this category is doing X." "There are three real players." These are true on the day you write them and they are statements about other people's behaviour, which changes without telling you. The market claim is the one most likely to be quietly wrong and least likely to be checked.
Dated predictions. The slowest to decay and the most damaging when it does. A founder writes "by Q4 this is going to be table stakes" in February. Q4 arrives. It either happened or it didn't, and the post is still sitting there making the prediction in the present tense with no follow-up anywhere near it. If you were right, that post is one of the most valuable things you own and you're doing nothing with it. If you were wrong, it's a receipt against you.
LinkedIn gives you almost nothing to fix it with
On a blog, decay is a solved problem. You edit the post, you add an updated-on date, the URL stays the same, and the reader has a signal about how current the thing is.
LinkedIn has none of that infrastructure. There is no visible updated-on stamp. There is no version history a reader can see. The edit is silent — and while editing an old post is cheap in distribution terms, it's also invisible, so a reader has no way to know they're looking at a corrected version. And you can't redirect anything: the post has one URL and it either exists or it doesn't.
This changes what the maintenance job actually is. You're not maintaining a document. You're triaging a set of standing claims where your only tools are edit, leave, and delete, and where none of the three announces itself to the reader.
Which is why the sort matters more than the fixing.
The sort: three states, three actions
Once a quarter, an hour. You are not re-reading your archive for quality. You are checking a specific, narrow thing: does this still say something true?
Still true. Most of it. Judgment, mechanism, opinion, explanation. Leave it entirely alone and move on quickly — the bulk of the hour is spent confirming things are fine, and that's the correct outcome, not a wasted pass.
True, but it needs a date. This is the biggest actionable bucket and the cheapest to fix. The claim is accurate and it's describing a moment. A number from your account in Q1. A search grid you screenshotted in spring. A platform behaviour that was correct when you wrote it and might not be now. The fix is one clause: when we ran this in March, at the time, this was before the character cap landed.
Founders resist dating old claims because it feels like weakening them. It does the opposite. An undated claim reads present tense and gets caught by the one reader who checks. A dated claim reads like someone who keeps records. We have never seen a reader be less impressed by a date.
No longer true. The small bucket, and the one people over-react to. The default action here is still an edit, not a deletion. One clause acknowledging the change — this changed in January — converts a wrong post into evidence that you were watching. Deleting it removes the only proof you were writing about this before everyone else was.
Delete only in two cases: the post contains something about a third party you shouldn't have published, or the post is wrong in a way that no clause can rescue and that would actively mislead someone into a decision. Everything else gets edited or left.
The event trigger matters more than the calendar
The quarterly pass is the floor. The pass that actually earns its keep is the one you run the week a platform changes something structural, because that's the week half your archive expires simultaneously.
When a character limit changes, when a fee schedule moves, when a program launches or a surface starts rendering differently — every post you've written about that mechanic went stale on the same afternoon. And that's precisely the week when demand for content about the change peaks, which means it's the week your archive is most likely to be read by people who know the new answer.
The move is to open the archive first and the drafting doc second. Fifteen minutes finding your own now-wrong posts, then the new post practically writes itself — because "here's what changed, and here's what I wrote about it before, and here's what I got right and wrong" is stronger content than the announcement post everyone else is publishing.
That's the second reason to run a decay pass: every stale post you find is a post. The correction and the update are two of the most credible formats available to a founder, and you can't write either one without knowing what you said last time.
What good looks like
Two tells, and neither of them is a clean archive.
You can name your three most fragile posts without looking. Not your three best — your three most likely to be wrong first. If you can, you've internalised where your content sits on the decay curve, and that changes how you write the next one. Founders who run this pass a couple of times start voluntarily dating claims at the point of writing, which eliminates most of the work at source.
Corrections stop feeling expensive. The first time a founder edits a clause into a post from March, it feels like an admission. After a few passes it's a maintenance task, roughly as emotionally loaded as reconciling a spreadsheet. That shift matters because the founders who never run a decay pass are usually the ones for whom every correction is a small crisis, and people avoid small crises by not looking.
FAQ
Isn't this the same as a content audit? No. A content audit looks at performance — what worked, what didn't, what to write more of. It's a planning tool pointed forward. A decay pass looks at accuracy and it's pointed backward. You can run a brilliant audit on an archive full of claims that stopped being true, because the audit never asks whether anything is still correct.
How far back should I go? Everything you'd be comfortable having a prospect read, which for most founders is everything. In practice you'll find the decay clusters in a specific six-month window — usually whichever period you were writing hardest about a platform mechanic. Start there.
Doesn't editing old posts hurt reach? The reach argument applies to editing a post in its first hours, when distribution is being decided. A post from March is not in distribution. Editing it costs you nothing and changes what every future read-through sees. This is the one edit decision that isn't a trade-off.
Should I say publicly that I updated something? Not inside the old post — there's nowhere sensible for it to go and nobody's reading for a changelog. Say it in a new post. "I wrote this in February and half of it is now wrong, here's what changed" is a better piece of content than most things a founder will publish that month, and it does the correction work in front of the audience that read the original.
What if I've published for two years and never done this? Don't start with the archive. Start by dating claims in everything you publish from this week, so the problem stops growing. Then run the first pass on the last six months only. A backlog you never begin is worth less than a partial pass you actually finish.
Most founders think of their published work as spent — it went out, it did its number, it's done. It isn't. It's a standing set of claims with your name on it that anyone can audit without asking permission, and the people most likely to audit it are the ones with the biggest decisions to make about you.
If you'd rather someone else held the ledger and ran the pass, that's what we do.