version: "1.0.1" name: content-refresh-system description: "Systematic content refresh discipline. Quarterly audits, refresh prioritization (which pieces, when, how deep), refresh-vs-merge-vs-delete decisions, the lifecycle that distinguishes intentional refresh from set-and-forget decay. Builds on the refresh sections of pillar-content-architecture and editorial-qa with a program-level discipline. Triggers on content refresh, content decay, content audit, refresh prioritization, content lifecycle, refresh strategy, traffic decay, ranking drop, content freshness, evergreen content, content maintenance. Also triggers when traffic is eroding silently across an aging content library, when teams cannot decide which pieces to refresh, or when refresh work is happening but the impact is unclear." category: content catalog_summary: "Systematic content refresh: quarterly audits, refresh prioritization, refresh-vs-merge-vs-delete decisions, the lifecycle discipline that distinguishes intentional programs from set-and-forget decay" display_order: 10

Content Refresh System

A senior editorial leader's playbook for systematic content refresh. The discipline that distinguishes intentional refresh programs from set-and-forget decay, and the prioritization framework that prevents both over-refresh (refresh-everything-on-calendar) and under-refresh (refresh-nothing-until-traffic-collapses).

Content decays. Search behavior shifts; SERP intent reshapes; facts go stale; competitors publish stronger pieces; the brand's own positioning evolves past what older pieces represent. Programs that ignore this reality watch traffic erode silently across the library. Programs that overreact (rewriting everything on calendar) burn editorial capacity that should be producing new flagship work. The discipline is in the middle: refresh what matters when signals say so, and document the decisions so the program is auditable.

This skill is the program-level refresh discipline across the whole content library. It builds on pillar-content-architecture's hub-level refresh consideration (refresh as ONE consideration in hub design) and editorial-qa's pre-publish quality gate (this skill is post-publish lifecycle, not pre-publish QA). Together those skills cover content quality at the moments quality decisions get made; this skill covers the moments between, when content is in the field and decaying or holding.

The voice is the senior editorial leader who has watched refresh programs fail in both directions and who has shipped the systems that produced durable refresh discipline.

When to use this skill: building a refresh program from scratch, auditing why refresh work is happening but traffic is not responding, designing the prioritization that keeps refresh tractable across a 200-piece or 2,000-piece library, or fixing a refresh program that is eating editorial capacity without clear results.

What this skill covers

This skill spans the post-publish lifecycle of content. The content suite distinction:

• content-strategy is program scope: what to produce.
• pillar-content-architecture is HUB scope; refresh appears as ONE consideration in hub design.
• content-brief-authoring is per-piece scope at production time.
• content-and-copy is execution scope at production time.
• editorial-qa is gate scope: pre-publish verification.
• `content-refresh-system` (this skill) is lifecycle scope: program-level refresh discipline across the whole content library, after pieces are in the field.

The audience: editorial leads, content directors, content ops managers, in-house teams running content libraries of 50-5,000+ pieces, agencies maintaining client content programs across years.

What is not in scope: writing the refreshed pieces themselves (that is content-and-copy), the brief that drives the refresh (that is content-brief-authoring), the pre-publish gate on the refreshed piece (that is editorial-qa). This skill is the prioritization and lifecycle discipline; the actual content work plugs into the existing skills.

Refresh-everything vs refresh-nothing vs triaged-refresh

The keystone framing. Two failure modes plus the discipline.

Refresh-everything. Full rewrites on calendar. Every piece gets a refresh on a 12-month or 18-month rotation regardless of signals. Output: editorial capacity consumed by maintenance work that often was not needed, while strong pieces are touched into worse versions and weak pieces consume the same effort as flagship pieces. Cost: opportunity cost on new flagship production; maintenance fatigue in the editorial team; some pieces that were performing well get diluted by unnecessary edits.

Refresh-nothing. Set-and-forget. Pieces ship and never get touched again. Output: traffic decays silently across the library as facts go stale, competitors publish stronger pieces, and SERP intent shifts away from the piece's framing. The library's compounding value erodes invisibly until an algorithm update or a competitor's flagship piece exposes the rot. Cost: cumulative traffic loss that nobody attributes to refresh failure because the loss is gradual; trust loss when readers find stale facts in pieces they expected to be current.

