The content decay guide covers why citation confidence erodes as content ages. This is the operational half: what a team actually does on a Tuesday to catch it, and why most refresh programmes produce activity rather than outcomes.
The common failure is organising the queue by publication date. Everything older than eighteen months gets flagged, someone works through the list, and the work lands mostly on pages where nothing has changed while genuinely stale pages sit untouched because they happen to be newer.
Age Is a Weak Signal on Its Own
A conceptual explainer from three years ago describing a mechanism that has not changed may need nothing. A pricing comparison from four months ago may already be wrong.
What matters is whether the content still describes reality, and reality changes at different rates across content types. Pricing and competitive claims move fastest. Integration and compatibility claims move on someone else's schedule, per the integration pages guide. Statistics carry an implicit expiry when the underlying study gets superseded. Conceptual explanation moves slowly.
A queue built on content type and volatility catches more real problems than a queue built on date, and it does less pointless work.
Four Triggers Worth Building Around
Citation decline on a tracked prompt. The most direct signal available. A page that was being cited and now is not has changed status for a reason worth investigating, and it points at a specific page rather than a date range.
External change you can watch for. A competitor shipping a feature your comparison page says they lack. A platform deprecating an API your integration page describes. A newer study superseding a statistic you cite. These arrive on other people's schedules and none of them touch your site, which is why they go unnoticed.
Impressions holding while clicks fall. Available in Search Console and frequently misread as a ranking problem. It often indicates the query is increasingly resolved by an AI summary, which means the page may need restructuring for citation rather than a content update.
Your own product changing. The most controllable trigger and the most routinely missed. A pricing change, a feature launch, a rename. Every one of those invalidates claims scattered across content nobody thinks to check, because the release checklist covers the product and not the archive.
A Refresh Is Not a Rewrite
The instinct on opening an old page is to improve everything, which turns a thirty minute correction into a two day project and reduces how many pages get touched.
The distinction worth holding: correcting is fixing what became false. Improving is making a page better. Both are legitimate, they compete for the same time, and a refresh queue that conflates them produces a small number of beautifully rewritten pages and a long tail of pages still carrying wrong information.
Run correction as a fast pass. Wrong numbers, dead links, superseded statistics, outdated product references. Run improvement as a separate, prioritised project on pages where the upside justifies it.
Changing dateModified Without Changing Content Is Not a Refresh
Worth being blunt because the practice is widespread. Updating a timestamp so a page looks current, without touching the content, is a claim that the page reflects current reality.
If the content is genuinely still accurate, the timestamp is honest and there is nothing wrong with confirming it. If the content is outdated and the timestamp is refreshed to game a freshness signal, the page is now more misleading than before, because a reader and a retrieval system both have reason to trust it more than they should.
The version I would run: update dateModified when content genuinely changed, and consider a separate visible line stating when the page was last reviewed and confirmed accurate. Those are different claims and separating them is more honest than collapsing both into one field.
What Actually Gets Edited in a Correction Pass
Statistics first, because they carry dates implicitly and a superseded figure is the most checkable kind of wrong. Replace with a current figure and update the attribution, or remove the claim if no current equivalent exists.
Product and pricing references next, connecting to the accuracy requirement in the pricing pages guide. A blog post quoting a price you no longer charge is doing the same damage as an outdated pricing page, with less visibility.
Competitor claims, which decay on schedules you do not control.
Links, both internal to pages that have moved or been pruned, and external to resources that have gone. Internal link rot accumulates quietly after any consolidation project, which is the cleanup step the pruning guide flags as most commonly skipped.
Schema last, and specifically checking it still matches the visible content after the edits above. A correction pass that updates the body text and leaves the schema asserting the old price has created the mismatch described in the schema errors guide.
Cadence by Content Type
Rough intervals that hold up in practice, adjusted for how fast your category moves.
Pricing pages and anything quoting your own prices, on every price change and quarterly regardless. Comparison and competitor content, quarterly, since it depends entirely on external change. Integration and compatibility content, quarterly, same reasoning. Statistics heavy posts, twice yearly, since studies get superseded on a slower cycle. Conceptual and definitional content, annually, mostly to catch terminology drift. Case studies, at the point where the product they describe has changed enough that the account no longer represents current capability.
These are starting points rather than rules. A category where competitors ship weekly needs tighter intervals on comparison content than one where a major release happens twice a year.
Who Runs It Matters More Than the Schedule
Refresh work fails when it belongs to everyone, because it is never anyone's priority against work that produces something new.
It works when it is a named recurring block, sized honestly. Two hours a week correcting the highest priority pages produces more than a quarterly initiative that gets deferred twice and then abandoned.
It also works better when triggered by events rather than calendars alone. A pricing change should create a refresh task automatically, in the same way it creates a task to update the pricing page. Most teams have the second and not the first.
At Scale the Problem Becomes Selection, Not Execution
A site with two hundred pages can refresh everything eventually. A site with twenty thousand cannot, and pretending otherwise produces a queue nobody works.
The selection principle that holds: refresh what is cited, or what should be. A page nobody reads and no system cites is a pruning candidate rather than a refresh candidate, and the decision framework for that sits in the pruning guide linked above.
That reframes the exercise usefully. Instead of a backlog of twenty thousand pages, you have a list of the several hundred that appear in tracked citations plus the several hundred that cover topics you want to be cited for. Everything else is inventory, and inventory that carries wrong information should be pruned rather than maintained.
Knowing Whether Refreshing Worked
Refresh has a measurement problem. You corrected a page, and now what. Traffic is a noisy indicator and rankings are noisier still.
Citation status on the prompts that page was built to serve is the closer measure, particularly on live retrieval engines where changes reflect fastest. Expect movement there within weeks rather than days, and expect training dependent engines to lag considerably, for the reasons in the migration guide.
The NotionCue Citation Tracker is the practical instrument here in both directions. Declining citation on a tracked prompt is the strongest available refresh trigger, and recovering citation afterward is the clearest confirmation the work landed.
Start your free NotionCue trial and use citation decline rather than publication date as your primary queue signal. It points at specific pages and it points at pages that actually matter.
Before building a refresh calendar, run one pass looking only for factual errors: wrong prices, superseded statistics, dead links, discontinued features. Most teams find enough in that single pass to justify the ongoing process, and it is faster than designing the process first.
Common Questions
Should a refreshed page be republished with a new date?
Keep the original publication date and update the modified date. Changing the publication date on old content obscures its actual history and offers no benefit.
Is it better to refresh an old page or write a new one?
Refresh where the URL has accumulated links and citation history, which is usually. Write new where the topic has changed enough that the old framing is wrong rather than outdated.
How much has to change before it counts as a refresh?
Enough that the page describes reality differently than it did before. A typo fix is not a refresh and should not trigger a timestamp update.