SEO Migration: How to Move Without Losing Your Rankings

An SEO migration is any significant change to a website’s URL structure, domain, platform, or architecture that has the potential to affect how search engines crawl, index, and rank your pages. Done carefully, a migration is invisible to Google. Done carelessly, it can wipe out years of organic growth in a matter of days.

I have watched businesses lose 40 to 60 percent of their organic traffic after a site relaunch that nobody thought to run past the SEO team. The technical work is not complicated, but it requires discipline, sequencing, and someone who understands what is actually at stake.

Why SEO Migrations Go Wrong

Most migration failures are not technical failures. They are process failures. A developer builds a new site, a designer approves the layouts, a project manager signs off the launch checklist, and somewhere in that chain, nobody with SEO accountability was involved until it was too late.

I saw this play out at an agency I ran. A large retail client relaunched their e-commerce platform without looping in our SEO team until two weeks before go-live. By that point, the URL structure had already been finalised, the redirect mapping had not been started, and the new platform had pagination issues that would have created thousands of duplicate pages. We caught it, but only just. The client had assumed their development agency understood SEO. The development agency had assumed we were handling it. Nobody had assumed responsibility.

That gap, where everyone assumes someone else is accountable, is where organic traffic goes to die.

If you want a broader foundation for how SEO fits into your commercial strategy before getting into the mechanics of a migration, the Complete SEO Strategy hub covers the full picture.

What Counts as an SEO Migration

Not every website change is a migration in the SEO sense, but the category is broader than most people realise. Any of the following can trigger significant ranking changes if not handled correctly:

• Moving from HTTP to HTTPS
• Changing your domain name
• Restructuring your URL hierarchy
• Merging two websites into one
• Splitting one website into two
• Moving to a new CMS or platform
• Consolidating international subdomains or subdirectories
• Removing or merging large sections of content

A platform move from WordPress to a headless CMS, for example, often looks like a cosmetic change from the outside. Under the hood, it can alter how JavaScript is rendered, how internal links are structured, and how canonical tags are applied. Each of those changes can affect rankings independently. Combined, they can be catastrophic.

The Pre-Migration Audit: What to Capture Before You Touch Anything

The pre-migration audit is your insurance policy. It gives you a baseline to measure against after launch, and it surfaces problems that need solving before the migration begins rather than after.

Here is what you need to capture before a single URL changes:

Full Site Crawl

Use a crawler like Screaming Frog or Sitebulb to export every URL on your current site. This becomes your master mapping document. Every URL that exists today needs a decision: keep it, redirect it, or remove it. There is no fourth option.

Ranking and Traffic Benchmarks

Export your top-ranking pages from Google Search Console and your organic traffic data from Google Analytics. You want to know which pages are generating the most impressions, clicks, and conversions. These are your highest-risk pages, and they need to be treated with the most care during the migration. Google Search Console is the most direct source for this data, and if you are not already using it systematically, now is the time to start.

Backlink Profile

Export your backlink profile from Ahrefs or a similar tool. High-authority inbound links pointing to specific URLs carry significant ranking weight. If those URLs change without proper redirects, that authority is lost. Identify your most-linked pages and flag them as priority redirect targets.

Technical Baseline

Document your current Core Web Vitals scores, page speed benchmarks, canonical tag structure, XML sitemap, and robots.txt configuration. These will be your comparison points post-launch. If something degrades after the migration, you need to know exactly what it looked like before.

Building the Redirect Map

The redirect map is the most operationally important document in any SEO migration. It is a spreadsheet that maps every old URL to its new destination, with a 301 redirect status code indicating a permanent move.

A 301 redirect tells Google that a page has permanently moved. It passes the majority of the original page’s ranking signals to the new URL. Without it, Google treats the old URL as a dead end and the new URL as a brand-new page with no history.

The redirect map should include:

• Every old URL (including trailing slash and non-trailing slash variants)
• The corresponding new URL
• HTTP status code (301 for permanent redirects)
• Priority tier (high-traffic, high-authority, or standard)
• Confirmation that the redirect has been implemented and tested

