Content decay
Content decay is the slow loss of value in a page you already published — traffic sliding as rankings erode and the search result changes shape around you, or the page quietly becoming wrong as the world it described moves on. The second kind is the more expensive one, because a page can keep ranking perfectly while the sentences on it stop being true.
Two different problems share the name
The reading most tools mean is the traffic one. A page peaks a few months after publication and then slides, with no event to point at: somebody published something better, the result page grew new features above you, the query changed shape, the topic moved on. Nothing broke and nobody penalised you. This is the version a content audit flags, because it is visible in a clicks chart and easy to count.
The reading nobody flags is the factual one. The claims on the page expire. A price changes, a free tier moves, a limitation is lifted, a feature ships, an integration is renamed. Your traffic does not move at all — the page ranks, gets read, and starts misinforming the exact people it was built to attract. From outside it looks healthy, because the damage lands on the reader rather than on the chart.
They are worth separating because their fixes point in opposite directions. Declining traffic is a competitive problem, answered by making the page better than whatever overtook it. An expired claim is a maintenance problem, and rewriting the page for freshness does not touch it unless somebody actually checks the facts. A quarterly reminder to refresh old content catches the first kind reliably and the second kind almost never, because whoever does the refresh is reading for stale tone rather than auditing assertions.
The kind we got wrong on our own site
We publish a page for every integration our product supports. One of them told readers, in every language we publish in, that posting to a particular social network required that network's paid developer tier at a monthly price we had typed into the page, and that publishing support would arrive in a later release. Both halves had stopped being true. The tier we named was no longer sold in the form we described, and posting had shipped long before — several approval-gated write actions plus a handful of immediate ones. Somebody arriving with exactly the question that page existed to answer would have concluded we could not do the one thing they came for, while sitting one click from the button that does it.
Two things about how it survived are the useful part. It never looked stale: the page ranked, read cleanly, and its central claim was the kind of sentence that ages invisibly, because a reader has no way to tell a current limitation from a former one. And our automated checks could not see it. We run tests that fail the build when marketing copy retypes one of our own prices or hardcodes a count that will move, and not one of them fired, because this was prose about somebody else's pricing tier rather than a number of ours.
The repair is the part we would do differently from the start. We did not correct the figure. We changed where the figure comes from, threading the current per-post cost out of the constant our billing code already uses instead of typing it into eight language files, precisely because that vendor had re-priced once already. A fact that lives in prose has no owner and no alarm. A fact read from the code that implements it cannot drift without something else failing first — and the decay you can catch with a test is the only decay you will catch reliably.
What rots fastest, and what to do about it
Ordered by how quickly they go wrong, the claims most likely to expire are the ones you do not control: another company's price or plan names, what a competitor's product can and cannot do, an integration's limits, screenshots of somebody else's interface, and any promise about what your own product will do soon. Anything carrying a date, a version number, a rival's name or a coming-soon pledge is on a clock, and nobody will notify you when it runs out.
What works better than a schedule is a trigger. Attach the page to the thing it describes, so that shipping the feature includes changing the sentence that promised it and re-pricing includes the copy that quotes the price. That is a workflow decision rather than an SEO one, which is why it falls between teams and stays broken. Where the fact is genuinely outside your control, the durable move is to stop asserting it: point at the vendor's own page instead of copying a number out of it, and you lose nothing but a maintenance liability.
For the traffic kind, one test is worth running before you spend a week on a refresh. Open the result that overtook you and decide whether your page loses on substance or merely on age. If it loses on substance, rewriting it is the right work. If it loses on neither — the query itself changed, or the answer now appears in the result without anybody needing to click — a refresh changes nothing, and the honest response is a new page for the question people are now asking. See zero-click search for why that outcome keeps getting more common. At AgentCeres, the AI Growth Officer at agentceres.com, the specialists that draft and update content work the way a careful editor would: claims are evidence-cited, and anything that publishes waits for a person's approval by default.
FAQ
- How do I find pages that are decaying?
- For the traffic kind, compare clicks per page across two equal windows in Search Console and look for steady slides rather than single-date steps — a step on one date is usually something you shipped or a dated update, which is a different investigation, covered in why did my website traffic drop. For the factual kind there is no report to run. The only method that works is a written list of which pages make claims about things outside your control, re-read whenever one of those things changes.
- Is updating the date on a page enough?
- No, and doing only that is worse than doing nothing. A refreshed date tells a reader the facts were checked at that time, so if they were not, you have added a false signal to a stale page. Change the date when you change the content, and treat the two as one action rather than two.
- Should I refresh an old page or write a new one?
- Refresh when the page is still about the right question and has simply been overtaken — its links and history are worth keeping, and a rewrite in place inherits them. Write a new page when the question itself has changed, then point the old one at it rather than stretching a single page to cover both, which leaves two pages competing for the same search. See keyword cannibalization.
- Does content decay matter for AI answers too?
- Yes, and less visibly. An engine that retrieves your page in order to answer a question repeats whatever it currently says, with your name attached, and you see neither a click nor a report. That makes the factual half of decay more consequential than it was when a stale page only misled the people who visited it. See AI citation.
An AI growth team that runs this for you
AgentCeres is a managed AI marketing team — you approve what ships. 14-day free trial, from $39/month.