A maintenance schedule for evergreen content

“Evergreen” is the most misleading word in content marketing, because it describes the topic while quietly implying something false about the artefact. The topic — how redirects work, how to size a cash buffer, how to pick a domain — genuinely stays relevant for years. The article you wrote about it does not. It ages the way an unattended house ages: nothing dramatic on any given day, just a slow accumulation of drifted facts, dead links, stale screenshots, and confident references to things that no longer exist, until one day a reader lands on it and quietly concludes that you do not know what you are talking about.

I run a library of more than three hundred posts and tutorials across this site, almost all of it evergreen by design, and I learned the decay lesson the embarrassing way: I found one of my own top-ranking articles cheerfully describing a tool surface we had retired months earlier. Publishing had a schedule; maintenance had a vague intention, which is to say it had nothing. The fix was to give maintenance the same standing as publishing — a real rota, on the calendar, with rules for what gets looked at, how often, and what happens when a review finds a problem. That rota is what this guide documents.

The system has three parts, and none of them requires software a one-person site cannot afford. First, a tiering of the library by traffic, so attention goes where readers actually are. Second, a quarterly review cycle with a short checklist and exactly three possible verdicts — update, rewrite, or prune. Third, a thin layer of automation that catches the mechanical rot (broken links, malformed entries, orphaned images) in the long gaps between human reviews. I will take those in order, then finish with the two things most maintenance advice skips: how to change dates honestly, and how to tell whether a refresh actually did anything.

The first decay vector is factual drift, and it is the sneakiest because the page never visibly breaks. Prices move. Free-tier limits shrink. A tool you recommended gets acquired and ruined. A “current best option” stops being either. The sentence you wrote was true on publication day and the page has no way of knowing it stopped being true — no error, no warning, just a growing gap between what the article claims and what a reader will find when they act on it. In my library the worst offenders are always the most specific claims, which is a cruel irony, because specificity is exactly what made those articles useful.

The second vector is rot you can actually detect: links and images. External pages get moved, merged, or deleted — studies of link rot consistently find a meaningful fraction of outbound links dying within a few years, and my own periodic sweeps match that. Internal links rot too, every time you restructure a section or retire a page. Screenshots are the fastest-aging asset of all, because interfaces change constantly; a two-year-old screenshot of anyone’s dashboard is a small museum exhibit, and readers register the staleness instantly even when the surrounding advice is still sound.

The third vector is the one you inflict on yourself. Rename a product, reprice a tier, retire a feature, and every historical mention of it across the library becomes wrong simultaneously — I have done all three, and the cleanup taught me more about maintenance than any article did. There is a competitive vector too: the other pages ranking for your query are being refreshed on their own schedules, so the standard a searcher expects keeps rising even while your page stands still. Decay, in other words, is not a possibility to guard against. It is the default state, and a schedule is simply the decision to notice it on your terms instead of a reader’s.

You cannot review three hundred posts every quarter, and pretending otherwise is how maintenance plans die in their first month. So the schedule starts with an honest capacity decision: tier the library by traffic, and let review frequency follow the tier. The data comes free from Search Console — export twelve months of page-level clicks and impressions, sort by clicks, and look at the concentration. Every content library I have ever examined shows the same lopsided curve: a small slice of pages earns the overwhelming majority of organic clicks, a middle band ranks and earns a trickle, and a long tail does very little on any given day.

I cut that curve into three tiers plus a nursery. Tier A is the set of pages that together produce roughly eighty percent of organic clicks — on my library that is only a tenth of the pages. Tier B is everything that ranks and earns impressions but only modest clicks: pages with a pulse and unrealised potential. Tier C is the long tail — pages that exist, serve the occasional visitor, and support the clusters around them. The nursery holds anything published in the last ninety days, which is too young to judge and too new to have decayed; it gets one scheduled checkup and then joins whichever tier its early numbers suggest.

Tiering is not just triage; it is a statement about blast radius. A wrong fact on a Tier A page is being read by someone right now, today, and every day you leave it — the error compounds hourly. The same wrong fact on a Tier C page misleads three people a month. Matching review frequency to blast radius is what lets a small operation promise something meaningful: not “everything is always perfect,” which is impossible, but “the pages people actually read are never more than a few months from their last inspection,” which is both achievable and, for readers, what actually matters.

