A website migration is any change that alters how a site's URLs, structure, or hosting work under the hood: a full redesign, switching CMS or platform, moving to a new domain, or restructuring the URL pattern of an existing site. None of these are inherently risky to rankings. What's risky is doing them without checking what the change actually did to crawling, indexing, and the redirect map, because the failure mode is almost always silent. The new site looks fine to a visitor. Google just can't find half of what it used to rank.
Why Migrations Are Where Rankings Quietly Break
Every part of technical SEO that normally sits still gets touched at once during a migration: URLs change, so every internal and external link now points somewhere that might not exist anymore. Redirects get added in a rush to get the new site live, and the ones meant to be temporary never get revisited. Robots.txt and noindex tags, often copied from a staging environment, sometimes make the jump to production unedited. None of these show up by looking at the new site. They show up as a slow bleed in Search Console over the following weeks.
Before the Migration
- Crawl and record the old site's URL list. You need a full map of what currently exists and ranks before you can confirm nothing important got dropped.
- Map every old URL to its new equivalent. A 1:1 redirect map, not a blanket rule sending everything to the homepage; sending old URLs to an unrelated new page passes little to no ranking value.
- Run a baseline audit of the live site so you have a documented "before" state: rankings, indexed page count, Core Web Vitals, and any existing structured data. Without this, you're relying on memory to judge whether the migration actually broke anything.
During the Launch
- 301, not 302, for every permanent redirect. See our 301 vs 302 redirects guide for why a 302 left in place too long can quietly fail to pass ranking signal the way a 301 does.
- Check robots.txt the moment the new site is live. A
Disallow: /copied from staging is the single most common migration disaster, and it blocks the entire site from being crawled at all. See our robots.txt guide for the exact rules that go wrong. - Check for stray
noindextags left over from staging, the meta-tag equivalent of the mistake above; a page can still be crawled but never appear in results. - Confirm canonical tags point to the new URLs, not leftover references to the old ones. See our canonical tags guide.
After the Migration
- Submit the new sitemap in Search Console and watch the Coverage/Pages report for a spike in excluded or error pages, the earliest signal something didn't transfer cleanly.
- Watch for soft 404s. If redirect logic silently sends deleted or moved URLs to an unrelated page instead of erroring properly, it often shows up first as a soft 404 rather than an obvious broken link. See our soft 404 guide.
- Re-check structured data. Schema markup is easy to lose in a platform switch if the new CMS doesn't output the same types the old one did.
- Give it 4 to 8 weeks before drawing conclusions. Some ranking movement after a migration is normal while Google recrawls and re-evaluates the new URLs; a real problem shows up as a sustained drop, not a brief dip.
The Fast Way to Check Yours
Running through this list by hand across dozens or hundreds of URLs isn't realistic under launch-day pressure. AuditCrow's free scan is worth running both before and after a migration: once to capture the baseline, and again once the new site is live, so you have a direct before-and-after comparison instead of relying on your memory of what the old site looked like.