Content Refresh Driven by Decay and Citation Loss

A page enters the refresh queue when a signal crosses a threshold you agreed to, never because it turned twelve months old. Nobody here bumps a publish date. The system watches four things: position decay, citation loss in AI answers, expiry on facts the page asserts, and change at the sources the page cites. Position decay: Search Console data pulls daily into Postgres. A page qualifies when its 28-day median position falls three or more places while impressions hold flat. That combination means the page still matches demand and lost to somebody else, which is worth an hour of a writer's time. A page losing impressions and position together is usually a demand change and gets a different recommendation, often retirement. Citation loss: A fixed panel of buyer questions, written with your team in English and Arabic, runs weekly against ChatGPT, Perplexity, Google AI Overviews and AI Mode, and Copilot. What gets recorded is which URL was cited, not whether your brand was mentioned. Losing a citation to a named competitor URL is the strongest trigger in the system, because it identifies the page you now have to beat. Fact expiry: Every page declares its perishable facts with a source and an expiry date: a VAT rate, a regulator's fee schedule, a delivery window, a size chart, an integration's supported version. Fintech clients in the Gulf get the most from this. A CBUAE or SAMA circular changes and the queue names every affected page the same day, without anyone having to remember which pages mentioned it. Source drift: Cited external URLs are hashed weekly. When a source changes materially, the pages citing it surface for a check. This is how you avoid the citation that quietly stopped supporting the claim. What the queue produces: A ranked list carrying the trigger, the evidence, the specific claim at issue, and a recommendation of update, consolidate or retire. Ranking is weighted by the page's contribution to revenue where you can give me that data, and by impressions where you cannot. On a mature site, roughly a fifth of the first queue is consolidation and retirement rather than rewriting, and that part of it usually pays for the build. Not included: I do not write the refreshes and there is no add-on that does. No link building, no technical audit, no migration work. The system does not auto-publish anything; a triggered page goes to a person, because deciding whether a claim changed materially is the judgement you are paying for. Who this is not for: Sites under roughly 80 indexed content pages. The queue will be short enough to hold in your head, and you should. Also not for teams who want a system that proves the content programme is working. This one is built to find loss and will report more problems than wins in the first quarter. Running it: The retainer covers the weekly panel, the queue review and the call on each triggered page. Thresholds change as the site changes; the ones I set in month one are wrong by month six, and correcting them is most of what the retainer buys. Everything runs in your infrastructure on your API keys, and keeps running if you stop the retainer.