What counts as a migration
"Migration" covers five quite different events, and they carry different risk:
| Type | Example | Risk |
|---|---|---|
| Domain change | old.com → new.com | High — everything moves at once |
| Protocol or host | http → https, www → non-www | Low, if redirects are right |
| URL restructure | /p?id=42 → /blue-widgets | High — every URL changes |
| Replatform | WordPress → Shopify | High — URLs, templates and rendering all change |
| Redesign | Same URLs, new templates | Moderate — content and internal links often change silently |
The last is the one people underestimate. If URLs stay the same, a redesign feels safe — but if the new templates drop text, change headings or thin out internal links, the pages have changed in exactly the ways search engines assess, with no redirect anywhere to explain it.
Capture the baseline first
You cannot tell whether a migration went wrong without knowing what "right" looked like. Capture this before anything changes, and keep it:
- A full crawl of the current site — every URL, its status, title, headings and canonical
- Organic performance per URL from Search Console — at least the last 12 months, exported
- Your top pages by traffic and by external links — the list that matters most if something breaks
- Current rankings for the terms you care about
- Core Web Vitals and index coverage, so you can tell a new problem from an old one
This is fifteen minutes of exporting that decides whether post-launch diagnosis is possible at all. Without it, every question becomes "was that page always like that?" and nobody knows.
The sequence
Order matters more than any individual step.
1 · Map old URLs to new. One to one wherever an equivalent exists. This is the migration; the rest is logistics. See 301 redirects for the mechanics and the traps.
2 · Build the new site on a blocked staging environment. Password-protect it. Do not rely on robots.txt or noindex — a staging site that gets indexed becomes a duplicate of a site that does not exist yet.
3 · Test the redirects on staging. Follow each to its final status code. Look specifically for chains and loops, which never appear in the map and always appear in reality.
4 · Check the new templates preserve what mattered. Titles, headings, structured data, internal links, canonical tags. Redesigns quietly drop these.
5 · Launch, then immediately verify. Remove the staging block. Confirm redirects are live in production — not just in the config file — and that the new site returns 200 where it should.
6 · Update the sitemap to list only new URLs, and submit it. Some teams temporarily submit the old sitemap too, so crawlers revisit old URLs and discover the redirects faster.
7 · Use the Change of Address tool in Search Console, for a domain change only. It tells Google the move is deliberate. It does not replace redirects.
8 · Re-crawl the live site within a day. Compare against the baseline: which URLs now 404, which redirect more than once, which lost their canonical.
The most common failure is not a missing step. It is step 5 being assumed rather than checked — redirects correct on staging, never deployed to production.
What to expect afterwards
A dip is normal. Search engines have to re-crawl every URL, follow every redirect and re-assess every page, and that takes time proportional to the size of the site.
What is not normal:
- Traffic falling and staying flat for months with no recovery trend
- A steadily rising 404 count weeks after launch
- Old URLs still being served, or serving 200 alongside the new ones
- Index coverage far below the old site's
Recovery time varies with site size, crawl frequency and how clean the redirect map was. Anyone quoting you a fixed number of weeks is guessing — what you can do is watch the *trend* and act if it is flat rather than rising.
The failures that actually happen
Redirects tested on staging, never deployed. The single most common serious migration failure.
A staging Disallow: / copied to production. The new site launches uncrawlable. Traffic goes to zero rather than dipping, which is at least an unmistakable symptom.
Only the top pages mapped. The long tail is where a surprising share of traffic lives, and it disappears quietly because no single URL's loss is visible.
Internal links still pointing at old URLs. The redirects carry it, but every internal link costs an extra hop and tells crawlers the site does not know its own structure.
Content dropped in the redesign. Pages that ranked on depth now rank on less of it. No redirect explains this, because the URL never moved.
No baseline. The migration may have gone perfectly. Without a before, nobody can say.
Frequently asked questions
How long does it take to recover traffic after a migration?
It varies with site size, crawl frequency and redirect quality, and no honest fixed figure exists. What matters is the trend: traffic should begin recovering as re-crawling progresses. Flat for months means something in the map is wrong.
Do I need the Change of Address tool?
Only for a domain change, and only in addition to redirects. It signals that the move is deliberate; it does not move anything by itself.
Will a redesign on the same URLs affect SEO?
It can. If new templates drop body text, change headings or reduce internal links, the pages have changed in ways search engines assess — with no redirect to explain it. Compare the new templates against the old before launch.
Should I migrate everything at once or in phases?
Phasing reduces blast radius and makes diagnosis easier, because a problem is isolated to one section. It also extends the period during which two structures coexist. For large sites the trade is usually worth it; for small ones a single clean move is simpler.
Move the site without losing what it earns
Migrations fail in predictable ways: URLs that were never mapped, redirects that never reached production, content quietly dropped in a redesign. None of it is mysterious, and all of it is cheaper to prevent than to diagnose six weeks later.
If you have a move coming, the Safe SEO Site Migration covers the baseline, the mapping, staging verification and post-launch checks — $2,500, one-off, no retainer.