SEO Recovery Plan: How to Get Lost Traffic Back

An SEO recovery plan is a sequence, and the order matters more than any single fix inside it. Establish when the traffic changed. Work out which pages and which queries lost it. Separate the causes you can prove from the ones you are guessing at. Only then start fixing, biggest loss first. Recoveries stall when the work begins at the last step.

What follows is a plan you can run yourself or hand to whoever does your SEO. It assumes Search Console access and a developer who will act on what you find. The bulk of it is diagnosis, deliberately, because a confident fix on the wrong cause costs the weeks you needed for the right one.

What recovery means, and the question to settle first

Settle one thing before you plan anything: whether the traffic was ever really yours. Losses come in kinds that need different answers, and treating one kind as another wastes months.

A page that used to rank, still exists, and has slipped is recoverable: the position was earned and something took it away. A spike from a news mention, a one-off seasonal query or a link that has since gone is a different animal, because there was never a stable position underneath it. Traffic to URLs that no longer exist sits in between, and only returns if the content returns somewhere Google can reach.

Pick your baseline now and write it down: the month before the drop, the same quarter last year, or the eight-week average before the change. In six weeks you will be arguing about progress, and an agreed baseline is the difference between a review and a row.

Fix the date before you fix anything

Traffic losses have a shape, and the shape narrows the cause down faster than any tool. A cliff on a single day points at something that happened on that day. Losses that slope away over six or eight weeks point instead at decay, competition or a broad reassessment of what the site is worth.

Take the date from Search Console performance data at daily granularity, not from analytics sessions. Analytics counts every channel and gets distorted by tagging changes, consent banners and bot filtering, so a drop there can be a measurement artefact rather than a search problem. If impressions held steady while clicks fell, the pages are still being shown and the problem lives in the result itself: the title, the snippet, a new SERP feature above you, or a competitor taking the click.

Once you have the date, put it next to every change log you can find: deploy history, CMS revision dates, plugin and theme updates, DNS records, hosting or CDN rule changes, and the dates of confirmed Google updates. A fall that starts the morning after a release is usually yours to fix. One that starts on a quiet Sunday with nothing shipped is usually external. If the site was rebuilt or moved in that window, treat the redesign and migration checks as your first pass.

Reading Search Console in the right order

There is an order to these reports, and it is not the order the menu shows them in. Two of them can end the investigation in a couple of minutes, so they go first.

1. Manual actions. If there is one, nothing else in this article applies until it is cleared.
2. Security issues. A hacked site or a flagged page produces losses that look exactly like an algorithmic drop.
3. Performance, in comparison mode. Compare the 28 days after the drop against the 28 before, then against the same period a year earlier to separate the fall from normal seasonality.
4. Pages, the indexing report. Compare the not-indexed reasons against the previous month and look for a category that has grown.
5. Sitemaps. Check the last read date and whether the discovered URL count still matches what you publish.
6. Core Web Vitals. Rarely the cause of a cliff, occasionally a contributor to a slope.

In the performance comparison, sort by click difference rather than by clicks, and read the page view before the query view. Concentration is the signal you want. If ten URLs account for the bulk of the loss, you have a page-level problem you can fix this month. If everything is down by roughly the same proportion, the problem is site-wide, and no amount of work on individual pages will move it.

Then split branded from non-branded queries. Branded traffic holding while non-branded collapses means the site is still known and no longer considered relevant to the things it used to answer. Both falling together points at visibility, and usually at something technical. Finally, compare position, impressions and clicks. Steady position with fewer impressions means you are matching fewer queries; falling position with steady impressions means somebody outranked you.

Technical faults, outages and hacks that take pages out of search

Sudden, deep losses are usually mechanical, and the mechanical causes are a short and well-known list. A staging robots.txt shipped to production. A noindex meta tag or an X-Robots-Tag header left behind after a launch. Canonical tags pointing somewhere wrong, which at its worst means every page on the site declaring the home page as its canonical version.

Redirects deserve their own look after any move: a 302 where a 301 was intended, chains three or four hops long, loops that never resolve, and old URLs pointed at the home page instead of the closest match. Then check plain 404s, particularly the ones other sites link to, because those you can reverse the same afternoon.

Rendering is the fault people miss. If the body copy only appears after a client-side fetch, view-source proves nothing useful; use the live test in URL Inspection and read the rendered HTML Google received. Check what the server does under crawl load too: intermittent 5xx responses, a firewall rate-limiting a verified crawler, or a bot filter treating Googlebot as an attacker will remove pages quietly and restore them just as quietly.

