A library of a few hundred pages is not a project you finish. It is a garden you keep. The day you publish an article it begins to drift away from reality: prices move, a property changes its hours, a competitor publishes something sharper, and the search query the page was built for slowly changes shape. The review and refresh workflow is how we stop that drift from compounding into a stale, untrustworthy site.
This is the unglamorous half of building a content factory. Anyone can publish. Keeping a thousand pages current is the discipline that separates an authority site from a content graveyard.
Why pages decay
Decay has three causes and it helps to name them, because each one calls for a different fix.
- Fact decay. The world moved. A venue closed, a fee changed, a tool was renamed. The page is now wrong, and wrong is the worst thing a directory can be.
- Query drift. The way people search the topic shifted. The page still answers the old question well and the new question poorly. Rankings slide even though nothing on the page changed.
- Competitive decay. Someone published a deeper, clearer, better evidenced page. Yours did not get worse in absolute terms, but it got worse relative to the result above it.
A refresh that only fixes typos misses two of the three. A good workflow checks for all of them on every pass.
Prioritising what to review first
You cannot review everything at once, so the workflow is really a queue. We order it by a simple rule: review the pages that are losing the most value first. In practice that means three signals.
The first is traffic decay. A page that pulled steady visits for six months and has fallen by a third is shouting for attention. The second is query drift, which you read from the search terms a page now ranks for versus the term it was built to win. When those lists pull apart, the page needs a rethink, not a tidy. The third is commercial weight. A page one click from a partner enquiry earns a faster review than one buried in the long tail, because the cost of it being wrong is higher.
This is where a clean spine pays off. We drive the queue from the same master plan spreadsheet that tracks every page, so review status, last reviewed date and decay flags live in one place rather than scattered across someone's memory.
What a review actually changes
A review is not a rewrite. If you rewrite every page you touch, you will never catch up, and you will throw away ranking signals that took months to earn. The job is surgical. On each pass we work through a fixed checklist.
The answer block
Every knowledge page opens with a direct answer of forty to sixty words. That block is what wins the featured snippet and the AI overview citation, so it is the first thing we pressure test. Is it still true? Is it still the answer people are actually looking for? A single sharper sentence here can recover a ranking on its own.
The facts
We confirm every concrete claim still holds. This is the same standard described in fact checking programmatic content: a number, a name or a date stays only if it can be stood behind today. Anything we cannot reconfirm gets softened to a directional statement or removed.
The links
Internal links rot quietly. A sibling article gets a new slug, a pillar gets reorganised, a property page moves. On review we check that every in body link still resolves and still points somewhere useful, and we add a fresh link or two if newer pages now deserve to be referenced.
The angle
If query drift is the problem, we adjust the framing, headings and subtopics to match how the question is asked now. We keep the URL and the core asset intact and change the parts that map to intent.
The cadence that holds
The mistake teams make is treating review as a project they will get to later. Later never comes. The fix is to make review a standing part of the weekly build, the same way new articles are. We reserve a fixed share of each week's capacity for refresh work so the queue is always moving, even in weeks when new publishing is busy.
Not every page deserves the same frequency. The busiest pages, the ones carrying real traffic and real commercial weight, come round on a tight loop. The long tail comes round far less often. We tier the library so the cycle matches the value, rather than pretending a sleepy glossary entry needs the same attention as a pillar that earns links.
The last reviewed date is the honest signal of all this. We only move it when a human or the system has genuinely re confirmed the page, never as decoration. A truthful date is a quiet trust signal to readers and to search engines, and faking it is the fastest way to make the whole site untrustworthy.
Logging the work
Every review leaves a trace: what changed, why, and when. That log does two things. It lets the next person see at a glance whether a page was touched yesterday or a year ago, and it protects you when a claim is challenged, because you can show your working. The discipline mirrors how we run corrections across the library, where a clear record matters more than a fast edit.
If you want the wider picture of how this maintenance layer sits inside the whole operation, the content operations pillar ties review together with planning, briefing and quality control. And if you are weighing whether a large knowledge library is worth running at all, our building thesis sets out why we think durable, well kept content is the most defensible asset a directory group can own.
Let the system flag the work
At a few hundred pages you can feel which articles are slipping. At a few thousand you cannot, and relying on intuition means the quiet decliners go unnoticed until they have fallen out of the results entirely. So the queue should be fed by signals, not by memory. We watch a small set of indicators and let them nominate pages for review rather than waiting for someone to notice.
The most useful signal is a sustained drop in impressions or clicks against a page's own recent baseline, because that catches decline before it becomes collapse. A second is a widening gap between the term a page was built for and the terms it now appears for, which flags query drift early. A third is age alone: any page that has not been touched beyond a set interval gets nominated regardless of its numbers, so nothing is left to rot just because it is quiet.
None of this replaces judgement. A flagged page still gets a human read, because a dip can be seasonal or an artefact of how a topic trends through the year. The signals decide what to look at. People still decide what to change. That division keeps the queue honest and stops the cycle from chasing noise.
Getting started without drowning
If you are starting from a library that has never been reviewed, do not try to boil the ocean. Pull your top fifty pages by traffic and commercial value, review those first, and set the cadence from there. Within a few cycles the queue stops feeling like a backlog and starts feeling like a heartbeat. That steady pulse, more than any single article, is what keeps a large site alive and trusted year after year.
The KHG Review and Refresh Loop: we revisit every published page on a rolling cycle, prioritising by traffic decay and query drift, with the busiest one page in five reviewed roughly twice as often as the long tail.
Common questions
How often should I refresh a page?
Tier your library. The busiest, most commercial pages come round on a tight loop, the long tail far less often. Frequency should follow value, not a single rule applied to everything.
Does refreshing content help rankings?
It can, when the refresh fixes a real cause of decay such as stale facts or query drift. Cosmetic edits with no substantive change rarely move anything and can look manipulative.
Should I change the URL when I refresh?
No. Keep the URL and the core page intact so you do not lose earned ranking signals. Change the answer, facts, links and framing, not the address.