Triaged-refresh. Refresh what matters when signals say so. Audit cadence catches decay early; prioritization concentrates effort on high-value-decaying pieces; weak pieces get refresh-vs-merge-vs-delete dispositions instead of automatic refresh; the program is auditable because every refresh decision was a deliberate response to specific signals. Output: editorial capacity preserved for new production; the library's compounding value protected; refresh work is seen, understood, and measured.

The litmus test. Ask of any refresh decision: what signal triggered this refresh, what depth of refresh did the signal warrant, what outcome do we expect, and how will we measure whether the refresh worked? If the answer is "it was scheduled" or "we always refresh after 12 months," the program is on calendar rather than on signal.

Refresh signals

Five categories of signal that trigger refresh consideration. Pieces that show no signals do not need refresh; pieces that show multiple signals are higher priority.

Traffic decay. Organic traffic to the piece is trending down over a 90+ day window beyond the seasonal baseline. The decay can be slow (5-10% over a year) or sharp (40%+ in a month after an algorithm update). Slow decay typically indicates content drift; sharp decay typically indicates external change.

Ranking drops. The piece is losing position on its target keywords. Drops from page 1 to page 2-3 are particularly consequential; drops within page 1 (position 3 to position 7) are less so but still tracked. Persistent ranking drops over 30+ days indicate a real shift, not search-result volatility.

Factual staleness. The piece contains statistics, references, examples, or claims that are dated. A 2018 stat in a 2026 piece on a fast-moving topic is staleness; a piece that references defunct products or platforms is staleness; a piece that uses pre-shift framings ("AI is starting to influence search" in 2026) is staleness.

SERP intent shift. The dominant SERP format for the target keyword has changed. The piece was written when articles ranked for the keyword; now the SERP wants product comparisons, video, or AI-overview-style answers. The piece may still rank but increasingly for the wrong reason.

Content drift. The piece's positioning no longer matches the brand's current positioning. Voice has evolved; the brand's POV on the topic has sharpened or shifted; the piece reads as the brand-of-three-years-ago. Internal signal more than external; readers may not notice but the team will.

The audit. Every piece in the library can be characterized by which signals it shows. Pieces with zero signals are stable; pieces with one or two signals warrant attention; pieces with three or more signals are typically in active decay.

Detail in `references/refresh-signals-checklist.md`.

The audit cadence

How often to look. Two cadences with different tradeoffs.

Quarterly audit. A formal review of the content library every 90 days. The team pulls traffic, ranking, and recency data; reviews each piece against the signals; assigns dispositions (refresh, merge, delete, or leave alone). Output: a refresh queue with priorities and a backlog of merge/delete decisions.

• Strength: predictable, auditable, fits naturally into editorial calendar planning.
• Weakness: 90-day delay in detecting sharp decay; piece that lost 40% traffic in week 2 of a quarter is in decay for 75 days before the audit catches it.

Continuous monitoring. Automated detection of traffic and ranking shifts with alerts when thresholds are crossed. Pieces that lose more than X% traffic in Y days trigger a review.

• Strength: catches sharp decay early; allows fast response to algorithm updates.
• Weakness: requires monitoring infrastructure; can produce alert fatigue if thresholds are too tight; misses slow decay that does not cross thresholds.

The hybrid pattern. Most strong refresh programs run both. Quarterly audits catch slow decay, content drift, and pieces that are stable but no longer match the brand's current positioning. Continuous monitoring catches sharp decay and algorithm-update fallout. The two cadences cover different failure modes.

Detail in `references/audit-cadence-patterns.md`.

Refresh prioritization

Prioritization is the discipline. Most libraries have more pieces showing signals than the team has capacity to refresh. Prioritization concentrates effort on the pieces where refresh produces the most value.

The 2x2 matrix: piece value (high vs low) crossed with traffic state (decaying vs stable).

High-value, decaying. Top priority. Pieces that drive meaningful traffic, conversions, or topical authority and are losing position. Refresh these first; the traffic loss compounds and the lost equity is hard to recover.