Redirect chains are a common problem here. If old URL A redirects to old URL B, which then redirects to new URL C, you have a chain. Chains dilute the signal passed to the final destination. Every redirect in your map should point directly to the final URL, with no intermediate hops.

When I was growing the agency from around 20 people to over 100, we built a standard migration checklist that every account team used. The redirect map was always the first deliverable, not an afterthought. Teams that skipped it or treated it as a formality were the ones who ended up in post-launch crisis management.

Staging Environment Testing

Before anything goes live, the new site should be built and tested on a staging environment that is blocked from being indexed by search engines. This is non-negotiable. If Google crawls your staging environment and indexes your new URLs before launch, you will have a duplicate content problem before the migration has even started.

On staging, you should verify the following:

• The robots.txt file is blocking crawlers on staging and will correctly allow them on production
• All 301 redirects are implemented and functioning correctly
• Canonical tags are pointing to the correct URLs
• The XML sitemap contains only the URLs you want indexed
• Internal links have been updated to point to new URLs rather than relying on redirects
• Meta titles, descriptions, and structured data have been carried across accurately
• Page speed and Core Web Vitals are not materially worse than the current site

Internal links are worth emphasising here. Many teams implement redirects and consider the job done. But internal links that point to redirected URLs add unnecessary crawl overhead and dilute link equity. After a migration, every internal link should point directly to the new URL. This is tedious work, but it matters.

The Launch Sequence

The order in which you execute the migration matters. A chaotic launch where multiple changes happen simultaneously makes it nearly impossible to diagnose problems after the fact. A sequenced launch gives you control points.

A sensible sequence looks like this:

1. Remove the noindex/disallow from the staging environment’s robots.txt immediately before launch
2. Deploy the new site to production
3. Confirm all 301 redirects are live and returning the correct status codes
4. Submit the updated XML sitemap to Google Search Console
5. Use the URL Inspection tool in Search Console to request indexing of your highest-priority pages
6. Verify that Google Analytics and any conversion tracking are firing correctly on the new site
7. Begin daily monitoring of crawl errors, ranking changes, and traffic

For large sites, a phased migration can reduce risk. Rather than moving everything at once, you migrate sections of the site sequentially, monitor the impact of each phase, and only proceed when the previous phase is stable. This approach takes longer but gives you the ability to isolate problems rather than inheriting a system-wide failure on day one.

Post-Migration Monitoring

The migration is not finished when the site goes live. It is finished when you have confirmed that rankings, traffic, and crawl behaviour have stabilised at or above pre-migration levels. That process typically takes four to twelve weeks, depending on the size of the site and how frequently Google crawls it.

In the first two weeks, you should be checking the following daily:

• Google Search Console crawl errors and coverage report
• Organic traffic versus the same period before migration
• Rankings for your top-priority pages
• Any new 404 errors appearing in Search Console
• Indexing status of key pages using the URL Inspection tool

A temporary dip in rankings immediately after a migration is normal. Google needs time to recrawl, re-evaluate, and reassign rankings to new URLs. What you are watching for is a dip that does not recover, which indicates a structural problem: missing redirects, incorrect canonicals, crawl blocks, or content that has been inadvertently removed.

I have judged marketing effectiveness work at the Effies, and one thing that experience sharpened in me was the difference between correlation and causation. A traffic drop after a migration does not automatically mean the migration caused it. Algorithm updates, seasonality, and competitor activity can all coincide with a launch. Your pre-migration benchmarks are what allow you to distinguish between a migration problem and an external factor. Without them, you are guessing.

Common Migration Mistakes and How to Avoid Them

Forgetting Pagination and Filtered URLs

E-commerce sites and large content sites often have thousands of paginated or filtered URLs that are easy to overlook in a redirect map. If your category pages use URL parameters for filtering and those parameters change in the new platform, you can lose a significant volume of indexed pages without realising it.

Changing Too Much at Once

Some migrations combine a platform change, a URL restructure, a content consolidation, and a design overhaul all at once. The logic is efficiency. The reality is that when something goes wrong, you have no way of knowing which change caused it. Where possible, separate the technical migration from the content strategy changes and execute them in sequence.

