SEO Migration: How to Move Your Site Without Losing Rankings

An SEO migration is any significant change to a website’s URL structure, domain, platform, or architecture that carries meaningful risk to organic search rankings and traffic. Done well, migrations are invisible to Google. Done poorly, they can erase years of accumulated search equity in a matter of weeks.

The frustrating truth is that most migration failures are not technical accidents. They are planning failures. Teams rush the timeline, skip the audit phase, or assume the new platform will handle redirects automatically. It rarely does.

I have been involved in more site migrations than I can count across my agency years, including several that went badly wrong before I inherited them. One client came to us after a platform migration that had wiped out roughly 60% of their organic traffic. The agency that ran it had built the redirect map from a crawl of the new site rather than the old one, which meant hundreds of high-value pages with inbound links simply had no redirect at all. Recoveries like that take months, not weeks. The damage was entirely avoidable.

What Types of Changes Actually Count as an SEO Migration?

Not every website change is a migration in the SEO sense. A migration, for our purposes, is any change that alters the URLs Google has indexed, the domain it associates with your content, or the signals it uses to understand your site’s structure.

The main categories are: domain migrations (moving from one domain to another, or from HTTP to HTTPS), subdomain changes (moving content from a subdomain to the root domain or vice versa), URL restructuring (changing slug formats, folder hierarchies, or parameter conventions), platform migrations (moving from one CMS to another, such as Magento to Shopify or a custom CMS to WordPress), and site consolidations (merging two or more sites into one). Each carries its own risk profile.

A pure design refresh with no URL changes carries almost no SEO risk. A platform migration that also changes URL structure and removes a significant volume of pages is a high-risk event that deserves weeks of preparation. The distinction matters because teams often underestimate scope. They think they are doing a design refresh and discover mid-project that the new platform uses a completely different URL convention. At that point, you are in a migration whether you planned for one or not.

If you are building out your broader organic strategy alongside migration planning, the Complete SEO Strategy hub covers the full picture, from technical foundations through to content and authority building.

How Do You Audit Your Site Before a Migration?

The pre-migration audit is where most of the real work happens. Its purpose is to create a complete record of your current SEO state before anything changes, so you have something to compare against after launch and a source of truth for building your redirect map.

Start with a full crawl of the existing site using a tool like Screaming Frog or Sitebulb. Export every URL, its status code, its title tag, its meta description, its canonical tag, and its inbound internal link count. Do this before any development work starts on the new site, because staging environments have a way of contaminating your baseline if you are not careful.

Cross-reference your crawl data with Google Search Console. Pull the full list of URLs that have received impressions in the last twelve months. This catches pages that your crawl might miss because they are orphaned from the main navigation but still indexed and generating traffic. It also catches pages that are indexed but performing poorly, which you may want to consolidate rather than migrate.

Pull your backlink profile from Ahrefs or SEMrush. Filter for pages with referring domains rather than just raw link counts. These are your highest-priority pages for redirect mapping. A 301 redirect passes the majority of link equity to the destination URL, but a missing redirect passes none. Every page with meaningful inbound links needs to be on your redirect map before go-live.

Finally, document your current rankings for your primary keyword set and your organic traffic by page. This is your benchmark. Without it, you cannot distinguish a normal post-migration fluctuation from a genuine problem. I have seen teams panic at a 15% traffic drop in week one and make unnecessary changes, and I have seen teams miss a 40% drop because nobody was watching the right data. Both outcomes come from not establishing a clear baseline before launch.

How Do You Build a Redirect Map That Actually Works?

A redirect map is a document that pairs every old URL with its new equivalent. It sounds straightforward. In practice, it is one of the most error-prone parts of any migration.

The most common mistake is building the redirect map from the new site rather than the old one. Your new site only contains pages you decided to keep. Your old site contains pages you may have forgotten about, pages that were excluded from the redesign scope, and pages that exist only in Google’s index because they were never properly removed. If you build your map from the new site, those pages have no redirect and their link equity disappears.

Build the map from your pre-migration crawl and Search Console export. Work through it in priority order: first, pages with inbound links from external domains. Second, pages with significant organic traffic. Third, pages that are linked to frequently from other pages on your own site. Fourth, everything else.

For each old URL, identify the best equivalent on the new site. “Best equivalent” means the page that most closely matches the content and intent of the original. If the new site does not have a direct equivalent, redirect to the most relevant category or section page. Avoid redirecting everything to the homepage. Google treats mass redirects to the homepage as soft 404s and will eventually stop passing link equity through them.

