I once watched a client lose 47% of their organic traffic in three days. The cause wasn’t a Google update. It wasn’t a competitor stealing rankings. It was a site migration where someone redirected every old URL to the new homepage, then turned off the old server before checking anything had indexed.
That’s the kind of thing that happens when SEO doesn’t get a seat at the planning table. By the time the dev team is pushing to production, it’s too late to restructure the redirect logic or rebuild the URL map. You’re fighting fires instead of preventing them.
The good news: site migrations don’t have to be traumatic. If you treat them like a project that starts six to twelve weeks before launch, you can come out the other side with rankings intact, traffic preserved, and sometimes even better performance than before. This is the SEO site migration checklist I run on every project, broken into the four phases that actually matter.
First, know what kind of migration you’re running
The risk profile changes massively depending on what’s actually changing. A hosting swap with the same URLs is low-risk. A full domain change combined with a CMS switch and a new URL structure is the kind of project that can take a year to recover from if it goes wrong.
Here’s how I categorize them.
| Migration type | What’s changing | Risk to SEO | Typical recovery time |
|---|---|---|---|
| Hosting / server move | IP address, hosting provider | Low | 1 to 2 weeks |
| HTTP to HTTPS | Protocol only | Low to medium | 2 to 4 weeks |
| Redesign on same URLs | Templates, look and feel | Medium | 4 to 8 weeks |
| CMS migration | Backend platform, often URL patterns | Medium to high | 6 to 12 weeks |
| Domain change | Full domain swap | High | 3 to 6 months |
| CMS + domain + URL structure | Multiple variables at once | Very high | 6 to 12 months |
Table 1: Common migration types ranked by risk to SEO.
Once you know which type you’re running, you know how much planning runway you need. The further down that table you sit, the earlier SEO needs to be in the room.
Phase 1: Pre-migration planning (start at least six weeks out)
Most migrations succeed or fail before launch day. I’d argue 70% of the work happens here.
The non-negotiables in this phase:
- Benchmark current performance. Pull rankings, organic traffic, top-performing URLs, top backlinks, and conversion data from at least the last twelve months. This becomes your reference point for whether the migration worked.
- Crawl the existing site. Use Screaming Frog or Sitebulb. You need a complete inventory of every URL, its status code, its title and meta, its internal links, and its traffic value.
- Identify your high-value pages. Sort by organic traffic, by conversions, by backlinks. The top 20% of pages by these metrics get extra attention. Everything else can be batched.
- Build the URL map. Every URL on the old site needs a destination on the new one. No blanket redirects to the homepage. No exceptions.
- Plan the redirects. 301s for permanent moves. Consolidations where pages should merge. 410s for the pages that should genuinely die.
- Test on staging. A protected staging environment is non-negotiable. If you skip this and find issues post-launch, you’re debugging in production with real traffic watching.
How to think about your URL map
This is where most migrations actually fall apart. Use this matrix to make consistent decisions about every URL in the inventory.
| Old page condition | What to do | Why |
|---|---|---|
| High traffic, has equivalent on new site | 301 to direct equivalent | Highest priority. Preserves rankings and traffic. |
| Has backlinks but no traffic | 301 to closest topical match | Preserves link equity even if the page itself was thin. |
| Duplicate or thin content with overlap | 301 and consolidate into stronger page | Cleanup opportunity. Use the migration to fix cannibalization. |
| Outdated, no traffic, no backlinks | 410 (gone) or noindex | Don’t pollute the redirect file with low-value pages. |
| Orphan pages with traffic | 301 to topical hub, then fix internal links | Often discovered during the pre-migration crawl. |
Table 2: URL mapping decisions, by page condition.
On a recent audit I did for a SaaS client, over 30% of their old URLs had been redirected to the homepage as a blanket policy. Traffic dropped hard within the first week. Once we rebuilt the map page by page, recovery started, but it took close to four months.
Phase 2: Pre-launch checks (the week before)
By this point everything should be tested on staging. The week before launch is for verification and sequencing.
- Confirm all 301 redirects are written and tested.
- Verify the XML sitemap is generated and accurate for the new site.
- Check robots.txt to confirm nothing important is being blocked.
- Confirm no leftover noindex tags from staging are coming with you. This kills more migrations than any other single mistake.
- Verify analytics, GTM, and Search Console tracking are in place on the new site.
- Check that structured data has been migrated, especially Product, Article, FAQ, and HowTo schema.
- Confirm canonical tags point to the new URLs.
- Re-verify hreflang tags if you have international targeting.
- Document a rollback plan in case something catastrophic happens.
The noindex one bears repeating. Half of the broken migrations I’ve audited have a noindex tag still living in the head of the new site, copied over from the staging environment. Check it twice.
Phase 3: Launch day
I always launch on a Saturday or Sunday evening. Lower traffic, fewer business consequences if something breaks, and more time to fix before Monday morning meetings.
- Activate redirects at the server level. Not JavaScript redirects, those don’t pass full link equity.
- Confirm robots.txt allows crawling.
- Generate and submit the new sitemap to Search Console.
- Use the URL Inspection tool to request indexing of high-priority pages.
- Crawl the new site immediately to catch any 404s, broken redirects, or missing pages.
- Test five to ten high-priority URLs manually in different browsers.
- Notify Google of address change in Search Console if the domain changed.
- Monitor server logs for crawl behavior and 5xx errors.
Phase 4: Post-migration monitoring (first 90 days)
A migration isn’t done at launch. It’s done 90 days later, when you can look at the data and say “rankings recovered, traffic stabilized, conversions intact.” Until then, you’re babysitting.
Here’s the monitoring rhythm I keep:
| Metric | Frequency | What you’re watching for |
|---|---|---|
| Indexation status | Daily week 1, then weekly | New pages getting indexed, old URLs dropping out |
| Crawl errors | Daily week 1, then weekly | 404s, 5xx errors, broken redirects |
| Organic traffic | Daily | Sudden drops on specific pages or sections |
| Rankings (top 50 keywords) | Weekly | Movement that exceeds normal volatility |
| Conversion rate | Weekly | Form fills, purchases, demo requests |
| Backlinks | Monthly | Lost referring domains from broken redirects |
| Core Web Vitals | Monthly | LCP, INP, CLS regressions on new templates |
| AI search visibility | Monthly | Citation count and sentiment in ChatGPT, Perplexity, Gemini |
Table 3: Post-launch monitoring schedule for the first 90 days.
Expect a dip in the first three to six weeks. That’s normal. What you’re watching for is whether the dip is recovering. If you’re four weeks out and still 30% down on traffic, something is wrong and you need to dig in fast. The longer you wait, the harder recovery gets.
The new variable: AI search visibility
This is the one most checklists from two years ago miss. Before you launch, run your top twenty buying-intent queries through ChatGPT, Perplexity, and Gemini. Note which of your pages get cited and for which prompts.
After launch, run the same queries again. If your citations have dropped, something in the migration disrupted your AI visibility. Usually it’s broken schema, removed content, or lost internal links. Identify the cause, fix it, and re-test the queries a week later.
What goes wrong, and why
The migrations I’ve seen go badly almost always share one or two of these patterns:
- SEO wasn’t in the planning conversation early enough.
- URL mapping was rushed or batched into “redirect everything to the homepage.”
- Staging wasn’t tested properly, or wasn’t set up at all.
- Noindex tags survived from staging and went live with the new site.
- Redirects were JavaScript-based instead of server-level.
- Nobody benchmarked the old site, so there’s no way to measure success or failure.
None of that is fancy. It’s mostly process discipline. The technical work isn’t the hard part of an SEO site migration. The hard part is getting the right people in the room early enough to do the technical work properly.
If you can do that, the checklist takes care of the rest.