Content Refresh System That Triages Before It Rewrites

Most refresh programs rewrite whatever is easiest to rewrite. Of the 340 URLs in the last refresh backlog I triaged, 61 needed the rewrite they were queued for. The rest needed one fact corrected, a stale figure re-dated, or nothing at all, and eleven should have been removed. A refresh system earns its cost by being right about which of those five things a page needs, not by producing drafts on a schedule. The signals it watches: Loss of citation in answer engines, measured by re-prompting a fixed set and recording when your passage stops being quoted and whose starts instead. Change in the source document behind a page: a datasheet revision, a new AAFCO ingredient definition, an updated NOM standard, a PROFECO or CPSC recall notice touching something you sell. Date-of-fact staleness parsed out of the body text — a price, a model year, a test result carrying a year — not the meaningless last-updated stamp. Query drift in Search Console, where a page keeps its clicks while the questions arriving at it change. And a competitor's passage changing on a page you compete with for the same answer. What it does with them: Every trigger writes an item to a queue with its evidence attached: which signal fired, the diff, the URL, and a proposed disposition of correct, rewrite, consolidate or retire. Corrections that are unambiguous, where a figure changed in a source you control, are staged as a draft — a pull request against your content repo, or a draft entry in Contentful or Sanity with the change highlighted. A person approves. Nothing publishes itself, in either language, at any confidence threshold. Where the build goes: A scheduled Python service on your infrastructure, not mine, with the prompt-sampling component rate-limited and budgeted so a runaway loop cannot spend four figures overnight. A weekly digest to Slack ranks the queue by what the correction is worth, which is a function of the page's assisted revenue and the seriousness of the error, not of its traffic. Spanish and English pages are triaged separately because they decay differently: a Mexican product page usually goes stale when the distributor list changes, an English one when the competitor set does. What I will not build: An auto-publishing loop. A system that regenerates whole articles from a title. A freshness routine that changes dates and shuffles paragraphs, which is the most common thing sold under this name and which achieves nothing except a wasted crawl. I also will not wire this into a CMS with no API and no draft state; a builder-only stack has to be fixed first, and that is your engineering team's work, not mine. Who this is not for: Libraries under roughly two hundred content URLs, where one person reading the list each quarter beats any system. Teams with no named owner for product data, because the triage will keep surfacing questions nobody can answer and the queue rots inside two months. And anyone who wants the count of published updates to be the metric; that number is the thing this system exists to stop reporting. The first thing you get: The triage of your existing library, done by hand before anything is built, with a disposition on every URL and the reasoning attached to the arguable ones. Two clients have stopped there and spent the build budget on fixing product data instead. That is a defensible place to stop, and I will tell you when it is the right one.