Use 301 redirects, not 302s. A 302 signals a temporary redirect and does not pass equity reliably. Check for redirect chains: if your old site already has redirects in place, make sure your new redirects point to the final destination, not through an intermediate URL. Chains of more than two hops dilute equity and slow page load times.

Test every redirect before launch. Not a sample. Every redirect. Automated testing tools can do this in minutes. There is no excuse for discovering broken redirects after go-live.

What Technical Checks Should You Run Before Go-Live?

The redirect map is the most important pre-launch deliverable, but it is not the only one. A complete technical checklist for migration go-live covers several additional areas.

Canonical tags need to be reviewed on the new site. Every page should canonicalise to itself unless there is a deliberate reason to do otherwise. Check that the new platform has not introduced self-referencing canonicals that point to the wrong version of a URL, which is a common issue with platforms that generate both www and non-www versions or both HTTP and HTTPS versions of pages.

Your robots.txt file on the new site needs to be checked before launch. Staging environments are typically set to block crawlers, and it is surprisingly common for that setting to persist into production. A robots.txt that blocks Googlebot will prevent your entire site from being indexed. This is not a theoretical risk. I have seen it happen on a site with over a million pages, and the team did not notice for four days because organic traffic takes time to show the impact of a crawl block.

Check your XML sitemap. It should contain only canonicalised, indexable URLs. Remove any URLs that return non-200 status codes, any pages with noindex tags, and any pages you are deliberately excluding from search. Submit the updated sitemap to Google Search Console immediately after launch.

If you are migrating to HTTPS from HTTP, ensure that all internal links, canonical tags, and sitemap entries reference the HTTPS version. Mixed content warnings from HTTP resources loaded on HTTPS pages can affect both user experience and crawl efficiency.

Page speed should be benchmarked on the new site before launch. Platform migrations often change performance characteristics significantly. If your new site is materially slower than your old one, that will affect rankings independent of anything you did with redirects or content. Tools like Google’s PageSpeed Insights and Core Web Vitals reporting in Search Console give you the data you need.

How Should You Manage the Migration Launch Itself?

Timing and process matter more than most teams expect at the launch stage.

Avoid launching on a Friday. If something goes wrong, you want your full team available to respond. Monday or Tuesday morning launches give you the most runway to identify and fix problems before the weekend. This sounds obvious, but deadline pressure pushes more migrations to Friday afternoons than I would like to admit from personal experience.

If you are doing a domain migration, update your Google Search Console property immediately after launch. Add the new domain as a property, verify it, and use the Change of Address tool to notify Google formally of the migration. This is not a guarantee of faster processing, but it is a clear signal and it is worth sending.

Crawl the live site within hours of launch. Not the staging environment. The live site. Check that your redirects are functioning, that your robots.txt is correct, and that your canonical tags are pointing to the right URLs. Do not assume that what worked in staging will work in production. Server configurations differ, CDN caching behaves differently, and CMS settings sometimes reset on deployment.

Notify your internal teams. Anyone who manages paid search campaigns needs to know that URLs have changed, because broken landing page URLs will cause campaigns to stop converting immediately. Anyone who manages email campaigns, social posts, or partner integrations that link to specific pages on your site needs the same information. SEO migrations have a habit of being treated as a purely technical event when they have commercial implications across the whole business.

What Does Post-Migration Monitoring Actually Require?

The migration does not end at launch. It ends when your organic metrics have stabilised at or above their pre-migration baseline. That typically takes six to twelve weeks, and the monitoring you do during that period determines whether problems get caught early or compound into serious damage.

Check Google Search Console daily for the first two weeks. Watch for crawl errors, coverage issues, and any sudden changes in indexed page counts. A drop in indexed pages immediately after launch is expected if you consolidated content. A drop that continues week over week is a problem. Watch for manual actions, which are rare but occasionally triggered by migrations that inadvertently create patterns that look manipulative to Google’s reviewers.

Monitor organic traffic by page, not just in aggregate. Aggregate traffic can mask significant problems at the page level. A new page that suddenly starts ranking well can offset traffic losses from pages that have dropped, making your total look stable when your core commercial pages are actually declining. Segment your tracking by page type: category pages, product or service pages, blog content, and landing pages should all be reviewed separately.

Track rankings for your priority keyword set weekly. Ranking changes after a migration are normal and expected. Google needs time to recrawl and reassess your site. What you are looking for is the direction of travel over four to six weeks. Rankings that drop and then recover are fine. Rankings that drop and continue dropping need investigation.

Check your backlink profile two to four weeks after launch. Some link analysis tools take time to update, but by week three you should be able to see whether your inbound links are resolving to the correct new URLs through your redirects. If major referring domains are still pointing to URLs that are returning errors rather than redirecting, contact the site owners directly and ask them to update the links. Redirects pass equity, but a direct link to the correct URL is always better.