An outage that ended before you noticed it still costs you. A host that went down, a certificate that expired, or a DNS record changed during a migration can leave Googlebot meeting errors for a day or two, and URLs get dropped overnight. The crawl stats report holds the evidence: a spike in host status errors, a fall in pages crawled per day, or a run of DNS failures dated to match the fall. The expired certificate is the version people dismiss, because the site loads fine once you click past the browser warning.

A hacked site produces a loss shaped like a penalty. Injected pages, redirects that fire only for visitors arriving from search, and cloaked content served to Googlebot alone all stay invisible when you load the site yourself, so fetch the page in URL Inspection and compare the rendered HTML with your browser. Cleanup means removing the injection, closing the hole, finding the second entry point, then requesting a review if Search Console raised a security issue. Staging leaks are the mirror image: a development copy left crawlable competes with the live site for its own content. Search a distinctive sentence from your home page in quotes and count how many hostnames answer. The fix is authentication on the staging server, not a robots rule, because a blocked URL can still be indexed from a link.

If the traffic you lost was local, check the Google Business Profile before you touch the site. A suspended, merged or duplicated listing removes map results without moving a single classic ranking, and Search Console shows nothing, because it never counted that traffic.

Soft 404s are the last of the common set. A page returning HTTP 200 with an empty result, an error message or a "no products found" state teaches Google that the URL is not worth keeping. If you want a fuller sweep of the mechanics behind all of this, the technical SEO fundamentals cover the checks in more detail than a recovery post can.

When the content stopped matching the search

Slopes rather than cliffs usually come from relevance, and relevance moves without anyone touching your site. Search the query you used to win and look at what ranks now. If the first five results are comparison tables and calculators, and your page is a 900-word essay, the question being asked has changed and your answer no longer fits it.

Decay is the quieter version. The page holds its head term but loses the long tail because the specifics went stale: old prices, superseded versions, dates that have passed, guidance that changed when the rules did. Nothing looks broken; the page just stops being the one worth citing.

Thin and duplicated pages are the other half of this. Location pages that differ only in the town name, product variants each given a URL of their own, tag archives listing the same six posts, and filtered views that mint a new URL per combination leave a site with more pages than it has things to say. Google indexes none of them out of obligation, and the pages you care about lose crawl attention to the ones you do not. Consolidate first, then count.

Cannibalisation is worth ruling out early because the symptom is distinctive. Filter performance by a single query and watch which URL Google serves for it over time. If it alternates between two or three of your pages and none of them settles, you have written the same article more than once and split the signal. The fix is almost never a site-wide rewrite. It is a re-angle of the one page that carried the traffic, plus a decision about what the others are for.

Links you lost, and the repairs that cost nothing

Start with what disappeared rather than what you might build. A backlink tool's lost-links report gives you candidates, and each one needs confirming by loading the page, because the reports carry false positives: a redesign that dropped the reference, a page moved behind a login, a directory that closed. One lost link rarely causes a cliff. A batch of them will flatten a recovery you would otherwise have earned.

One repair in this plan costs nothing at all: fixing links that point at your own 404s. The link already exists and the equity is already pointed at you, and a redirect to the right live page reclaims it without an email to anyone. After that, ask. The site owner who mentioned you two years ago will usually swap a dead URL for a live one if you make it a one-line request.

Disavow is the step recovery plans get wrong, and they get it wrong in both directions. It is not routine maintenance, and a file submitted in a panic throws away signals you will not get back quickly. It is also not something to rule out on principle when somebody has deliberately aimed spam at you. The next section is the test for telling those two cases apart.

Spam links, negative SEO, and when disavow is right

Backlink spam aimed at a site nobody there ordered is real, and it is usually not the reason for a drop. Google discounts the bulk of it before it reaches a calculation, which is why the standard answer is to leave it alone. That answer stops being right once a pattern appears, so the useful question is what a pattern looks like.

Audit before you decide. Start with the links report in Search Console, which shows what Google attributes to you rather than what a third-party crawler found, then run a backlink audit in a tool such as Ahrefs for the detail Search Console omits: anchor text distribution, referring domains plotted by date, and the topical fit of the sites pointing at you. The signal is a spike. Several hundred referring domains inside a fortnight, anchors in a language you do not publish in, anchors on gambling, adult, loan or pharmaceutical terms, footer-wide links across a network of expired domains, one anchor phrase repeated across hundreds of unrelated hosts. Put the date of that spike beside the date of your fall. A spike that started afterwards did not cause it.

Disavow is warranted in two situations and no others. The first is a manual action for unnatural links, where the file is part of the cleanup you submit with the reconsideration request. The second is a spam pattern that lines up with a fall you cannot explain any other way, after removal requests to the hosts have gone nowhere. Outside those two a file costs more than it saves, because you will sweep up links that were working.