Migrating Low-Quality Content Without Reviewing It

A migration is an opportunity to audit your content, not just move it. Pages that are thin, duplicated, or receiving no traffic should be evaluated before the migration. Consolidating weak content into stronger pages, or removing it entirely with appropriate redirects, can improve the overall quality signal of your site. Migrating bad content just means you have bad content on a new platform.

Not Updating Your Backlinks

While 301 redirects preserve most of the link equity from inbound links, the cleanest signal is a direct link to the live URL. After a migration, it is worth reaching out to high-authority referring domains and asking them to update their links to point to the new URLs directly. It is a small administrative task that removes a layer of signal dilution.

Assuming the Migration Is Complete at Launch

Launch day is not the finish line. It is the start of the monitoring phase. Teams that move on to the next project immediately after launch are the ones who discover three months later that a category of pages was never properly indexed. Build the post-migration monitoring period into the project plan from the start, with defined checkpoints and clear ownership.

Domain Migrations: A Special Case

Moving to a new domain is the highest-risk type of SEO migration because you are asking Google to transfer the entire authority of one domain to another. The process is the same in principle: 301 redirects from every old URL to every new URL, updated sitemaps, updated Search Console properties. But the stakes are higher and the recovery period is longer.

Google’s Search Console includes a Change of Address tool specifically for domain migrations. It does not replace the redirect work, but it signals to Google that the move is intentional and accelerates the recrawl process. Use it.

Keep the old domain’s redirects in place for at least twelve months after a domain migration. Some inbound links take a long time to be recrawled and updated. Removing redirects too early breaks those links permanently.

One more thing worth saying plainly: do not change your domain name unless you have a strong business reason to do so. I have seen businesses undertake domain migrations for brand refresh reasons, only to spend the following year recovering traffic they had spent years building. The SEO cost of a domain change is real, and it should be part of the business case, not an afterthought.

HTTPS Migrations: Still Worth Getting Right

If your site is still running on HTTP, an HTTPS migration is overdue. HTTPS has been a confirmed Google ranking signal for years, and browsers now flag HTTP sites as insecure, which affects both trust and conversion rates.

The mechanics are the same as any URL migration: 301 redirects from every HTTP URL to its HTTPS equivalent, updated sitemaps, updated canonical tags, and a new Search Console property for the HTTPS version. The most common mistake in HTTPS migrations is mixed content, where a page loads over HTTPS but references assets (images, scripts, stylesheets) via HTTP URLs. This triggers browser security warnings and can affect crawlability. A post-migration crawl specifically looking for mixed content is essential.

For a broader view of how technical SEO fits into your overall organic strategy, including how migrations connect to long-term authority building, the Complete SEO Strategy hub is worth working through in full.

The Organisational Side of SEO Migrations

The technical checklist for an SEO migration is well-documented. The harder problem is organisational. Who owns the migration? Who has sign-off authority? Who is responsible for the SEO audit before development begins?

In most businesses, website projects are owned by marketing or technology, with SEO sitting somewhere adjacent to both. That ambiguity is dangerous. For any migration project, SEO accountability needs to be assigned explicitly, with a named individual responsible for the audit, the redirect map, the staging review, and the post-launch monitoring. Not a team. A person.

The other organisational failure I see repeatedly is the timeline. Development teams are usually working to a launch date, and SEO work is treated as something that can be done in parallel or retrofitted at the end. It cannot. The redirect map needs to be built before development begins, because the URL structure decisions made during development determine the scope of the redirect work. Getting SEO into the room at the start of a website project is not a nice-to-have. It is the difference between a smooth migration and a recovery project.

When I was turning around a loss-making agency, one of the first things I changed was how we scoped website projects. We added an SEO discovery phase at the start of every project, before any design or development work began. It added time to the front end of projects, but it eliminated the expensive post-launch remediation work that had been eating into margins. The best thinking in this industry often sounds obvious in hindsight. Getting SEO involved before a site is built is about as obvious as it gets, but plenty of agencies and in-house teams still do not do it.

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