Use case
Recovering from a website migration that lost traffic
The new site launched and traffic fell. Here is how to find out what actually broke, and how much of it is recoverable.
The situation
A redesign or replatform goes live. Within a few weeks organic traffic is down by a substantial fraction, enquiries have fallen with it, and the explanations offered are vague — Google needs time, the new site is better, it will recover.
Sometimes that is true. More often something specific and identifiable broke, and every week it stays broken makes recovery harder because the affected pages continue losing whatever position they retained.
This is one of the most preventable failures in technical SEO and one of the most common, largely because the branding or design supplier and the technical supplier are usually different companies who each assumed the other handled the migration.
How it shows up
- Organic traffic fell sharply within weeks of a launch.
- Search Console shows a rise in 404s or a fall in indexed pages.
- Old URLs return 404 rather than redirecting.
- Pages that used to rank no longer appear for their terms.
- The new site is slower on mobile than the one it replaced.
- Nobody has a list of the old URLs.
Symptom, cause and change
The most expensive mistake in this situation is treating a symptom as a diagnosis. These are the three columns kept apart.
Why it happens
- No redirect map
- The single most common cause. Old URLs were not mapped to new ones, so accumulated search equity was discarded rather than transferred.
- Accidental noindex
- A staging-environment robots directive or meta tag shipped to production. It is embarrassing, it is frequent, and it is instantly fixable once found.
- Content removed or thinned
- Pages that ranked were consolidated or shortened during the redesign, removing the substance that earned the position.
- Internal linking destroyed
- A new navigation dropped links to pages that previously received authority, leaving them orphaned.
- Client-side rendering introduced
- A move to a JavaScript framework that renders content the crawler does not reliably see.
How we approach it
Establish what actually changed
A crawl of the live site with a Googlebot user agent, Search Console coverage data, and where possible a crawl of the previous site from an archive. Nothing is fixed until the diagnosis is written down, because acting on a guess wastes the recovery window.
Check the fast, embarrassing causes first
Robots directives, meta robots tags, X-Robots-Tag headers and canonical tags. An accidental noindex is fixable in minutes and accounts for a meaningful share of these situations.
Rebuild the redirect map
Every old URL that had value mapped to its closest new equivalent, verified to resolve with a single hop. Recovering the URL list from analytics, Search Console and archives is tedious and it is where the recovery actually lives.
Restore what was removed
Where pages that ranked were consolidated or thinned, the content that earned the position frequently has to come back, either as restored pages or as substance added to their replacements.
Fix internal linking and rendering
Re-establish links to pages that lost them, and verify that content is present in the served HTML rather than only after JavaScript execution.
Re-verify and monitor
Re-crawl, confirm every redirect resolves, resubmit the sitemap, and track recovery weekly. Then put the checks into the build so it cannot happen again.
What changes
- A written diagnosis
- What broke, with the evidence, rather than a theory about Google needing time.
- Redirects that resolve
- Every valuable old URL mapped and verified with a single hop.
- Indexability restored
- Robots directives, canonicals and rendering confirmed against the live site.
- Content that earned positions is back
- Where it was removed in the redesign.
- A realistic recovery expectation
- Including an honest statement of what is unlikely to come back.
- It cannot recur
- The checks move into the build, failing it on regression rather than discovering the problem after the next launch.
Where it goes wrong
The most damaging response is waiting. Every week that broken redirects and unindexable pages persist, the affected URLs lose more of whatever position they retained, and recovery becomes progressively harder. Speed matters more here than in almost any other technical SEO situation.
The second is acting on an audit tool without verification. Crawlers report problems that do not exist and miss ones that do, and a recovery plan built on unverified findings spends the window fixing the wrong things. Every finding should be reproduced against the live URL first.
The third is a redirect map built on guesswork. Mapping old URLs to the homepage rather than to their closest equivalent is barely better than a 404, and mapping through chains of two or three hops dilutes what is being passed.
A fourth is assuming the design is at fault. It usually is not. The cause is nearly always technical — redirects, indexability, rendering, internal links — and redesigning again in response is an expensive way to avoid the diagnosis.
A fifth is promising full recovery. Some loss is permanent, particularly where content was genuinely removed or where competitors have taken the positions in the interim. We will give you a realistic view rather than a reassuring one.
Finally, not fixing the process. A migration that broke once will break again at the next replatform unless the checks are automated into the build. This is the part clients most often decline and most often regret.
Finally, the organisational damage is worth naming. A migration that lost traffic frequently makes an organisation reluctant to touch the site again, which quietly costs more over the following two years than the original loss did. Restoring confidence means showing the diagnosis and the verification, not just the recovery.
What else you could do instead
Recovery is not always the right response, and occasionally one of these is the better commercial decision.
- Roll back
- Where the migration is recent and the old site is still available, reverting and migrating properly is sometimes faster and cheaper than recovering in place.
- Accept the loss and rebuild forward
- If the old content was genuinely weak, the position may not be worth recovering and the effort is better spent on new content that deserves to rank.
- Fix only the commercially valuable URLs
- A full redirect map for thousands of URLs may not be justified. Mapping the pages that produced enquiries captures most of the value for a fraction of the effort.
- Do nothing and monitor
- If the fall is within normal seasonal variation and no technical fault is found, the honest answer may be that nothing broke. We would rather report that than manufacture a project.
How we would know it worked
The measures are organic sessions, impressions, average position and index coverage from Search Console, compared against the equivalent period before the migration rather than against the weeks immediately after it. Comparing against the trough flatters every subsequent number.
We track recovery by URL cohort — the pages that lost the most — rather than in aggregate, because a site-level figure can improve while the commercially important pages stay broken. Aggregate recovery reporting is how partial fixes get presented as complete ones.
We state plainly what has not recovered and why, and where we believe a position is permanently lost we say so rather than attributing it to Google needing more time. Some loss is genuinely unrecoverable and a client is better served knowing that than waiting.
How long it takes and what it costs
Diagnosis is typically one to two weeks. Implementing redirects and indexability fixes is usually another one to three, depending on how many URLs are involved and how much of the old URL list has to be reconstructed from archives.
Recovery in search is slower than the fix. Re-crawling and re-indexing take weeks, and a realistic first read on whether positions are returning is six to eight weeks after the fixes are live. Full recovery, where it happens, commonly takes a quarter or more.
Cost is quoted after the diagnosis, which we sell as a separate fixed-price piece of work — partly so the recommendations are not shaped by the size of the remediation we would like to sell, and partly because the diagnosis sometimes concludes that nothing is wrong.
Estimates are labelled as estimates. Timelines here are planning ranges from comparable work, not commitments, and not measured client outcomes. We quote against a defined scope after a discovery call.
Services involved
Search Engine Optimisation
Getting found for the things people actually search — technical foundations first, then structure, then content that deserves the position.
Read more →Website Design & Development
Sites built to convert and to survive — fast, accessible, integrated with your CRM, and maintainable by someone other than us.
Read more →Data Engineering & BI
Getting numbers out of the systems that hold them, into one place, in a state somebody can actually make a decision from.
Read more →Content Creation & Creative Production
The production line behind everything else — the graphics, video, photography and copy that campaigns, channels and sales teams all consume.
Read more →Cloud, DevOps & Infrastructure
The layer everything else runs on — deployed reproducibly, monitored properly, backed up in a way that has actually been tested.
Read more →Maintenance & Ongoing Support
Keeping what has been built working — patched, monitored, backed up and quietly improved, with a response window written into a contract.
Read more →Questions
Will our traffic come back?
Partially, usually, and rarely entirely. Redirects and indexability fixes recover a substantial share where the cause was technical. Where content was genuinely removed or competitors have taken the positions, some loss is permanent, and we will tell you which is which.
How quickly should we act?
Immediately. Every week broken redirects and unindexable pages persist, the affected URLs lose more position and recovery gets harder. This is one situation where speed genuinely matters.
How do we find the old URLs?
Analytics history, Search Console, server logs, XML sitemaps if they were archived, and the Internet Archive. Reconstructing the list is tedious and it is where most of the recoverable value sits.
Was it the redesign?
Almost never the design itself. The cause is nearly always technical — redirects, robots directives, rendering, internal linking — and redesigning again in response is an expensive way to avoid diagnosing it.
Should we roll back?
Sometimes, if the migration is recent and the old site is still available. It can be faster and cheaper than recovering in place, and we would raise it as an option rather than assuming forward is the only direction.
Do we need to redirect every old URL?
Not necessarily. Mapping the URLs that produced traffic and enquiries captures most of the value, and a full map for thousands of low-value pages may not be justified.
How long until we know if it worked?
Six to eight weeks for a first meaningful read, because re-crawling and re-indexing take time. Full recovery where it happens commonly takes a quarter or more.
What does it cost?
The diagnosis is a separate fixed-price piece of work, deliberately, so the recommendations are not shaped by the remediation we would like to sell. Remediation is quoted after it.
How do we stop it happening again?
Move the checks into the build so it fails on regression — one h1 per page, self-referencing canonicals, no internal link to a non-canonical URL, no accidental noindex. It is the part clients most often decline and most often regret.
What if this is not the right piece of work for us?
Then we say so, and it is a common enough outcome that it is worth stating plainly rather than treating as an awkward exception. The most useful thing a first conversation produces is frequently a recommendation to do something smaller, something different, or nothing at all.
Other situations
- Replacing spreadsheets with a real system
- Cutting cost per qualified lead
- Launching in a new European market
- Making company knowledge searchable
- Automating quote to invoice
- Inheriting undocumented software
- Passing a customer security review
- Merging systems after an acquisition
- Opening a second location
Recognise this?
Tell us what it looks like in your business. We will tell you what we would do about it, and whether it is worth doing.
Get in touch