Catalogue refresh system driven by measured page decay

Refreshing a page because it is twelve months old is a calendar, not evidence, and it spends editorial effort on pages that were never going to move. The trigger this system uses is measurable decay: impressions flat or rising while clicks fall more than 25 percent against the page's own eight-week baseline, or average position slipping past 8 while a URL that was not in the top five last quarter now sits there. Applied to a catalogue of any size, that test flags far fewer pages than an anniversary rule would, and every one of them carries a number next to it: the revenue that page produced in the ninety days before it started sliding. That number is what you take to a budget conversation, and it is the reason this work survives a cost review. The mechanism: A scheduled job pulls Search Console Search Analytics into Postgres, or reads your BigQuery bulk export if you already have one, and joins it against the Shopify or BigCommerce Admin API for stock, price and publish history, and against your order data for contribution margin. It runs on your infrastructure, on GitHub Actions or n8n, under your credentials. We do not host your commercial data and we do not build a dependency on a dashboard we own. A Metabase board ranks the queue by revenue at risk rather than by traffic lost, which reorders it substantially, because the pages that lose the most sessions are rarely the pages that lose the most money. Who operates it: The build is done by the principal who has run this pattern on three catalogues, including one where the queue's first month found that the decaying pages shared a template rather than a topic. That finding cancelled the refresh work and turned into a template fix, which is a smaller invoice than the one originally scoped. During the retainer, the queue is reviewed by a person before anything is published. No page is rewritten by a model and pushed live unseen. Proposals arrive as diffs, a human approves each one, and the approval is logged with a name against it. What the system is allowed to change: Opening paragraph and the direct answer block. Internal links, both into the page from collections that have gained authority and out of it to products that are actually in stock. Specification table completeness. An FAQ block where the live SERP shows a stable question cluster. Image alt text where the image is the thing being compared. The visible date changes only when the body text materially changed, because a date bump with no substance behind it is the one habit that makes an entire refresh programme untrustworthy. What it is never allowed to change: URLs. Canonical tags. Price, availability and shipping claims. Product titles that feed Google Merchant Center, since a title edit there can suspend a feed on a Sunday. Anything with a legal or compliance review attached to it. These are hard blocks in the pipeline, not conventions we intend to follow. The stop rule: If a refreshed page has not moved within six weeks, it leaves the queue and is recorded as a structural problem rather than a content one. Around a third of flagged pages exit this way, and that is the useful part of the output. Refresh cannot rescue a page sitting on the wrong template or targeting a query the site has no standing to answer. The monthly one-pager reports those cases, and it reports the pages where our own edit made performance worse, because a report that only contains wins is a report nobody should act on. Outside scope: New content production. Migration work. Translation or hreflang. Reputation or link work of any kind. Reviewing your paid channels. We will point at a conflict when the same query is being bought and earned at once, but sorting that out is somebody else's engagement. Wrong fit: Stores where nothing has been published long enough to decay. Teams who want volume of updates as the reported metric, because that is the number this system is built to reduce. Anyone who needs the queue to run without a human approving diffs, which we decline on every account regardless of budget, since one bad automated edit to a category page costs more than a year of the retainer.