Every few months we are asked to investigate why a redesign or replatform cost a business a substantial share of its organic traffic. The diagnosis is almost always the same and almost never the new platform.
The traffic was attached to specific URLs carrying specific content. The migration changed the URLs without mapping them, or dropped the content, or both. Google followed, found the old addresses gone and the content absent, and the rankings went with them.
This is entirely preventable with a checklist and some discipline, and it is considerably cheaper to do properly than to repair afterwards. Recovery from a badly executed migration can take six months and is never complete.
Inventory before you change anything
The first task, before any design work begins, is to know exactly what you have and what it is worth. Skipping this is what makes everything afterwards guesswork.
Export every URL on the current site. Take them from your sitemap, from a crawl of the site, from Google Search Console performance data and from your analytics, because each source knows about pages the others do not. Search Console in particular will show you URLs receiving impressions that never appear in your sitemap.
Against each URL record the clicks and impressions over the last twelve months, the queries it ranks for, and the number of external links pointing at it. That last one matters disproportionately: a page with genuine inbound links carries equity that is expensive to rebuild and trivially preserved with a redirect.
Now you have a prioritised list. The top pages by traffic and by links must survive the migration with their content intact. Everything else is negotiable.
In practice
Redirect mapping done properly
Every old URL needs a destination, and the destination has to be the closest equivalent rather than the homepage.
Redirecting everything to the homepage is the single most common migration error and it is close to useless. Google treats a mass redirect to an unrelated page as a soft 404, the equity does not transfer, and the user who clicked a search result about a specific product lands on a homepage and leaves.
Use permanent redirects, not temporary ones, because a temporary redirect tells Google the old URL is coming back and the equity should stay there. Map one to one wherever an equivalent exists. Where content is genuinely being retired with no equivalent, letting it return a proper 404 is better than redirecting it somewhere irrelevant.
Avoid redirect chains, where the old URL points to a second URL that points to a third. Each hop dilutes and slows, and chains accumulate silently across successive migrations. Map old directly to final.
Test the map before launch, not after. A spreadsheet of a thousand redirects will contain errors, and checking them on a staging environment is an afternoon. Discovering them from Search Console after launch is a month.
| Situation | Correct handling |
|---|---|
| Page exists in new structure at a different URL | 301 to the new URL |
| Page content merged into a larger page | 301 to the merged page |
| Product discontinued, equivalent exists | 301 to the equivalent |
| Content genuinely retired, no equivalent | Return 404 or 410 |
| Anything with no obvious destination | Do not redirect to homepage |
Preserving the content that ranks
A redirect preserves the address. It does not preserve the reason the page ranked, which was the content.
This is the error that catches design-led redesigns. The URLs are mapped correctly, the redirects work, and rankings still fall, because the new page has a third of the words, the headings were rewritten for visual balance, and the detailed section that answered the query was removed as clutter.
So before rewriting anything, check what the page currently ranks for and make sure the new version still answers it, at least as thoroughly. That does not mean preserving the old copy verbatim. It means preserving the substance and the structure: the same questions answered, the same specifics present, the same headings covering the same ground.
Pay particular attention to pages that rank for queries you did not target deliberately. Those are frequently older pages nobody thinks about, answering something specific, and they are the easiest to delete by accident during a tidy-up.
Launch day and the first month
Launch in a way that lets you verify rather than hope. The checks are quick and the cost of missing something is weeks.
On the day: confirm the new site is not blocking crawlers, which is the single most catastrophic and most common launch error, caused by a staging robots file reaching production. Check that canonical tags point to the new URLs rather than to staging. Submit the new sitemap in Search Console. Spot-check twenty redirects across different page types, including the highest-traffic ones.
In the first week: watch the coverage report for a spike in 404s, which tells you the redirect map has gaps, and for pages being excluded. Watch server logs or Search Console for crawl errors. Expect some ranking volatility; Google needs to recrawl and reprocess, and movement in the first fortnight is normal rather than evidence of failure.
In the first month: compare traffic by landing page against the same period before migration, not against the week before, so you account for seasonality. If specific high-value pages have dropped, investigate those individually rather than treating it as a sitewide problem.
Keep the old site accessible in some form for a few months if you can. Being able to check what a page said is invaluable when diagnosing a drop.
In practice
Key takeaways
- Ranking loss is caused by dropped URLs and dropped content, not by the new platform.
- Inventory URLs from sitemap, crawl, Search Console and analytics before any design work.
- Never mass-redirect to the homepage; Google treats it as a soft 404 and equity does not transfer.
- A redirect preserves the address, not the reason the page ranked. Preserve the substance too.
- The most catastrophic launch error is a staging robots file blocking crawlers in production.
- Expect volatility for two weeks; compare against the same period last year, not last week.
Frequently asked
Only if URLs or content are dropped. A redesign that keeps the URL structure, preserves the content that ranks and maps any changed URLs with permanent redirects typically sees no loss and frequently improves through better performance. Losses come from silently dropping pages during a tidy-up or from rewriting content that was answering a query.
No. It is the most common migration error and close to useless. Google treats a mass redirect to an unrelated page as a soft 404, so equity does not transfer, and users who clicked a specific search result land on a homepage and leave. Map each URL to its closest equivalent, and where nothing equivalent exists, let it return a proper 404.
Six months is typical and recovery is rarely complete, which is why prevention is so much cheaper. If the redirect map can be repaired quickly the damage is limited, but content that was deleted has to be rewritten and re-earn its position, and inbound links pointing at pages that 404ed may never be recovered.
A staging robots file reaching production and blocking crawlers entirely. It is both the most catastrophic and one of the most common errors, and it can go unnoticed for weeks while the site disappears from search. Check it first, before anything else, every time.
Export URLs from your sitemap, a crawl, Search Console and analytics, then record clicks, impressions, ranking queries and external links against each. Pages with meaningful traffic or genuine inbound links must survive with content intact. External links matter disproportionately because that equity is expensive to rebuild and trivial to preserve.