The file is plain text, UTF-8, one entry per line. domain:example.com rejects a whole host, which is the right level for a spam domain, and a full URL is for the rare case of one bad page on a site you otherwise want kept. A line starting with a hash is a comment, worth using to date each batch. Uploading replaces the previous file entirely, so keep the master in version control and upload the whole thing every time. Read it again once a quarter, drop domains that have cleaned up, and never list a link you would have been pleased to earn.

Core updates, spam updates and manual actions

These three get treated as one thing in conversation, and they need completely different responses.

A manual action is a human decision, it appears in Search Console, and it is the only case with a formal appeal. Fix the breach, document what you fixed, then file a reconsideration request. Nothing improves until a reviewer accepts it, so this is the one situation where waiting is genuinely the correct next step.

A core update is a reassessment rather than a punishment. There is no switch to flip back, no appeal, and no list of violations, because nothing was violated. The system changed its mind about what deserves to rank for a set of queries, and the site is now judged against that. Spam updates sit between the two: algorithmic like a core update, but tied to a policy you can read and a breach you can remove.

Check the dates before you attribute anything to an update. Confirmed windows run for weeks, so a fall inside one proves little on its own. Look for a site-wide or category-wide shape rather than a handful of URLs, and for movement from other sites in the same results. If only you moved, the cause is more likely on your side.

The plan, in the order the work should happen

Order matters because attribution matters. Six changes shipped in one week produce one outcome and no explanation for it.

1. Stop the bleeding: reverse anything shipped in the window that could plausibly cause the loss. Robots rules, noindex tags, canonical changes, redirect maps, blocked user agents. Reversible changes are cheap and tell you quickly whether you were right.
2. Restore indexation: make sure the pages that mattered are crawlable, indexable, present in the sitemap and returning 200. Request indexing for the biggest losers rather than for everything.
3. Restore the pages that carried the traffic: take the ten URLs with the largest click loss and work only on those until they move. Widening the scope first is how a recovery becomes a permanent project.
4. Rebuild relevance where intent moved: re-angle those pages against what the results now reward, keeping the URL and the accumulated history intact.
5. Recover links, free ones first: broken inbound links to your own 404s, then dead references on friendly sites, then genuine outreach. Nothing bought.
6. Measure one change at a time: leave a gap between batches that is long enough for a recrawl, or you will never know which change did the work.

Internal links are the piece recovery plans routinely skip. If the pages that lost traffic are now three clicks from the home page because a navigation change buried them, no amount of on-page work compensates. A structured pass, of the kind an SEO audit checklist walks through, surfaces that faster than reading templates one at a time.

What not to do while you are recovering

• Do not mass-redirect old URLs to the home page. Google treats an irrelevant redirect as a soft 404 and the signal is lost anyway.
• Do not submit a disavow file on suspicion. Evidence means a manual action, or a dated spam pattern you can point at.
• Do not rewrite every page at once. You lose the ability to attribute any recovery to any change.
• Do not buy links while you are trying to prove your link profile is clean.
• Do not change the URL structure during diagnosis. Add a variable and you cannot read the result.
• Do not delete pages to improve average quality before you know what each one earns in impressions and assisted conversions.

Judging progress, and the honest timeline

Recovery shows up in a fixed order, and knowing that order stops a working plan being abandoned in week two. Crawl comes first: check the crawl stats report and the last crawl date in URL Inspection. Indexation follows, then impressions as the page starts matching queries again, then average position, then clicks. Clicks move last and get measured first.

Timelines depend on recrawl, and recrawl is not yours to control. A fix counts from the moment Google fetches the page again, which for a small business site means weeks rather than days, and longer for anything buried deep in the structure. Requesting indexing helps for a handful of URLs and does nothing at scale.

Core update recovery runs on a different clock, because the reassessment lands with the next update and Google publishes no schedule. Anyone offering a date for it is guessing. What you control is whether the site is in better shape when it comes.

Set a review date at the start, compare like-for-like periods, and match days of the week so a Bank Holiday does not read as a regression. Keep a dated log of every change. Six weeks in, that log is the only thing that will tell you which of your ideas was right.

Where to start this week

Open Search Console and check manual actions and security issues; two minutes, and it occasionally ends the whole investigation. Then export the performance comparison by page, sort by click loss, and write down the ten URLs carrying the largest share of it. That list, the date the fall began, and whatever shipped near it is a recovery plan on one page. Everything after that is execution.

If you would rather have someone else run the diagnosis, our free SEO audit runs the same indexation and technical checks described above, plus a read of the pages that lost the traffic, and comes back with a prioritised list. Where the work is bigger than a fix list, the SEO and web development services page sets out how ongoing recovery work is structured. Either way, start with the date and the ten pages. Everything sensible follows from those.