The cadence itself is simple enough to hold in your head. Tier A gets reviewed every quarter, no exceptions. Tier B gets reviewed twice a year, split across alternating quarters so no single sweep doubles in size. Tier C gets reviewed once a year, as a rolling batch — a slice each quarter rather than one soul-crushing January death-march through two hundred old posts. The nursery checkup lands at the ninety-day mark. And any page, in any tier, jumps the queue immediately when a reader reports a problem or an automated check flags one; the rota is a floor for attention, never a ceiling.

Mechanically, I run the sweep in the first week of each quarter and work from the least glamorous tool in this whole system: a spreadsheet with one row per URL — tier, last-reviewed date, verdict, and a notes column. Each review is capped at about fifteen minutes and follows the same checklist: are the specific factual claims still true; do the external links still resolve to what I cited; are the diagrams and any product references current; does the opening still match what searchers are asking; and is there a newer post in the library this page should now link to? Fifteen minutes sounds brisk, but a focused pass catches nearly everything a two-hour agonise would.

The one discipline that makes the sweep survivable: the review is triage, not surgery. I log a verdict and move to the next page, and only after the whole batch is triaged do I schedule the actual fixing, grouped by type — one session swapping dead links across every flagged page, one session on factual corrections, rewrites booked as their own calendar blocks. The alternative, falling into a full rewrite the moment you spot the first embarrassing paragraph, feels productive and reliably kills the rota, because the sweep never finishes and the next quarter starts with a guilt backlog instead of a clean list.

Every review ends in one of three verdicts, and having only three is the point — an open-ended “hmm, improve somehow” note is a decision deferred, and deferred decisions are where maintenance goes to die. The first and most common verdict is update: the structure holds, the argument is still one I stand behind, but details have drifted. Swap the stale numbers, replace the dead links, redraw the aged diagram, add a short paragraph on whatever changed since. Most Tier A verdicts are updates, and a good one takes an hour, not a day. The craft of doing that well is its own subject, which I covered in Refreshing old content to keep (and regain) rankings.

The second verdict is rewrite: keep the URL, replace the body. I reach for it when the drift is structural rather than cosmetic — the search intent has shifted and the page now answers last year’s version of the question, or my own understanding has moved and the article argues something I no longer believe. The tell-tale signals are a page holding decent impressions while its position and click-through sag quarter after quarter, or the simpler human signal: I reread it and wince. A rewrite costs nearly what a new post costs, which is exactly why it needs its own verdict — budgeted deliberately, not smuggled into a fifteen-minute review slot.

The third verdict is prune, and it is the one people flinch from. Some pages are redundant with a better page you wrote later; some were misjudged from the start and three years of data confirm nobody wants them. Keeping them costs crawl attention, dilutes the library, and drags the maintenance burden up every single quarter. When a page has earned links or residual traffic, merge its useful substance into the better page and 301 the URL; when it has earned nothing, retire it cleanly. The mechanics of doing that without losing equity are laid out in Pruning and consolidating content without losing rankings. Across a typical year my verdicts land roughly seventy percent update, twenty percent rewrite, ten percent prune — and the prune decile is the one that keeps the other ninety percent maintainable.

Dates deserve their own section because they are where content maintenance most often shades into lying. Searchers filter by recency, results show dates, and everyone in this trade knows a fresher date tends to earn more clicks — so the temptation is obvious: bump the date, change nothing, harvest the freshness. It works just well enough to be popular and it is a straightforward deception of the reader, who took “updated last month” as a promise that someone checked the claims last month. It is also increasingly futile, since search engines compare the content they recrawl against what they had before, and a date bump with no substantive change is a detectable pattern.

My rule is mechanical so that I cannot negotiate with myself: the visible date on a page changes only when a review produced substantive edits — corrected facts, redrawn diagrams, new sections, revised recommendations. Fixing a typo or swapping one dead link does not move the date. Google’s guidance on publication dates says essentially the same thing — provide dates, keep them accurate, and do not artificially freshen pages without significant updates — and it is one of the few pieces of official advice that aligns perfectly with plain honesty, which makes it easy to follow.

The habit that enforces this is the maintenance log itself: because every review already gets a row with its verdict and notes, the question “does this edit justify a date change” answers itself from the record rather than from wishful thinking. For major refreshes I go one step further and say so in the piece — a short line noting the page was reviewed and what materially changed. Readers reward that more than you would expect. Date integrity is a slow-compounding trust asset: invisible when you have it, and very visible the first time a reader catches a “fresh” page describing a world two years gone.

