Citation half-life: a refresh trigger worth having, and a number worth checking

Most content refresh runs on a calendar or a publish date, which means the page that actually needed updating sits untouched for another quarter while pages that were fine get rewritten anyway. On 13 August 2026, Profound shipped a view that replaces the calendar with a signal: for every cited URL it plots a citation curve and reports the first-cited date, the rise, the peak, the half-life, and the last-cited date.¹ The underlying idea is sound and worth adopting even if you never buy the tool, because a page whose citations are already halving is a better refresh candidate than a page that happens to be old. Two things deserve checking before anyone plans a quarter around it. The headline figure it launches on has no published method, and the metric is built entirely relative to a peak, which quietly excludes most of your pages.

On my own crawler log, all 86 article URLs were re-fetched within three days, so re-fetch frequency carries no decay signal at all.

What is citation half-life, and why does a refresh calendar miss it?

Citation half-life is the number of days from a page’s peak weekly citation count until that count falls to half of the peak and stays there, smoothed on a two-week rolling average.¹ A refresh calendar misses it because a calendar knows only how old a page is, while decay is about whether anything still points at the page. Profound’s framing is that the pages worth updating this week are the ones whose citations are already halving, not the ones that happen to be oldest.¹

That is a real improvement in how the work gets prioritized. A trigger beats a ritual, in the way that a smoke alarm beats walking the house once a month looking for smoke. The comparison breaks at one point worth holding onto: a smoke alarm is wired to the thing you care about, while a citation count is wired to a proxy for it, so a quiet alarm here is weaker evidence than a quiet alarm at home.

What does the new view actually report for each URL?

For every cited URL, the view tracks week-over-week citation counts starting from the first week that URL appeared in an AI answer, and reports five fields. The first-cited date is that first week. The rise is the number of days from first-cited to peak. The peak is the highest weekly citation count and the week it happened. The half-life is defined above. The last-cited date closes it out. The view filters to owned domains or all domains, and by model, so you can see whether a page decayed everywhere or only inside ChatGPT.¹

Profound’s own worked example is a page that “rose for 63 days and then had a 7-day half-life”, which it reads as climbing slowly and then losing relevance fast.¹ The pairing of rise and half-life is the genuinely useful part, because a format with a long rise and a long half-life is worth producing more of, and a format that halves in two weeks needs either a higher publishing rate or a different approach.

Profound suggests grouping cited URLs by page type and comparing half-lives across product pages, comparison pages, glossary entries and launch posts.¹ That is the analysis I would run first, ahead of any individual refresh decision, because it answers a commissioning question instead of a maintenance one. If your comparison pages hold citations for months and your launch posts halve in two weeks, the finding is about next quarter’s brief and not about which page to update on Friday. It also degrades gracefully: even on a small sample, a format-level difference is easier to trust than a single URL’s curve, since one page can decay for reasons that have nothing to do with its format.

Where does the thirteen-week figure come from?

The claim that “half of the content Answer Engines cite is less than 13 weeks old” appears in the opening line of a product announcement, written by a Forward Deployed Engineer and a Product Marketing Manager, with no sample size, no time window, no method and no link to supporting work.¹ That does not make it wrong. It makes it uncheckable, which is a different problem and the one that matters when you are deciding whether to reorganize a content program around it.

There is a place the method might actually live. The same vendor published an observational analysis of roughly 12 billion citations across 29 industries and 8 LLMs on 30 July 2026, a separate document that the launch post does not cite.¹ I have not read that study, so I am pointing at it without vouching for it. If the thirteen weeks is grounded anywhere, that is where to look first.

Why does a peak-relative metric leave most pages out?

A peak-relative metric leaves out every page that never peaked. Half-life here counts days from the peak, and the rise counts days to the peak, so a URL cited once has no rise and no half-life, and a URL never cited has no curve at all. Every line in the view therefore belongs to a page that already won something. The measurement describes the shape of decline among the pages that got cited.

Profound’s Citation Decay view, launched August 13, 2026; the metric is defined relative to each URL’s own peak.

Naming the pattern, the survivor’s curve is any decay metric computed only over items that already succeeded, which makes it silent on everything that never started, and it generalizes well beyond citations. Treat it as a boundary on what the tool can answer instead of a flaw in the tool, and remember that the boundary is easy to forget once the chart is on screen.

As an additional critique, the view reports that citations halved. It does not report whether refreshing the page brought them back, because answering that needs the same page measured after an intervention against a comparable page left alone. Until that exists, “refresh the halving pages” is a reasonable policy rather than a tested one, and it’s worth running as an experiment with the dates written down rather than as a settled practice.

Can you measure any of this from your own server logs?

No, and I did check for this measure. My site logs every bot request, so the best substitute is to treat a re-fetch as a proxy for continued interest and watch the gap between fetches grow. Measured on 18 August 2026 across the 86 article URLs that appear in my path logs, the median gap since the last fetch was 2 days, the maximum was 3, and not one article had gone a week unfetched. Every article is being re-fetched roughly daily, so the line is flat and a flat line cannot proxy a decay curve.

There is a second, harder blocker underneath that one. My two log files are keyed differently, one by date and user agent and the other by date and path, and they share no key beyond the date. So no fetch can ever be attributed to a named crawler, and “GPTBot re-fetched this URL” is not a sentence the data can support. Anyone planning to build this from Cloudflare or nginx logs should check that their own logging preserves the join before designing around it.

A re-fetch is also not a citation. A crawler reading your page tells you nothing about whether an answer engine used it, and citation decay is only observable on the answer side. Server logs are the wrong instrument for this question, and finding that out cost me one script.

What should change in a refresh queue on Monday morning?

Sort by decay if you can see decay, and by evidence of interest if you cannot. With the vendor view, work the top of the half-life queue and leave pages still on the rise alone, but log what you changed and the date you changed it, so that in a quarter you can answer the counterfactual the tool does not. That log is the difference between a practice and a habit.

One suggestion in the launch post also deserves its own callout; Profound proposes pulling past-peak URLs into an agent that drafts an updated version and stages the revision in your CMS.¹ The plumbing is straightforward and the risk is not in the plumbing. A decay signal tells you a page stopped being cited, and it says nothing about why, so an agent triggered on decay will rewrite pages that lost citations because the query changed, because a competitor published something better, or because the engine changed how it selects sources. Two of those three are not fixed by editing your page. I would wire the trigger to a review queue before wiring it to a drafting step, and I would want the counterfactual from the section above answered first.

Without the tool, the substitute is not your server log. Pick twenty prompts that matter in your category, check them by hand once a month, and record which URLs get cited in a sheet with dates. It is slow, it is boring, and it measures the thing that actually pays, which is the answer and not the crawl. In my opinion, the tooling here is ahead of the evidence for what to do with it, so the teams who write down what they tried will be the ones who know whether any of this worked.