High-value, stable. Monitor; do not refresh proactively. Pieces that are performing should not be touched without clear signal; refresh-everything-on-calendar treats this quadrant the same as the high-value-decaying quadrant and damages performance.

Low-value, decaying. Audit for merge or delete. Pieces with low traffic that are decaying further are usually candidates for merge (consolidate into a stronger sibling piece) or delete (and 301 to the closest sibling). Refresh on these pieces rarely justifies the effort; the underlying issue is usually that the piece never had strong demand.

Low-value, stable. Leave alone. Low traffic is the floor; the piece is not costing anything to keep. Touching these pieces in a refresh program burns capacity for no return.

The matrix shifts the program from refresh-everything to refresh-the-quadrant-that-warrants-it. Detail in `references/refresh-prioritization-matrix.md`.

Refresh depth options

Not every refresh is the same kind of work. Four depth levels.

Light edit. Update statistics, replace dead links, fix factual errors, swap dated examples. Keeps the piece's structure and argument intact. Time investment: 30-90 minutes per piece. Use when the piece is structurally sound and only the surface details have aged.

Substantial revision. Light edit plus rewrite of 1-3 sections that have aged badly. Update the introduction or closing. Add coverage of topics that emerged after the piece was written. Time investment: 2-4 hours per piece. Use when the piece's structure is sound but specific sections have become weak.

Full rewrite. Keep the URL and topic; rewrite the piece end-to-end. Time investment: similar to writing a new piece, sometimes more because of the constraint of preserving the URL and the existing internal links. Use when the piece's structure no longer fits the current SERP intent or the brand's positioning has shifted enough that the piece needs to be re-conceived.

Structural redesign. Full rewrite plus consolidation with sibling pieces, restructuring of internal linking, possible URL change with redirects. Time investment: a multi-piece project. Use when refresh is part of a larger structural change in the content library (a hub being rebuilt, a category being consolidated).

The depth-decision discipline. Match depth to signal strength. Sharp decay or major SERP intent shift may warrant full rewrite; slow decay with stale stats may warrant only a light edit. Treating every refresh as a full rewrite is refresh-everything energy in a different shape.

Detail in `references/refresh-depth-decision.md`.

Refresh vs merge vs delete decisions

Not every piece in decay should be refreshed. Three dispositions.

Refresh. The piece has a clear topic, real demand, and either a strong-enough current position to recover or a strong-enough strategic role in the library to justify the work.

Merge. Two or more pieces are competing for the same query, splitting authority and confusing the reader. Combine into one stronger piece; redirect the merged URLs.

Delete. The piece has no real demand, the topic is no longer relevant to the brand's positioning, or the piece is a low-quality artifact from an earlier era of the program. Delete and redirect to the closest sibling or, if no sibling exists, to the relevant hub or category page.

The decision criteria. Refresh when the piece has demand and a path back. Merge when authority is being split. Delete when there is no path forward and the piece is not worth maintaining.

The under-recognized failure mode: refreshing pieces that should have been merged or deleted. The team spends hours improving a low-value piece that even at its best will not recover meaningful traffic, while a merge candidate that would have produced a stronger consolidated piece sits unaddressed.

Detail in `references/refresh-vs-merge-vs-delete.md`.

Refresh execution patterns

Who does the work, how it ships.

Ownership. A single owner per refresh, not a committee. The owner is accountable for the outcome and runs the work through to ship. Refreshes that pass through multiple hands without an accountable owner often get partially done and then stall.

Editorial integration. Refreshes typically run through the same editorial workflow as new pieces (brief, draft, edit, QA gate, publish), scaled to the depth chosen. A light edit may skip the brief and go straight to edit; a full rewrite goes through every step.

Capacity allocation. Refresh work consumes editorial capacity that would otherwise produce new pieces. The capacity decision is a real tradeoff: a team producing 20 pieces per quarter might allocate 5 of those slots to refresh work, leaving 15 for new production. The split varies by program maturity (older libraries often need 30-40% refresh allocation; newer libraries may need 5-10%).

