Most migration checklists promise you'll keep your rankings if you follow the steps. Here's a number they tend to leave out: one widely cited study of 892 domain migrations found around 17% never returned to their previous traffic levels, even after a thousand days.
The honest recovery picture
That statistic needs context, because quoted without it, it's alarmist.
The study covered domain migrations — moving to a different domain name, which is the highest-risk category of move there is. Its headline average was around 523 days to regain previous traffic, with the fastest recoveries clustering around three to five weeks as clear outliers.
Meanwhile Google's own guidance suggests a well-executed migration typically stabilises within roughly four to twelve weeks, and that small to medium sites often see most pages processed within a few weeks.
Both are true. The gap between them is the entire subject of this article.
What the spread means The variance between a three-week recovery and a permanent loss isn't luck. It's the quality of the redirect map, the scope of what you changed at once, and whether anyone checked the right three things on launch day.
So set expectations accordingly. Some dip is normal — you should plan for it rather than treat it as failure. What isn't normal is a dip that doesn't recover, and that outcome is almost always traceable to a decision made before launch.
The two silent killers
Ask what causes a migrated site to disappear and most people say missing redirects. In practice, two staging leftovers do more sudden damage.
A noindex tag carried over from the development site. Staging environments are deliberately blocked from indexing. If that tag ships to production, the site is removed from the index within days — not degraded, removed.
Canonical tags still pointing at the staging hostname. Every page tells search engines the authoritative version lives somewhere they can't reach. The effect is similar and the cause is harder to spot, because the page renders perfectly.
A misconfigured robots.txt belongs in the same category — one line can block crawling of the entire site.
What makes these dangerous is that everything looks right. The site loads, the design is correct, the content is there, nobody in the launch meeting sees a problem. Traffic collapses over the following week and by the time anyone investigates, recovery time has already been lost.
noindex; confirm canonical tags point at live URLs rather than a staging hostname; fetch /robots.txt and read it. Three minutes. These outrank everything else on the checklist because they fail catastrophically rather than gradually, and because they're the ones that look fine from the front end.
The redirect map is the migration
Everything else is logistics. Get this wrong and no amount of post-launch monitoring saves you.
Map one to one, wherever a genuine equivalent exists. Each old URL to the single new URL that most closely matches what it offered. Not to a category page because it's quicker. Not to the homepage.
Use 301 or 308. These are permanent redirects and act as canonicalisation signals that consolidate to the destination. 302, 303 and 307 signal a temporary move, and don't carry the same consolidation weight — mixing them into a permanent migration is a common and quiet error.
Redirect every indexed URL, not just the important ones. The pages you consider unimportant may hold external links you don't know about. That's the equity most at risk, because you can't recover it by editing your own site.
Rankmath
Most popular WordPress SEO plugin with powerful on-page optimization features built in
Best for: WordPress SEO Plugin
Why redirecting everything to the homepage backfires
It feels tidy and it is specifically warned against in Google's own migration documentation.
Mass-redirecting unrelated URLs to the homepage is generally treated as a soft 404 — the destination doesn't match what the original page offered, so the signal is discarded rather than transferred. You get the worst of both: the equity isn't preserved, and visitors arrive somewhere that doesn't answer why they clicked.
Where no equivalent page genuinely exists, a 410 Gone response with a helpful page listing relevant alternatives is frequently the better outcome. It's honest, it's fast, and it doesn't dilute your destination pages with irrelevant signals.
Chains and loops
Crawlers stop following after a small number of hops — commonly cited as around four or five. A chain longer than that can leave the final destination undiscovered entirely.
Even short chains cost you: slower loads for users, more crawl work, and debugging difficulty because redirect rules frequently live simultaneously across your CMS, your CDN and your server configuration. Chains accumulate silently over successive site changes, which is why they're worth auditing periodically rather than only on migration day — part of any thorough technical SEO audit.
Keep redirects for at least a year. Google's guidance is explicit about this, and suggests keeping them indefinitely from a user's perspective. Signal transfer depends on other sites being recrawled, and links pointing at your old URLs may not be revisited for a long time. Removing redirects early recreates the original problem and discards work that had already succeeded. For domain changes, retaining the old domain for several years is standard practice.
The decision that multiplies risk
This is the single most consequential choice in any migration, and it usually gets made for convenience rather than deliberately.
Teams bundle changes. Since we're rebuilding the site anyway, we'll also restructure the URLs, redesign the templates, change the CMS, and clean up the content. Four migrations at once.
Two problems follow. The risk isn't additive — it compounds, because failures interact. And more importantly, if traffic drops you cannot diagnose why. Was it the URLs, the templates, the platform, or the content changes? You've removed your own ability to find out, which means you can't reverse the specific thing that hurt you.
| Type of move | Risk level | Note |
|---|---|---|
| HTTP to HTTPS | Low | Well-understood; still needs full redirects |
| Redesign, URLs unchanged | Low–moderate | Watch for content loss and template-level markup changes |
| Platform change, URLs preserved | Moderate | The URL preservation is what keeps this manageable |
| URL restructure, same domain | High | Redirect map quality decides the outcome |
| Domain change | Highest | Longest recovery; retain old domain for years |
| Several of the above at once | Compounding | Undiagnosable if it goes wrong |
Where you must combine — and sometimes commercial reality requires it — separate them in time as far as you can, and instrument each stage so you know which change corresponds to which movement.
The baseline you can't recreate afterwards
You cannot prove a migration succeeded, or diagnose why it didn't, without knowing precisely what "before" looked like. Capture this before touching anything:
- A full crawl of the existing site — every URL, its status code, title, canonical and indexability. This is your redirect map's source of truth.
- Twelve months of Search Console data, exported. Queries, pages, impressions, clicks, average position.
- Your top pages by traffic and by external links — these two lists overlap less than people expect, and the second one is what you most need to protect.
- Current rankings for your priority queries.
- Analytics benchmarks by channel and landing page.
- Existing structured data, page by page, so you can verify it survived.
The external-links list deserves emphasis. Traffic you can rebuild; a backlink from a site that will never update its link is only preserved by your redirect working. Prioritise those URLs in the map above everything else.
What's new in 2026
Two additions to the traditional checklist, both consequential.
Schema loss is now a visibility problem, not just a rich-result one. Structured data rarely migrates automatically between platforms, and a migration that destroys it can stop AI systems citing you even after your rankings recover. This makes verifying schema on the new site a launch-day item rather than a nice-to-have — the reasoning behind making your site machine-readable in the first place.
AI crawlers behave differently from Googlebot. Notably, many don't render JavaScript. A new site that assembles content client-side may be perfectly visible to Google and effectively blank to the systems generating AI answers. If your platform move introduced client-side rendering, you may recover in search results while remaining absent from AI answers — a failure invisible in Search Console.
Worth also checking your CDN or bot-management settings after a move, since defaults can shape which crawlers reach your content. That's a decision worth making deliberately rather than inheriting.
Broken links: a separate discipline
Bundled into migration guides, but the work is different and mostly ongoing rather than event-driven.
Internal broken links waste crawl budget, produce dead ends for readers, and are entirely within your control. They accumulate whenever pages are moved, renamed or removed, and they're the cheapest technical fix available. Worth a quarterly crawl — and part of why internal link structure needs maintenance rather than just design.
External links pointing to your dead pages are the higher-value find. Someone linked to a page you removed. That equity is sitting unclaimed, and a single redirect recovers it. Pull your 404 report, cross-reference against pages with external links, and redirect the ones that have them to genuinely relevant destinations. This is one of the highest-return hours in technical SEO and it's routinely skipped because 404 reports look like housekeeping.
Your links pointing to other people's dead pages matter least for rankings and most for credibility. Worth fixing on your important pages; not worth an exhaustive programme.
What else silently changes in a rebuild
Three things that move without anyone deciding to move them, all worth a pre-launch check.
Title tags and meta descriptions. New platforms generate these from templates, which frequently means every page inherits a pattern rather than the specific text someone wrote. On a large site this can rewrite thousands of pages at once, and it's rarely noticed until click-through drops — the reason titles and descriptions belong in the pre-launch crawl comparison rather than in a later audit.
Heading structure. Template changes routinely turn an H1 into a styled div or promote navigation labels to headings. The page reads identically to a person and quite differently to a parser.
Page performance. A new build is not automatically faster, and new template frameworks often add weight. Since performance shifts take roughly a month to register, check Core Web Vitals on staging rather than discovering a regression at the 28-day mark alongside everything else.
Timing, which is a business decision
Three rules that are easy to state and frequently overridden.
Never migrate close to your peak season. If a meaningful share of your annual revenue lands in a particular quarter, do not move the site in the preceding months — the recovery window and the peak must not overlap. For retailers that rules out roughly September onward, which is worth checking against your peak season timeline before anyone picks a launch date.
Launch when people are available. Not Friday afternoon, not the day before a holiday. The first 48 hours are when catchable problems are catchable.
Have a rollback plan you've actually tested. Knowing you can revert changes the risk calculation entirely, and the time to discover your backup doesn't restore cleanly is not migration night.
Protect the structures you built deliberately
One category of loss deserves separate attention because it's invisible in a URL-level check.
If you've built topic clusters or hub-and-spoke content, the migration can preserve every page while destroying the relationships between them — supporting pages surviving as orphans because the pillar's outbound links were rebuilt from a template that dropped them. Every URL returns 200, the crawl looks clean, and the architecture you spent a year building is gone.
So verify the internal link graph, not just the status codes. Crawl before and after, compare the number of internal links pointing at each page, and investigate anything that lost a significant share. That's the check that catches damage to cluster structures before it costs you the topical signal they exist to produce.
The sequence
- Capture the baseline. Crawl, Search Console export, top pages by traffic and by links, rankings, schema inventory.
- Build the redirect map from the crawl. Every indexed URL, one to one, 301 or 308. Flag any that can't be mapped and decide deliberately between a relevant redirect and a 410.
- Test on staging. Redirects, canonicals, schema, metadata, internal links, page speed. Confirm nothing points at the staging hostname.
- Launch, then run the three-minute check. noindex, canonicals, robots.txt. Before anything else.
- Verify redirects at scale. Crawl the old URL list and confirm each returns a single-hop 301 to the intended destination. Chains and loops surface here.
- Submit the new sitemap and remove the old one. Update internal links, canonicals and navigation to point at new URLs directly rather than relying on redirects.
- Crawl again at 28 days. Crawl data and performance metrics take roughly a month to stabilise, so this second pass is where you learn what actually happened.
- Monitor for three to six months against your baseline, and keep the redirects for at least a year.
One item hidden inside step three that gets missed: confirm your analytics and conversion tracking fire correctly on the new site. Broken tracking means you lose the data you need to evaluate the migration, and the problem often isn't noticed for weeks.
If the site is large, the URL history is messy, or the move is a domain change, this is genuinely specialist work where the cost of an error is measured in quarters — the point at which a web development partner who has done it before is cheaper than learning on your own site.
The short version
Expect a dip and plan for it; what isn't normal is a dip that never recovers, and that outcome traces back to decisions made before launch. Check noindex, canonicals and robots.txt first — those fail catastrophically while everything looks fine. Map every indexed URL one to one with 301s, never bulk-redirect to the homepage, and use a 410 when no equivalent exists. Don't bundle a platform move with a redesign and a URL restructure, because you'll lose the ability to diagnose what went wrong. Capture the baseline before you touch anything, verify schema survived, and keep the redirects for at least a year.
Planning a rebuild and worried about what it costs you?
We plan and run site migrations that keep the rankings, the links and the traffic you already earned.
Explore SEO Services →Frequently asked questions
How long does it take to recover traffic after a site migration?
It depends enormously on the type of move, and the published figures are easy to misread. Google guidance suggests a well-executed migration typically stabilises within roughly four to twelve weeks, and small to medium sites often see most pages move within a few weeks. However, one widely cited study of 892 domain migrations reported an average of 523 days to regain previous traffic levels, with around 17% never fully recovering within 1,000 days. That study covered domain changes specifically — the highest-risk category — so treat it as the worst case rather than the norm.
Should you redirect old pages to the homepage?
No, and Google's own documentation warns against it specifically. Mass-redirecting unrelated URLs to the homepage tends to be treated as a soft 404, because the destination does not match what the original page offered. That means the signals you were trying to preserve are discarded anyway, and you have also given visitors a confusing experience. Where no genuinely equivalent page exists, a 410 response with a helpful link to relevant alternatives is usually a better outcome than a redirect to somewhere irrelevant.
What is the most common cause of a migrated site disappearing from search?
Two staging-environment leftovers cause more sudden disappearances than missing redirects do: a noindex tag carried over from the development site, and canonical tags still pointing at the staging hostname. A misconfigured robots.txt file has the same effect. These are not subtle degradations — they can remove a site from the index within days, and because everything looks visually correct nobody notices until traffic collapses. Checking these three things should be the first action after launch, before redirects are even verified.
How long should you keep redirects in place?
Google recommends keeping them for at least a year, and suggests keeping them indefinitely from a user perspective. The reason is that signal transfer depends on external sites being recrawled, and links pointing at your old URLs may not be revisited for a long time. Removing redirects early recreates the original problem and undoes work that had already succeeded. For domain changes it is common practice to retain the old domain and its redirects for several years rather than the minimum one.
Do redirect chains harm SEO?
Yes, in two ways. Crawlers generally stop following after a small number of hops — commonly cited as around four or five — so a long chain can leave the final destination undiscovered entirely. Even shorter chains add friction: slower page loads for users, more crawl work, and harder debugging because rules often live across CMS, CDN and server layers simultaneously. Chains tend to accumulate silently over successive site changes, which is why auditing for them periodically matters as much as getting them right on migration day.
