When to use this prompt
Quarterly. Or when traffic to older posts has decayed and you have to decide where to spend a fixed amount of editorial time. Most content teams have 50-200 backlog posts and no system for deciding which ones to refresh. They refresh the most recent or the loudest, which is rarely the right answer.
This prompt produces a triage list: refresh first, consolidate, retire, leave as is. The output is meant to drive a single editorial planning meeting.
The prompt
<role>Content strategist triaging a backlog of older blog posts for refresh ROI.</role>
<task>Score each post on the backlog using the input data, classify it on the four-tier action scale, and produce a prioritized refresh list.</task>
<inputs>
<posts>
[FOR EACH POST, PROVIDE:
- URL
- Title
- Publish date
- Current monthly organic traffic (from GSC or analytics)
- Peak monthly traffic (and the month it peaked)
- Top-ranking query
- Current rank for that query
- 1-sentence summary of what the post is about]
</posts>
<topic_clusters>[OPTIONAL: list of pillar topics on your site so the model can identify cluster fit]</topic_clusters>
</inputs>
<scale>
- REFRESH: post is on a high-value topic, has decayed, and a refresh would likely recover or grow traffic. Worth editorial time.
- CONSOLIDATE: post overlaps significantly with another post (or pillar page). Merge content into the stronger URL and 301-redirect this one.
- RETIRE: post is on an off-strategy topic, traffic is negligible, no realistic path to growth. 410 or noindex.
- LEAVE: post is performing acceptably for its topic, or its decay is genuinely market-driven and a refresh would not move it.
</scale>
<instructions>
1. For each post, calculate decay: (peak_traffic - current_traffic) / peak_traffic. Express as a percentage.
2. Classify each post on the four-tier scale. Pick exactly one label per post.
3. For every REFRESH post, recommend one specific update type:
- DATA_REFRESH: numbers, statistics, examples, or screenshots are stale
- SCOPE_EXPANSION: post is too narrow; add 2-3 sections
- INTENT_REALIGN: post targets the wrong intent for current SERP; restructure for current top-of-page format
- INTERNAL_LINKING: post is technically fine but isolated; add internal links from and to it
4. For every CONSOLIDATE post, name the specific destination URL the content should merge into and the redirect to set.
5. For every RETIRE post, name the specific reason. Do not retire a post solely because traffic is low. Retire only if the topic is off-strategy or unrecoverable.
6. After per-post classification, output a top 10 refresh list, ordered by expected ROI.
7. Do not propose new posts in this prompt. The output is triage of existing inventory.
</instructions>
<output_format>
**Per-post classification:**
| URL | Decay | Cluster fit | Action | Update type / destination / reason |
|-----|-------|-------------|--------|------------------------------------|
**Top 10 refresh list (priority order):**
1. [URL] — [update type] — [why first]
2. ...
**Consolidations:**
- [Source URL] → [Destination URL] — [content to merge]
**Retirements:**
- [URL] — [reason]
**Estimated traffic recoverable from top 10 refreshes:** [low / medium / high band, with one-sentence justification. Do not invent a precise number.]
</output_format>How it works
Most content refresh decisions are made on intuition: “this post used to do well, let’s update it.” That captures decayed-but-recoverable posts and misses everything else. This framework forces the team to consider three other actions (consolidate, retire, leave) that often have higher ROI than refreshing.
The four update-type tags (DATA_REFRESH, SCOPE_EXPANSION, INTENT_REALIGN, INTERNAL_LINKING) are the four kinds of refresh work, and each one is a different size of project. INTERNAL_LINKING is a 30-minute task; INTENT_REALIGN is a 4-hour rewrite. Tagging them separately lets you batch the small tasks and schedule the big ones.
The “do not invent a precise number” line in the recoverable-traffic estimate is a hallucination guard. Frontier models will produce confident traffic predictions if you do not block it. The low/medium/high band is honest and actionable; a fake “approximately 1,247 monthly visits” is neither.
Example output
| URL | Decay | Cluster fit | Action | Update type / destination / reason |
|---|---|---|---|---|
| /blog/old-event-tracking-guide/ | 78% | Strong (product analytics) | REFRESH | DATA_REFRESH — examples and screenshots are 2 years old |
| /blog/general-marketing-tips/ | 92% | Off-strategy | RETIRE | Off-cluster, no path to recovery |
| /blog/duplicate-mixpanel-overview/ | 60% | Strong | CONSOLIDATE | → /blog/mixpanel-vs-amplitude/, 301 redirect |
| /blog/recent-product-roundup/ | 15% | Strong | LEAVE | Performing acceptably; market-driven decay |
Top 10 refresh list:
- /blog/old-event-tracking-guide/ — DATA_REFRESH — high-traffic post, 2-hour fix, recovers most decay
- …
Variations
- Single-cluster mode: Run on one topic cluster at a time when you have a large content backlog. Easier to act on a 15-post cluster triage than a 200-post site-wide list.
- Annual archive review: Run on every post older than 18 months once a year. Catches posts no one is thinking about that are quietly hurting cluster authority.
- GSC-data-only mode: When you do not have peak traffic, use only current rank and current traffic. Less precise but faster to assemble inputs.