There are two kinds of sites in this world: those that have migrated, and those that will. Because at some point, a business redeploys — a redesign, a rebrand, a move to a new platform — and in doing so, it puts its entire organic visibility on the table.
Here's the thing that should give you confidence and also a little fear: the technical side of migration is the easy part. The losses come from the planning, and almost all of them are avoidable. Most of what separates a smooth migration from a traffic cliff is paperwork done before a single line of new code ships. This guide is that paperwork, in the order we actually execute it.
Why sites actually bleed rankings
It's rarely the redirection software failing. It's the human steps around it:
- A URL changes with no redirect at all — the old page just ghosts. Every external link that pointed at the old URL now points at a 404, and every share, citation, and bookmarking session you earned evaporates.
- A redirect points to the homepage instead of the specific new page, dumping equity and confusing intent. Search intent maps to the page, not the domain; a redirect to home says "your specific question isn't answered here anymore."
- The sitemap lists pages that 404 — the new sitemap published before the redirects finished propagating, which tells the crawler you shipped broken.
- Metadata and content got dropped in the redesign's rush. A page that survived the migration but lost its title optimization, its FAQ, or its answer-shaped paragraphs is a page that kept its URL and lost its reason.
- The whole thing shipped to production without testing — and nobody noticed until traffic spoke.
None of these are glamorous technical failures. They're oversights. And they're 90% of migration damage.
The migration checklist that protects you
It's the checklist our technical SEO engineering team assigns to every migration, in the order it has to happen:
This is the order we insist on, and it's mostly paperwork you can't skip:
Inventory everything first. Crawl the live site, export every URL, and note which carry actual value — rankings, links, traffic. That's your protected list. Don't invent this list from memory; crawl it. Sites routinely run 40% more URLs than anyone remembers, and every unlisted one is a page that could quietly die.
Build the redirect map before you touch anything. Every URL on the inventory gets a decision: old-to-new 1:1, old-to-best-match-on-new, or gone. Gone pages get a 404 or a sensible redirect, never a silent hole. If a page genuinely no longer exists, pick the closest live equivalent — nothing that had rankings should endlessly dinner-table 404.
One redirect per change. When a page moves, the only redirect you need is old URL to new page. Avoid chains — old to intermediary to final — and keep redirects one hop. Chains slow response, waste equity, and create a debugging minefield the moment one link in the chain breaks.
Test on staging, hard. Redirect each old URL on staging and confirm it lands where intended with the right status code. Crawl staging the way you'll crawl production — a staging crawl catches the pattern errors a spot-check won't: the template bug that drops titles, the configuration that noindexes everything, the canonical that points at the old domain.
Preserve what ranks. Keep title tags, metadata, and content in place wherever the intent didn't change. Redesigns love to rewrite perfectly good copy about which content you rank and lose it. Ask the redesign team a better question: what does the copy change buy you? Only rewrite pages when the rewrite is the point; otherwise, preserve.
Launch, then monitor. After go-live, watch Search Console and read the logs for 404s, unindexed pages, and crawl-rate drops. Expect a temporary dip; that's normal recrawling. Watch for the avoidable losses — the 404s and missing redirects — and fix them the moment they appear.
The sensitive directives everyone gets wrong
Migrations are where the subtle SEO switches get flipped by accident, and they're worth a dedicated pass because they're silent:
- Canonicals. Every page must self-canonical on the new domain. We've seen migrations fail because the templates carried a canonical pointing at the old domain — telling Google the new URLs were duplicates of the old ones. If you've applied canonicals anywhere in the past, review them all through the lens of the new URL scheme (canonical decisions covered separately), and check that pagination kept its self-canonicals.
- Noindex. A staging noindex rule that rides along to production removes the whole site from the index, silently — the same accidental noindex pattern that audits keep finding in production. Grep your templates and headers for noindex before launch, not after traffic collapses.
- Robots. If robots.txt blocked sections on the old site, confirm the rules still apply to the new structure — blocks that made sense for one layout can hide an entire section of another.
Each of these fails silently, which is exactly why they're the subclass of migration mistakes that leave the deepest scars. The 404 shows up in every report; the wrong canonical doesn't.
The pre-launch test suite (run this twice)
Before you schedule the deploy, the following should all be true:
- Every template renders an indexed, crawlable page on staging — no noindex leaks, no canonical from staging or the old domain.
- The sitemap resolves to 200s, not redirects, on the live domain after launch.
- Your most valuable fifty URLs all redirect to exactly the page you designed — verified one by one, not sampled.
- Metadata and content on the pages that matter match the old versions unless a rewrite was deliberate.
- Redirects are one hop, and none land on a page that itself redirects.
Run it once for the launch team and once from a fresh crawl after launch. The second run is where the "you missed one" mistakes surface — and it's also where you confirm the crawl-to-index flow: old URLs 301 to the new pages, and the new ones get discovered and indexed without babysitting.
The 30/60/90 calendar after launch
The migration isn't over at launch; the deploy was just the loud part. Give the recovery phase a structure, or it soaks up the next quarter in evening-meeting anxiety:
- Days 0–7: triage. Check 404s daily, fix the highest-value redirects first, confirm the sitemap resolves to 200s on the live domain, and watch for a crawl-rate cliff. Everything else can wait — a redirect pointed at the wrong page compounds confusion every day it lives.
- Days 8–30: stabilization. Watch the indexation report for both the new URLs and the old URLs' redirect status, and compare field performance against the pre-launch baseline. A redesign that shipped 800ms slower is a redesign quietly taxing every ranking and conversion effort afterward.
- Days 31–90: confirmation. The new architecture should be forming a clear index footprint. Check that internal links between new pages match the site architecture design, that canonical directions are coherent, and that the money pages are getting the crawl attention the old ones had. This is when a clean hierarchy or a heap becomes visible in the data.
The dip is normal; a dip that's still a dip on day 45 is a signal that something structural didn't make the cut.
Two extra reminders: keep the redirect map published and inspectable for at least ninety days, because partner sites and directories take months to refresh their links; and resist treating an unexpected ranking gain as permission to relax — a spike during a migration is frequently a stale cached result, not a new baseline.
The cost of skipping
A clean migration costs a few days of tedious mapping. A broken one costs months of traffic and the reputation that goes with it. Every time I see a site in freefall after a relaunch, the cause is the same: someone was in a hurry and skipped the mapping. The ranking loss wasn't fated. It was checked into production.
The math favors patience. One week of mapping amortized across eighteen months of stable rankings is nearly free. Two weeks of reactively rebuilding rankings after a cliff is the most expensive project an SEO team will run all year — and it's the project no one budgets for.
Treat it as change management
A migration isn't a technical deploy. It's a change-management project where the most valuable asset — your established visibility — is the thing most at risk. Give the mapping the respect it deserves, and the migration becomes a short dip instead of a long recovery. And remember the flow it creates: a clean launch means Googlebot recrawls the new structure with confidence, rediscovering pages in days rather than weeks — which is exactly the indexing behavior you want, and exactly what a bot that's been trained by broken redirects will not give you.
For a deeper dive, see our guide on understanding crawl budget.
We run migration prep for clients so the scariest project in SEO becomes the most routine — Enterprise SEO Architecture covers the redirect and crawl-side planning. If you're planning a relaunch and don't want to lose what you've built, book a free website teardown first and we'll scope the redirect map before you schedule the deploy.