A content audit SEO process for finding posts that are quietly losing traffic, diagnosing why each one decayed, and deciding refresh, prune, or merge.
Most SaaS blogs find out a post is losing traffic by accident, months after it started. Someone notices a lead-gen page isn't converting the way it used to, pulls up Search Console out of habit, and finds a decline that's been running quietly for a quarter. A content audit SEO process is what catches that before the accident: a recurring pass that finds which posts are decaying, works out why, and decides what to do about each one before you touch a single word.
That last part is the piece a lot of "refresh your old content" advice skips. Refresh is the fix for exactly one diagnosis. If you refresh a page that's actually decaying because a sibling post on your own site is cannibalizing it, you've added new sections to a page that was never going to recover its rankings until the cannibalization gets fixed. If you refresh a page that's losing clicks because a SERP feature moved in above it, you'll spend an afternoon on new stats and get nothing back. The audit exists to sort that out before you commit the work, and it hands off to three posts on this blog that each own the fix for one diagnosis: content refresh strategy 2026 for staleness, content pruning for AI-era SEO for pages with nothing left to save, and keyword cannibalization for pages competing with your own site.
A content audit run once a year catches damage, not decay. By the time an annual review flags a page, it's usually been losing traffic for two or three quarters, which is most of the compounding value a faster catch would have protected. Treating the audit as a recurring system, the same way you'd treat a refresh cadence or a publishing calendar, is what turns "we should really clean up the blog" into something that actually happens.
The system doesn't need to be heavy. A quarterly pass over your top 50-100 posts by historical clicks, with a lighter monthly check on whatever's highest-traffic, catches almost everything that matters. What it needs is a fixed trigger, a date on the calendar or a step in your existing content pipeline, not a task that only runs when someone remembers to be worried about the blog. If you're running this alongside a regular refresh and pruning cadence already, the audit is the layer that decides which posts feed into which of those two pipelines, so neither one runs on guesswork.
Content decay shows up as a gradual decline in one page's clicks or rankings, distinct from a sudden site-wide drop tied to a known algorithm update. The signal lives in Google Search Console, and reading it correctly is what separates a real decay diagnosis from reacting to normal week-to-week noise.
Pull the Pages report for your top posts by historical clicks, compare the trailing 8-12 weeks against the prior period, and set a minimum sample, at least 200 impressions or 100 sessions in the window, before you act on anything. Rankings wobble for reasons that have nothing to do with a post going stale, so a threshold matters more than the exact percentage you pick. A page that dropped from 40 clicks a week to 35 isn't decaying, it's noise. A page that dropped from 400 to 150 over two months, with a matching position slide, is a real candidate.
This is the diagnostic step most audits skip, and it's the one that decides whether a refresh will even help. Ahrefs frames it as three distinct patterns in the same two metrics: impressions and clicks both falling is classic decay, you're losing visibility and the clicks that come with it. Impressions down with CTR up means you've lost position but the people who still find you are engaged, a potentially recoverable ranking loss. Impressions flat with CTR down means you're still ranking, but something changed in the results page around you, an AI Overview, a featured snippet, or a competitor's rich result eating the click before it reaches your listing (Ahrefs).
That third pattern is the one worth sitting with, because it's where a refresh does nothing. If Google is still showing your page in the same position and impressions haven't moved, no amount of new sections or updated stats puts the click back. The problem isn't your content, it's the SERP shape around it, and the honest answer is sometimes there's no on-page fix at all.
Once a page clears the noise threshold, the audit's real job starts: working out which of three causes is behind the drop, because each one points at a different fix.
Sometimes the query you rank for changes shape entirely, and no version of your existing post was ever going to hold its position. Ahrefs documents a concrete case: for "how to start a blog," Reddit's share of page-one results rose from 34% to 60% year over year, while traditional "how to" guides fell from 27% to 22% over the same window (Ahrefs). That's not a staleness problem a rewrite fixes. Google decided the query is better served by forum threads than by structured guides, at least for that period, and a beginner-guide post competing in that space is fighting the SERP's composition, not its own content quality.
Catching this diagnosis means actually looking at what's ranking above you now, not just at your own trend line. If the top results have visibly shifted format, forums, video, a different content type entirely, since you last checked, that's the signal, and it changes what "fixing" the page even means.
Ahrefs' second diagnostic checks your own edit history against the decline date, and it splits into two distinct patterns that both look like decay from the traffic graph alone but mean different things: traffic declined with no preceding content change, which is classic staleness, or traffic declined right after you edited the page, which means the edit itself degraded something that was working (Ahrefs). The second pattern is the one teams rarely check for, because the instinct after a drop is to assume the content aged out, not that a well-intentioned tweak broke it.
Roxana Stingu, Head of Search & SEO at Alamy, has described how far Google's own systems now go on this exact question: "Google spent a lot of time refining how it handles [content updates], and it can look back across multiple versions of a page and assess whether a change is meaningful enough, outside of just getting a new timestamp" (via Ahrefs). That cuts both ways. It means a real, substantive update is more likely to register as one. It also means a cosmetic edit, a bumped date with no real change underneath it, is exactly the kind of thing Google's version history is built to see through.
The third cause is the one an audit that only looks at a single page's trend line will miss entirely: the page isn't decaying because it got worse, it's decaying because a second page on your own site started outranking it. A 2026 study that analyzed 2,500 keywords across 100 high-authority sites via the Ahrefs API found 68% of sites showed significant keyword cannibalization, defined as five or more of their own URLs ranking for the same keyword, while only 12% kept tight one-to-two-URL control (Studio36 Digital). Cannibalization at that scale isn't a rare edge case in a content audit, it's close to the norm.
Confirm this before you diagnose staleness on a declining page: open Search Console's query report, filter to the page's main keyword, and check whether a second URL from your own domain is also drawing impressions on it, especially if the ranking URL for that query keeps swapping week to week. If it is, refreshing the declining page won't fix anything, because the traffic didn't leave your site, it moved to your other post. Our keyword cannibalization guide covers the fuller detection and fix, consolidate the two pages or differentiate their intent, once the audit flags the overlap.
One diagnosis this section doesn't cover, because it needs a different trigger entirely: a tutorial's prose can stay accurate while its code samples quietly break, and that failure produces no Search Console signal at all until a reader hits a dead snippet. Tutorial content decay needs a changelog-driven check tied to your own release notes, not the traffic-based audit this post is built around.
Once you know why a page decayed, the decision is close to mechanical. Ahrefs' framework maps cleanly onto the three causes above: if the keyword is still relevant and the content is just outdated, update it; if two pages compete for the same keyword and one is stronger, consolidate the weaker into it; if the keyword no longer fits your strategy but the page still carries backlinks, redirect it; if it's a low-value keyword with minimal traffic and few backlinks, prune it (Ahrefs).
| Diagnosis | Signal | Decision |
|---|---|---|
| Staleness, keyword still relevant | Content changed or aged; no cannibalization | Update (refresh) |
| Cannibalization | A stronger sibling page ranks for the same query | Consolidate into the stronger page |
| SERP or strategy shift, backlinks intact | Keyword no longer fits, but the page has link equity | Redirect to a relevant page |
| No remaining value | Minimal traffic, few or no backlinks, low-value keyword | Prune |
The full decision framework for the prune branch, including the 404 vs. noindex vs. 301 call, lives in content pruning for AI-era SEO; this audit's job is getting a page correctly sorted into that branch in the first place, not re-deriving the technical handling once it's there.
The instinct once you've built a decay list is to refresh everything on it, and that instinct is usually wrong. Not every declining page earned enough to justify the work: no backlinks, no conversions, and traffic that's been flat near zero for a full year is a page with nothing left for a refresh to protect. SEO consultant Jes Scholz tested this directly on a real estate client's site by deleting over 60% of its articles. Most of the articles that stayed saw small performance gains, which Ahrefs summarizes as adding up to "a notable boost in clicks," and Scholz's own read on the trade-off was that it was "well worth the risk" (via Ahrefs). A blog audit that treats every decayed page as a refresh candidate misses that a chunk of the list is actually a prune list wearing a refresh list's traffic graph.
Once a post is sorted into the update branch, the actual refresh work is the recipe covered in content refresh strategy 2026: new sections closing real gaps, stale stats replaced with current, sourced numbers, and every claim re-verified, not just the new ones. What that post assumes, and what's worth spelling out here, is what an AI writer needs fed into it before it drafts a refresh at all.
A refresh draft that ignores the post it's replacing isn't a refresh, it's a rewrite wearing the same slug. The original post, its existing internal links, and a sample of its voice all need to go into the drafting context, not just the target keyword and the gap you're closing. Skip this and you get a section that reads like it was bolted on from a different blog, with links that point nowhere your original post pointed and phrasing that doesn't match the paragraphs around it. The internal links matter specifically: those anchors carry the authority your original post already built, the same authority internal linking automation covers on the publishing side, and a refresh that silently drops them is giving that authority up for no reason.
The same model that drafts a refresh checking its own work is grading the draft against the assumptions it used to write it, which is a weaker check than it looks like from the outside. Research on multi-agent review pipelines describes this as bias inheritance: a reviewer sharing context with the generator tends to confirm the generator's errors rather than catch them, and self-preference research separately finds LLM judges favor outputs that resemble their own style, independent of whether the content is actually correct. Our multi-agent content review post covers the generator, critic, judge pattern in depth; the short version for a refresh specifically is that the pass checking the new sections against the original's facts and voice needs to run with no shared context from the drafting session, or it isn't really an independent check.
This is the part that separates a content audit built for AI-assisted publishing from one written for a team that only ever hand-edits posts. An AI-drafted refresh isn't safer just because a fact-checking pass ran on it. It's safer when a human reviews it the way they'd review any other change to a system they're responsible for: as a diff, with an approval step, and a way back out if it's wrong.
Open the refresh as a pull request against the file that's already live, not as a new document to evaluate cold. A diff view answers the question that actually matters for a refresh: what changed, and does every line of the change hold up. Reading the whole post as if it were brand new buries the two or three sections that actually moved inside a wall of text that's identical to what's already published, and that's exactly where a reviewer's attention goes slack. AI content governance covers why this record matters beyond the immediate review too: a pull request already gives you the who-changed-what trail that proves a human signed off, which is the same record you'd want if a regulator or a customer ever asked how a specific page got edited.
A refresh that adds new, sourced facts next to old, unverified ones still ships a liability, because the reader can't tell which sentence went through a fact-check and which one has been sitting there since the post's first draft two years ago. The re-verification pass has to cover the whole page, not just the new paragraphs: every claim, every link, checked against a current source, the same discipline our editorial review process for AI content's E-E-A-T lays out for a first draft. Treat anything that fails that check as a blocker on the merge, whether it's in a section you just wrote or one you didn't touch at all.
Not every refresh works. If a post's traffic keeps declining after the update, or drops further, the fix isn't a second, bigger refresh stacked on top of the first one, it's a revert. A git-based blog already gives you this for free: the previous version of the file is sitting in history, and reverting to it is the same operation as backing out any other bad change. Treat a refresh's first few weeks post-merge as a watch window, using the same Search Console pull that flagged the original decay, and if the numbers move the wrong way, roll back rather than layering a second guess on a first one that already missed.
An audit that runs this loop quarterly stops treating decay as a surprise and starts treating it as a known, measured, recurring cost of running a blog, one with a fixed process for catching it early and a fixed process for deciding what to do about it.
A content audit only pays off if the refresh it produces gets reviewed properly. Lyra watches your published posts for decay, drafts the refresh in your blog's voice with every claim re-verified, and opens it as a pull request you review like any other diff.
Step by step
Pull decay candidates from Search Console
Export the Pages report for your top 50-100 posts by historical clicks, compare the trailing 8-12 weeks against the prior period, and flag anything with a real decline above your noise threshold.
Read impressions against CTR to separate decay from a SERP feature
For each flagged page, check whether impressions and CTR are both falling (decay), impressions are down with CTR up (a recoverable ranking loss), or impressions are flat with CTR down (a SERP feature taking the click, not real decay).
Check content-change history against the decline date
Look at whether the page changed right before the drop, which points at an edit that broke something, or whether it declined with no changes at all, which points at staleness or a shift in the query itself.
Run a cannibalization check before you diagnose staleness
Confirm in Search Console whether a second page on your own site is now ranking for the same query. A page can look stale when the real cause is a sibling post eating its rankings.
Sort each candidate into update, consolidate, redirect, or prune
Match the diagnosis to the fix: relevant keyword with outdated content gets an update, two pages on one keyword get consolidated, a keyword that no longer fits gets redirected if it has backlinks, and a low-value page with minimal traffic gets pruned.
Review an AI-drafted refresh as a diff against the live post
Read the refresh the way you'd read a pull request: what changed, what didn't, and whether every claim in both the new and untouched sections still holds up. Keep a rollback path in case the refresh underperforms.
FAQ
A content audit is the diagnostic pass that finds which posts on your blog are losing traffic or rankings and figures out why, before you decide what to do about any of them. It comes before a refresh, a prune, or a merge: it's the triage step that tells you which of those three a given post actually needs, using Search Console data, content-change history, and a cannibalization check rather than a gut call.
Quarterly for a blog publishing regularly, with a lighter monthly pass over your highest-traffic pages if you're shipping weekly. An annual audit misses too much: a post can lose most of its traffic over two quarters before a once-a-year review catches it, by which point you've lost most of the compounding value a faster catch would have preserved.
Content decay is a gradual decline in one page's traffic over weeks or months, usually caused by staleness, a SERP change, or your own cannibalization. An algorithm update is a sudden, site-wide shift that hits many pages at once, on a date you can usually match to a known Google rollout. If one post is sliding alone over a quarter, that's decay. If dozens of pages move together on the same week, check the update calendar first.
Pull the page's impressions and CTR from Search Console and compare them over the decline window. Impressions and CTR both falling is classic decay: you're losing visibility. Impressions flat with CTR falling means you're still ranking but something in the results page around you changed, an AI Overview, a featured snippet, or a competitor's rich result eating the click before it reaches you. The fix for the second case is different: no amount of refreshing your prose puts a click back that a SERP feature is intercepting.
Built by the tool you're reading about
Lyra finds the topics worth ranking for, writes them in your repo's voice, fact-checks every claim, and opens a pull request scored and ready to merge. You review and hit merge. Want to see what she'd write for you? Start free with three posts, no card.
Keep reading
White-label AI content breaks when one shared tool runs five-plus client blogs. What an agency needs instead: per-client repos, keys, and PR review.
How many blog posts per month should a SaaS company publish? The data says 2-4 focused posts beat 16 generic ones, and how to set a cadence you can sustain.
Pricing page SEO: how to structure prices so AI Overviews and ChatGPT quote them right, plus the verification habit that stops a cited price going stale.