One thing I would add from experience: assign a single person to own post-migration monitoring. On shared responsibility, nobody watches closely enough. On a migration I ran for a retail client some years ago, we had three people nominally responsible for post-launch monitoring. When a crawl issue emerged in week two, each assumed one of the others had spotted it. By the time it was escalated, we had lost two weeks of crawl coverage on a section of the site that accounted for a significant share of organic revenue. Single ownership is not bureaucracy. It is accountability.

How Do You Diagnose a Traffic Drop After Migration?

If your traffic drops materially after a migration and does not recover within three to four weeks, you need a structured diagnostic process rather than guesswork.

Start with the most common causes in order of likelihood. First, check for redirect failures. Crawl your old URL list against the live site and verify that every redirect is returning a 301 to the correct destination. Second, check your robots.txt and meta robots tags. A noindex tag or a disallow directive that should not be there will suppress rankings quickly. Third, check your canonical tags. Incorrect canonicals can consolidate ranking signals to the wrong page or dilute them across multiple versions of the same URL.

If those three checks come back clean, look at content changes. Platform migrations often involve content restructuring, and it is common for pages to lose important on-page elements during the process: heading hierarchies change, body copy gets shortened, structured data gets dropped. Compare your top-performing pages before and after migration to check for content quality regressions.

Check your internal linking structure. If your new site architecture significantly reduces the number of internal links pointing to key pages, those pages will receive less crawl priority and potentially less ranking support. This is particularly relevant for large sites where crawl budget matters.

If none of the above explains the drop, look at the broader context. Did a core algorithm update coincide with your migration? Are your competitors also showing traffic changes? Is the drop concentrated in specific query types or devices? Correlation with a migration does not always mean causation, and it is worth ruling out external factors before assuming the migration is responsible for everything you are seeing. That said, the burden of proof should sit with ruling out migration causes first. In my experience, when a traffic drop follows a migration by less than four weeks, the migration is responsible more often than not.

For a broader view of how technical health fits into your overall search performance, the articles in the Complete SEO Strategy hub cover the strategic context that migration decisions sit within.

What Are the Most Commonly Missed Steps in an SEO Migration?

After reviewing migrations that went wrong, a handful of omissions come up repeatedly.

Structured data is frequently dropped during platform migrations. If your old site had schema markup for products, reviews, articles, or FAQs, and your new CMS does not replicate that markup automatically, you will lose rich result eligibility. Audit your structured data before and after migration using Google’s Rich Results Test.

Hreflang tags are another common casualty. If you run a multilingual or multi-regional site, hreflang annotations tell Google which version of a page to serve to which audience. Platform migrations often break these annotations, leading to the wrong language version ranking in the wrong market. This is a slow-burn problem that takes weeks to surface in rankings data.

Pagination handling changes between platforms. If your old site used rel=”next” and rel=”prev” for paginated content and your new site does not replicate this (or uses a different pagination convention), Google may struggle to understand the relationship between paginated pages and consolidate ranking signals incorrectly.

Third-party tracking and tag management setups often break during migrations. This is not directly an SEO issue, but if your analytics tracking is broken, you cannot monitor the migration effectively. Verify that Google Analytics, Search Console verification tags, and any other tracking dependencies are functioning on the new site before launch.

Finally, and this one is underappreciated: the migration of 404 pages. Your new site should have a well-designed 404 page that helps users find what they are looking for and does not simply return a blank error. More importantly, monitor for new 404s in Search Console after launch. Some will be expected. A surge of 404s on URLs that should have been redirected is a signal that your redirect map has gaps.

For teams that want a reference point on how SEO practitioners approach complex technical work, this piece from Moz on what technical SEO leadership looks like in practice is worth reading. It gives a useful sense of the depth of knowledge that serious migrations require.

If you are looking at how content performance fits into your migration decisions, particularly around which pages to consolidate versus migrate, Buffer’s overview of SEO fundamentals offers a clear grounding in how content signals feed into organic performance.

For teams working in competitive verticals where migration decisions intersect with market positioning, SEMrush’s analysis of B2B content strategy gives useful context on how content quality decisions made during migrations affect long-term authority.

And for anyone who wants to understand how landing page structure should inform migration decisions for pages that serve both SEO and conversion purposes, Unbounce’s research on CTA placement is a useful reference when you are rebuilding high-value pages on a new platform.

About the Author

Keith Lacy is a marketing strategist and former agency CEO with 20+ years of experience across agency leadership, performance marketing, and commercial strategy. He writes The Marketing Juice to cut through the noise and share what works.

Frequently Asked Questions