Content decay is a sustained decline in organic search performance for a page that previously attracted traffic. An old tutorial loses useful clicks because its instructions, examples, or coverage no longer match what readers need.
The useful response is a diagnosis followed by a targeted update. Start with the affected URL in Google Search Console, identify the queries that lost traffic, and check whether the page still solves their problem.
For a developer blog, that might mean replacing an obsolete installation command, testing a code sample against the current SDK, or explaining a migration readers now need. This guide walks through that decision and gives you a refresh brief you can hand to your AI agent.
What content decay looks like
A post's age alone tells you little. A five-year-old explanation of a stable concept may still be useful. A three-month-old integration tutorial can already be wrong.
Look for a pattern across comparable periods. Which pages used to bring qualified readers to your product, and now bring fewer? Which query groups have weakened? Are readers arriving for an answer the article no longer provides?
A post that has never earned impressions needs a different investigation. Our guide to blog posts that aren't indexed covers one possible starting point.
Find declining pages in Search Console
Use the Search Console Performance report to compare search results over time. Keep the search type, country, and device filters consistent.
- Open Performance and choose a date comparison. Start with two complete, equal-length periods, such as the latest 28 complete days and the preceding 28.
- Select the Pages table and export the comparison.
- Calculate the absolute click change for each URL. Review substantial losses before impressive-looking percentage drops on tiny counts.
- Filter to one candidate URL and examine its Queries table. Record which searches explain the change.
Here is a fictional example, not Blogizi performance data:
| Tutorial | Previous clicks | Recent clicks | Change | First question |
|---|---|---|---|---|
| API authentication guide | 180 | 110 | −70 | Did the authentication flow change? |
| Framework installation guide | 70 | 65 | −5 | Is this normal variation? |
| New integration walkthrough | 3 | 1 | −2 | Is there enough history to judge? |
The authentication guide deserves the first look. Its larger loss gives you more to investigate, and its topic may be directly relevant to users of your product.
For a small blog with sparse data, widen the comparison window. A change from three clicks to one doesn't justify a rewrite on its own.
Check the cause before rewriting
Google's guide to debugging search traffic drops recommends investigating technical problems, ranking changes, and shifts in demand. Use a longer history to check seasonality.
| Pattern | Investigation |
|---|---|
| Many pages decline around the same date | Check deployments, indexing reports, and search update timing. |
| One tutorial declines on queries about setup | Test its setup instructions against the current product. |
| Impressions remain similar while clicks fall | Compare the title, snippet, and current results for the affected queries. |
| A seasonal topic drops at the same time each year | Compare year-over-year demand before changing the article. |
Treat these as investigation paths. A chart cannot prove that an SDK example is obsolete; running the example can.
For a technical tutorial, make a small verification record:
Article: /blog/api-authentication
Reader task: obtain a token and make the first request
Environment tested: [runtime and SDK versions]
First failing step: [command or instruction]
Verified replacement: [working example and source]
Related query: [query from this page's Search Console data]
Keep observations separate from assumptions. “The example returns an error on SDK version X” is actionable. “Google dislikes old posts” gives an editor nothing specific to fix.
Build a content refresh around one reader task
Open the declining article alongside the current documentation for the tool it explains. Then perform the task from a clean starting point.
For an authentication guide, check the sequence: prerequisites, credentials, request, expected response, and common failure. If the reader needs a new permission scope, add it before the command that fails without it. If an endpoint moved, replace the endpoint and its response example together.
Useful refresh work often includes:
- Replacing deprecated commands and testing the replacements.
- Updating screenshots when a changed interface affects the instructions.
- Adding a missing prerequisite or troubleshooting step.
- Removing claims that no longer match the product.
- Linking to the next relevant task on your site.
Record what changed so a reviewer can assess it. A short, tested correction can be more valuable than several new sections.
Google's people-first content guidance asks for original value and warns against changing dates merely to make pages appear fresh. Give the reader a better answer before revising the update date.
Keep the existing URL when you're improving the same article for the same purpose. If you discover two articles serving the same task, review their distinct value and search data before planning a consolidation. Traffic loss alone is insufficient reason to delete either page.
Give your AI agent a specific refresh brief
An agent can help compare documentation, identify stale statements, and propose edits. Supply the existing article and evidence so it can work on the actual problem.
Review this existing tutorial for a content refresh.
Inputs:
- Existing article: [file or URL]
- Reader task: [one concrete task]
- Search Console comparison: [dates, filters, page and query rows]
- Current official documentation: [URLs]
- Tested environment: [versions and command output]
Return:
1. Observations supported by the supplied evidence.
2. Uncertain points that need verification.
3. Proposed edits and the reason for each.
4. A revised Markdown draft and a short change log.
Preserve the existing slug. Do not invent test results, metrics,
or experience. Flag examples you cannot run. Save proposed changes
for review; do not publish or schedule them.
Blogizi's Search Console documentation explains how to connect your property. Its MCP tool can provide cached search performance to your agent; check the returned date range and sync time. Use Search Console exports when the analysis needs historical detail beyond the returned data.
Your agent writes the revision. Review the diff, test the examples, and approve the update before it goes live. For a broader weekly routine, see our Claude SEO workflow.
Measure the update with a change log
Before publishing an approved refresh, save the baseline, affected queries, and exact edits. Choose a review date and keep your comparison filters consistent.
URL:
Baseline dates and filters:
Queries under review:
Problem verified:
Edits made:
Approval and publication date:
Next review date:
Result and remaining uncertainty:
Use the review to decide what to inspect next. A traffic increase after an edit doesn't isolate its cause; search demand and competing pages can change too. Equally, a quiet first week doesn't tell you that a tested correction was pointless.
Common questions
How often should I check for content decay?
A monthly review is a practical starting routine. Also revisit tutorials when a dependency, API, or product workflow changes. Choose the cadence around how quickly your subject changes and how much data your blog has.
Can refreshing a post guarantee recovered traffic?
No. A refresh can make an article more useful, but rankings and demand can still change. Define the problem, verify the fix, and assess the result over time.
Should I refresh an old post or write a new one?
Refresh the existing post when it still serves the reader's task. Create a separate article when the new task deserves a separate answer, then link the two where useful.
Start with one declining tutorial, one verified problem, and one reviewable update. That's a manageable maintenance habit for a blog that sits beside a product you're still building.