Verified against Claude · 2026-08-02
Diagnose and refresh a post that's been sliding instead of rewriting it blind
Diagnoses the actual cause behind a slipping post — content decay, competitive displacement, cannibalization, or a technical issue outside the content itself — before recommending a fix, instead of defaulting to "add more words."
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are diagnosing why a published post's performance has slipped, before recommending any refresh. Different causes need different fixes, and rewriting the body text is the wrong response to at least two of the likely causes below — the diagnosis has to come first. POST CONTENT A 2024 post titled "The Complete Guide to Email Deliverability," 2,800 words CURRENT ANALYTICS Impressions flat over 6 months, average position dropped from 4 to 11, CTR dropped from 6.1% to 1.8% — the position drop coincides with two new competing guides published by larger sites in the same window. ORIGINAL PUBLISH DATE March 2024 WHAT'S CHANGED SINCE PUBLISH Two competing "deliverability guide" posts from larger email-marketing platforms published in the last 4 months, both include an interactive spam-score checker tool embedded in the post. TARGET KEYWORD email deliverability guide DIAGNOSTIC RULES Separate the possible causes before recommending anything: content decay (the post's facts, screenshots, or examples are stale relative to a topic that's since moved on); competitive displacement (a newer or more thorough page has since outranked this one, and the gap is relative, not that this post got worse); cannibalization (another page on the same site now competes for the same query and traffic is likely split, not lost); or a non-content issue (indexing, a technical regression, a lost backlink, a SERP feature change) that a body-text rewrite would not fix at all. Use the analytics notes to identify which of these is most likely before proposing a fix — a pattern of stable impressions with falling click-through rate points at the title and meta description, not the body; a pattern of falling impressions with position holding steady points at a technical or indexing issue, not content quality; a pattern of falling position specifically on this keyword while impressions hold points at competitive displacement, which does call for a content refresh, but a targeted one addressing what specifically changed in the competitive set, not a generic top-to-bottom rewrite. Check the actual queries driving whatever traffic remains, not just the target keyword in isolation — if the post is now ranking for a related but different query than the one it was written for, that's itself a diagnosis, and the fix is realigning the content to what it's actually being found for, or accepting the drift and optimizing further in that direction, not blindly re-targeting the original keyword harder. Weigh what's changed since publish against the diagnosis — a competitor's specifically named new content, a product change that made an existing section wrong, an algorithm update the team is aware of — since a diagnosis with no plausible external cause behind it deserves more scrutiny before acting on it. Preserve the existing URL and publish date's accumulated authority unless there's a specific, named reason a new URL would be justified; recommend against a fresh URL by default. State the fix plan ranked by likely impact, not as an exhaustive checklist of every possible SEO improvement — a team executing a refresh needs to know what to do first, not everything that could theoretically help. OUTPUT FORMAT 1. The most likely cause, named specifically, with the analytics evidence that points to it. 2. What that specific cause rules out — the fixes that would not actually help here even though they're generically good practice. 3. The fix plan, ranked by likely impact. 4. Any competing hypothesis you considered and ruled out, and why.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Separating content decay, competitive displacement, cannibalization, and non-content technical causes before recommending a fix matters because these four causes point to genuinely different, sometimes opposite remedies, and the single most common mistake in post-performance triage is defaulting to "refresh the content" regardless of which one actually applies — a rewrite spends real time and does nothing for a post that dropped in position because a competing site lost a backlink deal or because Google rolled out an algorithm update unrelated to on-page quality, and worse, it can look like it worked simply because rankings fluctuate for unrelated reasons afterward, teaching the team the wrong lesson about what actually moved the number. Reading the specific shape of the analytics pattern — stable impressions with falling CTR versus falling impressions with stable position versus falling position with stable impressions — turns a vague "performance is down" complaint into a diagnosis with an actual mechanism behind it, because each of those three patterns corresponds to a different part of the funnel (the snippet's appeal, the page's visibility, the page's competitiveness) failing, and the analytics data genuinely distinguishes between them if it's read for the pattern rather than just the overall downward trend. Checking what queries are actually driving current traffic, not just the original target keyword's position, catches a specific and easy-to-miss case: a post whose position on its intended keyword has technically fallen but which has organically drifted into ranking well for a related, adjacent query is not necessarily failing — it may simply have found a different, real audience than the one it was written for, and forcing a refresh that re-targets the original keyword harder can actively undo whatever is working about the drift. Recommending against a fresh URL by default addresses a specific overcorrection risk: a URL that's accumulated months or years of backlinks and crawl history carries real, hard-to-replace authority, and a diagnosis-driven refresh should default to preserving that unless a specific, named reason argues otherwise, rather than treating "just start over" as a low-cost option when it usually isn't.
Verified against
Claude Claude Sonnet 5 · 2026-08-02
Perplexity Sonar Pro · 2026-08-07
Changelog
- 2026-08-02 — Initial publish, verified against Claude (Claude Sonnet 5) and Perplexity (Sonar Pro).
Need this built into your business?
If a prompt isn't enough — SEO, built and maintained for you — that's Scult's day job.
EXPLORE SEO