Refresh batching. Some teams batch refresh work into dedicated weeks or sprints; others integrate one refresh per week into the steady-state production cadence. Batching produces focus but interrupts new production; integration sustains new production but slows refresh velocity. Either works; the failure mode is no allocation discipline at all, which produces refresh work happening in the cracks at unpredictable cadence.

Detail in `references/refresh-execution-patterns.md`.

Re-promotion after refresh

Refreshed pieces need to signal to search engines and audiences that they have been updated.

To search engines. Update the modified date in schema markup. Update the published-or-modified-date in the visible metadata. Submit the URL for re-crawl through Search Console. Some teams update the URL minimally (e.g., adding a year to the slug for evergreen pieces), but URL changes carry redirect risk and should be reserved for substantial-revision or full-rewrite refreshes.

To audiences. Re-share the refreshed piece on the channels where the original landed: newsletter, social, syndication partners. Treat the refresh as a publication event, not as silent maintenance. The re-promotion is part of the refresh's value proposition: the piece earns new attention as well as preserved search position.

Internal linking refresh. Pieces that link to the refreshed piece may benefit from anchor-text updates if the refreshed piece's positioning shifted. Sister pieces that should now link to the refreshed piece can be updated to do so.

The refresh that nobody tells anyone about. A refreshed piece that is not re-promoted often performs only marginally better than the original. The refresh's signal to search engines is the modified date; the refresh's value to the program is partly the audience re-engagement.

Detail in `references/re-promotion-after-refresh.md`.

Refresh tracking and effectiveness measurement

The discipline that prevents refresh-theater: tracking which refreshes worked, which did not, and what the patterns reveal.

Per-refresh tracking. Each refresh is logged with: the signals that triggered it, the depth chosen, the date shipped, the predicted outcome, the actual outcome at 30 days and 90 days post-refresh. The log is the refresh program's evidence base.

Effectiveness metrics. The primary metrics depend on the refresh's purpose. Traffic-decay refreshes track post-refresh traffic recovery; ranking-drop refreshes track post-refresh ranking position; content-drift refreshes track post-refresh engagement metrics (time on page, return visits) more than search metrics.

