> ## Documentation Index
> Fetch the complete documentation index at: https://docs.snowdoughnut.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Maintaining the article library

> The recurring cycle that keeps published articles current: pull what is due from the register, triage each one into update, consolidate, retire, or leave, do the work, and set the next review date.

Published articles decay. Facts age, the question shifts, someone else publishes something more current, and none of that announces itself. This is the recurring cycle that catches it: pull the articles that are due, decide what each one needs, do the work, and set the next date.

<Info>
  This process runs on the [hero article register](/hero-article-register) and the [supporting article register](/supporting-article-register). The cadence defaults live in the [article standards](/article-standards).
</Info>

## What you'll end up with

* Every article that came due either updated, consolidated, retired, or deliberately left alone with a reason recorded.
* Updated last-updated and next-review dates in the register, with a note on what changed.
* A register that reflects what is actually published today.

## Why this exists

A hero article is a commitment to keep something true indefinitely, not a piece of work that finishes at publication. Without a cycle, articles get updated when somebody happens to notice a problem, which in practice means after they have stopped working.

The signal is measurable. Published analyses of AI citations on commercial queries put the large majority on pages updated within the past year, and well over half on pages updated within six months. An unmaintained article is a depreciating asset, and a library of them makes a site harder to trust.

## When it runs

| Article type                                      | Default review cadence |
| :------------------------------------------------ | :--------------------- |
| Hero                                              | Every quarter          |
| Supporting                                        | Every 6 to 12 months   |
| Anything with pricing, specs, or fast-moving data | Every 1 to 3 months    |

Run the sweep on a fixed schedule, monthly is usually enough, and work whatever is due that month. A fixed date on a calendar with a named owner is what makes this happen. A cadence that exists only in a document does not.

<Warning>
  Do not set a cadence the team cannot sustain. A quarterly cycle across twenty hero articles is real recurring work. An honest twice-yearly cadence that actually runs is worth more than a quarterly one that is silently missed, because the register stays true.
</Warning>

## The process at a glance

<Steps>
  <Step title="Pull what is due">
    Filter both registers for a next-review date in this period.
  </Step>

  <Step title="Check for decay signals">
    Look at what changed since the last review: traffic, citations, the facts themselves.
  </Step>

  <Step title="Triage each article">
    Update, consolidate, retire, or leave. Record the decision either way.
  </Step>

  <Step title="Do the work">
    Make substantive changes, not date bumps.
  </Step>

  <Step title="Update the register">
    New last-updated date, new next-review date, and a note on what changed.
  </Step>

  <Step title="Review the hero set once a year">
    Confirm the authority areas are still the right ones.
  </Step>
</Steps>

## 1. Pull what is due

Filter the [hero](/hero-article-register) and [supporting](/supporting-article-register) registers for a next-review date falling in this period. That list is the work.

Anything with a review date in the past is overdue and goes to the top of the list. A register with a growing pile of overdue rows is telling you the cadence is set faster than the team can run it, which is a cadence problem rather than a discipline problem.

## 2. Check for decay signals

For each article, look at what has changed since the last review:

* **The facts.** Are the numbers, prices, screenshots, product names, and dates still correct? Start with the "what will go out of date first" note from the original brief.
* **Traffic and rankings.** Is organic traffic falling? Has the article slipped for the queries it was written for?
* **Citations.** Run the article's primary question as a prompt in the AI tools your customers use. Are you cited? Is a competitor cited instead?
* **The competition.** Has someone published a more current or more complete answer?
* **The question.** Are people still asking this, and asking it the same way?
* **Links.** Are the outbound links still alive? Do the inbound links from the brief still exist?

## 3. Triage each article

Every article that came due gets one of four decisions.

| Decision        | When it applies                                              | What it means                                                        |
| :-------------- | :----------------------------------------------------------- | :------------------------------------------------------------------- |
| **Update**      | The question is still right, the article has aged            | Refresh facts, add new data, expand thin sections, fix the structure |
| **Consolidate** | Two or more articles now overlap                             | Merge into the strongest one, redirect the others to it              |
| **Retire**      | Nobody asks this any more, or it is no longer ours to answer | Redirect or remove, and record why                                   |
| **Leave**       | Still accurate, still performing                             | Change nothing, record that it was checked, set the next date        |

Leaving an article alone is a real decision, not a skipped one. Record it, so the next reviewer knows the article was looked at.

<Warning>
  Consolidating and retiring both change URLs. A removed page with no redirect loses every inbound link and citation pointing at it, including ones you never knew existed. Redirect to the closest equivalent page rather than the homepage.
</Warning>

## 4. Do the work

An update is a substantive change to the article, not a change to its date.

Bumping a timestamp without changing anything is visible to readers who have seen the page before, and it destroys the one signal that would otherwise tell your own team which articles genuinely need attention. If nothing needed changing, the decision was "leave," and that is fine.

A substantive update usually means one or more of:

* New or corrected data, with the source updated.
* A new section answering a question people have started asking.
* Removing a section nobody needs any more.
* Rewriting an opening that no longer answers the question directly.
* Adding the internal links to articles published since this one.

A hero article that has drifted far enough to need rewriting rather than updating goes back through the [article process](/article-process) with a fresh brief, keeping the same URL.

## 5. Update the register

For every article touched:

| Field        | What to record                                |
| :----------- | :-------------------------------------------- |
| Last updated | Today's date, on the page and in the register |
| Next review  | Today plus the cadence for that tier          |
| Status       | Live, consolidated, or retired                |
| Notes        | What changed, in one line                     |

The one-line note is what makes the next review fast. A reviewer who can see that the last pass replaced the 2027 telemetry figures knows exactly where to start.

## 6. Review the hero set once a year

Once a year, step back from individual articles and look at the hero set as a whole:

* Are these still the areas where we can answer better than anyone else?
* Has an area stopped being ours, because the market moved or someone else now owns it?
* Has a supporting article outgrown its tier and earned a hero slot?
* Are any hero articles consistently missing their review dates, meaning the set is larger than the team can maintain?

Promoting a supporting article into the hero set means demoting or retiring another one. The cap is what makes the commitment real, and a hero set that grows quietly ends up as an ordinary content library with an aspirational label. The [article library overview](/article-library-overview) covers how areas are chosen.

## Exceptions

* **An article breaks between reviews.** A wrong price, a broken product reference, or a factual error gets fixed immediately rather than waiting for its date. Update the register when you do.
* **A launch or announcement dates an article overnight.** Treat the launch as the trigger and update the affected articles as part of the launch, not at their next scheduled review.
* **An article is deliberately frozen.** Some pieces are records of a moment: an announcement, an event recap, a dated report. Mark them as frozen in the register with no review date, rather than leaving them to fail a freshness check forever.

## Related resources

* [**Hero article register**](/hero-article-register) The capped set, with review dates.
* [**Supporting article register**](/supporting-article-register) Everything else.
* [**Article library overview**](/article-library-overview) How tiers and areas are decided.
* [**Article standards**](/article-standards) The cadence defaults.
* [**Article update checklist**](/article-update-checklist) The pass to run on each article you update.
* [**Article process**](/article-process) For an article that needs rewriting rather than updating.