Refreshing content without measuring the effect is how you end up polishing pages out of superstition, so the log earns its keep a second time here: every refresh gets its date recorded, per URL, because attribution is impossible without knowing exactly when the change shipped. The measurement itself is deliberately plain — in Search Console, compare a twenty-eight-day window after the refresh against the same-length window before it, and leave a two-to-four-week gap after the edit for recrawling and settling before the “after” window starts. I read position and impressions before clicks, because clicks inherit seasonality and query-demand swings that have nothing to do with your edit.

The recrawl gap is worth shortening when you can. A refreshed page only competes as its new self once search engines have re-fetched it, so after any meaningful update I request indexing for the URL — the routine is in Getting indexed faster in Google Search Console — and I still expect the data to take weeks, not days, to say anything. Impatience here produces the classic false negative: judging a refresh dead at day ten, just before the recrawl lands and the position moves.

Then there is the small-numbers problem, which quarterly measurement makes unavoidable: a Tier C page going from four clicks to nine is a coin flip, not a victory. For the long tail I judge refreshes in aggregate — did this quarter’s refreshed batch trend better over the following quarter than comparable pages I left alone — and reserve page-level verdicts for pages with page-level traffic. The readings feed the next cycle directly: a page that has absorbed two competent refreshes and still will not move is telling me its problem is not staleness, and its next verdict is probably rewrite or prune rather than a third coat of polish.

Everything above is human process; the layer underneath is automation, and a small site can have more of it than people assume — not by buying an enterprise content platform but by making the build do the checking. On this site the entire library lives as typed TypeScript rather than rows in a CMS, which means the compiler is the first maintenance tool: when we renamed a product, every stale reference surfaced as a build error with a file and line number instead of a needle-in-haystack search. A malformed entry — a missing field, a wrong image dimension — cannot ship, because the site literally will not compile around it.

On top of the compiler sits a validation gate that runs at build time and checks the things types alone cannot: that every image path in every post points at a file that exists, that every related-post reference names a slug that is actually in the registry, that internal links resolve against the live route tree. I wrote up the design in A build-time validation gate: catching content errors before deploy, and the payoff is blunt: an internal 404 cannot reach production, ever, no matter how careless a late-night edit gets. External links are the one thing the build cannot guarantee — the outside web moves without consulting us — so those get a periodic sweep with a link checker, feeding a fix list straight into the quarterly rota.

Two policies round out the tooling, and they cost nothing. First, no screenshots: every diagram on this site is a hand-drawn SVG, and the difference for maintenance is enormous — an SVG ages as an idea, so when a fact changes the fix is a text edit, while a screenshot ages as pixels and demands a full re-capture of a UI that may no longer exist. Second, the documentation hub at Documentation sits inside the same rota as the posts, because docs decay identically and are read at more decisive moments. The complete stack — compiler, build gate, link sweep, SVG policy, one spreadsheet — costs nothing monthly and catches the mechanical majority of rot before any human review even begins.

Every maintenance system eventually meets the quarter where everything else is on fire, and what kills the system is never that bad quarter — it is the precedent. Skip one sweep entirely and the next one inherits double the pile plus a layer of dread, and dread is how a skipped quarter quietly becomes a skipped year. So the rota has a designed minimum: when the quarter collapses, do Tier A only. That is one afternoon, it protects the pages carrying nearly all the readership, and it keeps the habit alive, which matters more than the coverage. A reduced sweep that happens beats a complete sweep that does not, every single time.

The reframe that made the schedule stick for me was accounting: maintenance is publishing. A refreshed Tier A page is content shipped to more readers than most new posts will meet in their first year, at a fraction of the writing cost, and the before-and-after data from the measurement section usually shows the refresh out-earning a median new post per hour invested. Once I started counting refreshes toward the content calendar instead of treating them as janitorial overhead stolen from “real” work, the incentive problem — new posts feel like progress, upkeep feels like penance — mostly dissolved.

What you get, a year in, is a library with a property that very few sites can honestly claim: every page a meaningful number of people read has been inspected within the last ninety days, everything else within twelve months, and the dates on the pages mean exactly what a reader assumes they mean. None of it required a team or a platform — a spreadsheet, a compiler, one afternoon a quarter at minimum, and the willingness to treat “evergreen” as a verb. The plant survives because somebody waters it; the word was never a promise the content made, it was a promise you did.