Pattern detection. The log reveals patterns over time. Some signal types produce reliable recovery; others rarely produce recovery and indicate a deeper problem (the topic itself is dying; the brand's positioning on the topic is wrong; competitors are too strong to displace). The patterns inform program-level decisions.

The refresh-that-did-not-work review. Refreshes that did not produce the expected recovery should get a structured review. Was the depth wrong? Was the merge or delete decision the right disposition that we did not take? Did the underlying problem turn out to be something refresh cannot fix?

Detail in `references/effectiveness-measurement.md`.

Common failure modes

Rapid-fire. Diagnoses in `references/common-refresh-failures.md`.

• "We refresh every piece annually and traffic is still declining." Refresh-everything pattern; the calendar-based work is not catching the actual decay signals.
• "We have not touched the library in 18 months and traffic has eroded 30%." Refresh-nothing pattern; the decay went uncaught.
• "We refresh pieces but the traffic does not come back." Wrong disposition; the pieces were merge or delete candidates, not refresh candidates.
• "Our refresh queue is 200 pieces deep and growing." No prioritization; everything that shows any signal goes in the queue regardless of value.
• "We refreshed a flagship piece and traffic dropped." Refresh damaged a piece that was performing; the refresh was triggered by calendar rather than signal.
• "The team is exhausted from refresh work." Capacity allocation is wrong; either refresh ratio is too high, or new production is suffering, or the depth choices are over-investing.
• "We do not know if our refreshes are working." No tracking; refresh work happens but its effectiveness is invisible.
• "Some pieces always get refreshed; others never do." The signal triage is informal and inconsistent; some pieces are getting attention because they are visible, not because they are most decayed.
• "We refreshed a piece and forgot to re-promote it." Refresh-without-re-promotion; the piece's modified date updated but no audience or channel re-engagement happened.
• "Our quarterly audit catches things 75 days late." Quarterly cadence alone is missing sharp decay; add continuous monitoring for traffic-loss thresholds.
• "We refresh sister pieces but the hub orchestration is unchanged." Pieces refreshed in isolation when the hub-level architecture also needed updating; coordinate with pillar-content-architecture discipline.

The framework: 12 considerations for content refresh

When designing or auditing a refresh program, walk these 12 considerations.

1. Triaged-refresh, not refresh-everything or refresh-nothing. Refresh on signal, not on calendar.
2. Signal categories named. Traffic decay, ranking drops, factual staleness, SERP intent shift, content drift.
3. Audit cadence committed. Quarterly audit plus continuous monitoring; both running.
4. Prioritization matrix applied. High-value-decaying first; low-value-decaying audited for merge or delete.
5. Depth matched to signal. Light edit, substantial revision, full rewrite, structural redesign.
6. Disposition decided per piece. Refresh, merge, or delete; not all decay warrants refresh.
7. Single ownership per refresh. Accountable owner runs the work to ship.
8. Capacity allocation explicit. Refresh ratio of editorial capacity is a real number, planned.
9. Re-promotion built into the workflow. Schema, visible date, search-engine resubmit, audience re-share.
10. Per-refresh tracking. Signals, depth, outcomes logged for pattern detection.
11. Effectiveness measurement. Recovery tracked at 30 and 90 days; patterns inform program decisions.
12. The-refresh-that-did-not-work review. Failed refreshes get structured review; lessons compound.

The output of the framework is a refresh program that is auditable, capacity-respecting, and producing visible value for the library's compounding equity.

If required data is unavailable

This skill's output depends on data, measurements, or tool results it cannot generate on its own. When a required input, tool, or data source is unavailable or unverifiable, the sanctioned output is the deliverable with the gap stated: what was needed, what was actually obtained or verified, and which parts of the output are affected. Fabricating, estimating, or interpolating a required number to complete the deliverable is never sanctioned. A stated gap is a complete answer.

Reference files

• `references/refresh-signals-checklist.md` - Five signal categories with detection patterns. Traffic decay, ranking drops, factual staleness, SERP intent shift, content drift. The audit pattern that surfaces signals across the library.
• `references/audit-cadence-patterns.md` - Quarterly audit vs continuous monitoring vs hybrid. Tradeoffs, integration patterns, alert-threshold design.
• `references/refresh-prioritization-matrix.md` - 2x2 matrix with quadrant strategies. High-value-decaying as top priority; low-value-decaying audited for merge or delete; the discipline of NOT refreshing the high-value-stable quadrant.
• `references/refresh-depth-decision.md` - Light edit, substantial revision, full rewrite, structural redesign. Time investment per depth, signal-to-depth matching, depth-creep anti-pattern.
• `references/refresh-vs-merge-vs-delete.md` - Disposition criteria. When to refresh, when to merge, when to delete and redirect. The under-recognized failure of refreshing pieces that should have been merged.
• `references/refresh-execution-patterns.md` - Single owner per refresh, editorial-workflow integration, capacity allocation, batching vs integration tradeoffs.
• `references/re-promotion-after-refresh.md` - Schema markup, visible-date update, search-engine resubmission, audience re-share, internal linking refresh.
• `references/effectiveness-measurement.md` - Per-refresh tracking, 30/90-day recovery measurement, pattern detection, the refresh-that-did-not-work review.
• `references/common-refresh-failures.md` - 11+ failure patterns with diagnoses and fixes.

Closing: refresh is content's immune system

A content library is a long-running system. The pieces in it interact with search algorithms that change, audiences that shift, brands that evolve, and competitors that publish. Set-and-forget treats the library as a static asset and watches it decay. Refresh-everything treats it as a maintenance project and burns capacity that should be producing new flagship work.

The discipline is the immune system: signals are detected early, prioritization concentrates effort where the value is highest, depth matches signal strength, dispositions include merge and delete (not just refresh), and the work is tracked so the program learns. Programs that run this discipline preserve the library's compounding value. Programs that do not watch the library erode and discover the loss only when an algorithm update or a competitor's flagship piece exposes how far the rot has spread.

When in doubt about whether a refresh program is ready, ask: does the program detect signals, prioritize on value, match depth to signal, decide between refresh and merge and delete, allocate capacity explicitly, re-promote the refreshed pieces, and track effectiveness? If yes to all of those, the program is real. If no to any, the gap is where decay will compound.