SEO Migration Checklist: How to Move Your Website Without Losing Rankings

Whether you're redesigning your website, moving to a new platform or CMS, changing your domain name or switching host, it all counts as a website migration, and each one puts the rankings and traffic you've built up at risk if search engines get left out of the plan. I've put this SEO migration checklist together in the order I'd work through it, starting with the groundwork before you move and finishing with the checks that carry on for weeks after launch.

Website migrations are one of the SEO projects I take on and, as technical SEO is the part of the job I enjoy most, they're a job I like getting stuck into. I've written this with small and medium businesses and in-house marketers in mind, so it should be useful whether you're doing the work yourself or briefing a developer.

What Counts as an SEO Migration

Generally speaking, an SEO migration (or website migration) is any change to your site that could affect how search engines crawl, index or rank it. That could be a domain change, a redesign, a move to a new CMS or platform, a hosting or server move, or a restructure that changes your URLs.

Some of these can feel more like a design job than an SEO one, such as a new theme or a move from WordPress to Shopify, but they can still change your page addresses, the links between them and the signals Google uses to rank them.

If you're worried that your traffic will fall off a cliff when the new site goes live, the honest answer is that it can if nobody plans the move with search engines in mind. Old URLs that lead nowhere, a staging block left in place or internal links pointing at deleted pages can undo years of work.

Google says ranking fluctuations are expected after a URL change while it recrawls and reindexes your site, so if you see some movement in the first few weeks there's no need to panic. What I'd look out for is a sharp drop, or a drop that doesn't recover, as that's usually the sign something has been missed.

Before You Migrate: Planning and Auditing

I tend to think of a migration in three phases. Before the migration I benchmark, audit and map every URL. At launch the redirects go live, the staging block comes off and the new sitemap gets submitted. Then after launch it's a case of crawling, monitoring and fixing problems for several weeks until rankings and traffic settle down.

Most of the work sits in this first phase, and it's also the one people are most tempted to rush. The pre-migration review is really an SEO audit of your current site, because you need to know exactly what you've got before you can move it safely, so I'd always spend a bit more time here than feels necessary.

1. Benchmark your current performance. The first thing I do is export rankings, organic traffic, conversions by landing page and indexed page counts from Google Search Console and analytics. Without a baseline to compare against, it's hard to tell a normal dip from a real problem once the new site is live.
2. Crawl the existing site. Next I crawl the current site and capture every URL along with its page title, meta description, status code and canonical tag. Bear in mind a crawl only finds pages that are linked internally, so it's worth adding in URLs from your XML sitemap, Search Console and analytics too. This list then becomes your redirect map.
3. Identify your most valuable pages. From that list I flag the pages bringing in the most organic traffic, leads or sales, along with any that other websites link to, as these are the ones that need the most care.
4. Decide what stays, merges or goes. Then go through each page and mark whether it's being kept, merged into another page or dropped altogether.
5. Take a full backup. Before anyone touches anything, make sure you've got a backup of the current site's files and database, so if launch day goes badly you've got a clean way back.

Building the Redirect Map

The redirect map is a spreadsheet with every old URL in one column and its new home in the next. If your URLs are changing, this is the most important document you'll make, and if you only get one thing on this list right I'd make it this one.

1. Map one-to-one. I point each old URL at its single most relevant new equivalent using a permanent server-side redirect (301 or 308). One of the most common and most damaging mistakes is to redirect everything to the homepage, because visitors end up somewhere they didn't ask for and the relevance each page has built up gets thrown away.
2. Keep chains short. If a page has been redirected in the past, point the oldest URL straight at the final destination so there's only one hop. Google advises keeping redirect chains to no more than three hops, and fewer than five at most, even though Googlebot will follow up to ten.
3. Cover the URLs that are easy to miss. The ones that tend to catch people out are the extras your platform generates, such as old mobile variants, gallery and image pages, old blog paths, category and tag archives, and PDFs that have picked up links.
4. Handle dropped pages properly. If a page doesn't have an equivalent on the new site, either redirect it to the closest relevant page or let it return a genuine 404 or 410. If an old URL is left live with empty content and a normal 200 status, search engines can treat it as a "soft 404" and carry on crawling a page you thought was gone.
5. Move content across largely as it is. Where I can, I keep the content, titles and headings close to the original at launch and save any rewrites for once the site has settled. If the content and the URLs both change at the same time, you've no way of telling which one caused any ranking movement.

Once the redirects are live, leave them in place. Google recommends keeping redirects in place for at least a year after a migration, and longer if the old URLs are still getting traffic, but personally I treat them as permanent.

Pre-Launch Technical Checks

Before the new site goes anywhere near your live domain, I run through these checks on the staging site.

1. Block staging from search engines. Password protection is the most reliable way to do this, although a noindex tag works too. The one to be careful with is a robots.txt block on its own, because if robots.txt blocks a page, Google never sees its noindex tag, so the page can still turn up in the search results if something links to it. Whichever method you go with, I'd add "remove the staging block" to your launch day list now, as forgetting it is one of the most avoidable ways to lose traffic.
2. Check robots.txt and the XML sitemap. The live robots.txt should allow crawling of everything you want indexed, and the new sitemap should only list new, indexable, canonical URLs, so nothing that redirects or is set to noindex.
3. Check canonical tags and schema. Every canonical should point at the page's own final live URL, and I always double-check none of them are pointing at the staging domain or the old URL structure. It's also worth making sure any structured data has carried over and still validates.
4. Rebuild internal links on purpose. Changes to the navigation are a common way to lose internal link value, so I point menus, footer links and in-content links straight at the new URLs and check no important page has been left orphaned with nothing linking to it.
5. Keep local details identical. If you have a Google Business Profile, the business name, address and phone number on the new site should match it exactly. Carry over any local business schema too, and if the domain is changing, remember to update the website link on your profile at launch.

Launch Day

Most launch day problems come from one step being left until later, so I try to do all of these together.

1. Deploy redirects and lift the staging block together. The new site, the redirects and the removal of any noindex tag, password or robots.txt block should all go live at the same time.
2. Test a sample of redirects. Once it's live, I check a handful of old URLs, including your most valuable pages, and confirm each one lands on the right new page in a single hop.
3. Submit the new sitemap. Add it in Google Search Console, and in Bing Webmaster Tools too if you use it.
4. Plan DNS changes ahead. If the host or domain is changing, it can be helpful to lower your DNS TTL (how long other servers cache your DNS records) to a few hours at least a week before cutover, as Google recommends, so the switch spreads quickly. Once everything has settled you can raise it again.
5. Separate DNS and registrar changes. Pointing DNS at a new server and transferring your domain to a new registrar are two separate jobs, and I'd do them in different weeks so that if something breaks you know which change caused it.

I'd also recommend launching earlier in the week. Leaving everything for a Thursday or a Friday can mean working at the weekend if anything crops up. Launching on a Monday or Tuesday gives you plenty of time to keep an eye on the new site and make any changes needed.

After You Migrate: What to Check and How Long For

Once the site is live, the job is to find and fix problems while they're still small. I crawl the live site straight away and then keep an eye on rankings, traffic, indexing and crawl errors for several weeks.

1. Crawl the live site immediately. Look for broken links, 404 errors, redirect chains, incorrect canonicals and links still pointing at staging.
2. Crawl your old URL list. Take every old URL from your pre-migration crawl and run it through again, checking each one redirects to the right place and adding any you missed.
3. Check tracking is firing. New templates often lose the analytics or tag manager code, so I always check GA4, Google Tag Manager and any conversion or ad platform tags are recording on the new site. If you'd like a hand with this, I offer Google Analytics and GA4 support.
4. Monitor for several weeks. Compare Search Console's Performance and Pages reports against your benchmark, keep an eye on crawl errors and track organic traffic in analytics.

A common mistake is to treat a migration as a one-day event. Google says that on a medium-sized site it can take a few weeks or more for Google to gradually start showing the new URLs, and even longer on larger sites. Old URLs, new URLs, canonicals and internal links are all still being discovered well after launch, so problems can surface weeks in. A brief dip is often normal, and keeping up with these checks is what stops it turning into a permanent loss.

Domain moves can take a lot longer to recover from. A study of 892 domain migrations found it took an average of 523 days for the new domain to match the old domain's organic traffic, with 17% still not back to their previous levels after 1,000 days. The data was crowdsourced from SEO professionals, so I'd treat it as a rough guide, but it's still a good reason to only change your domain when you really have to.

Domain Change or Hosting Move Only? What's Different

If you're only moving host, or only changing domain, some of the checklist won't apply and there are a few extra checks to add.

Hosting or Server Move With No URL Changes

If your domain and every URL are staying exactly the same, you can skip the redirect map. The checks below still matter though, because a setting that's changed along with the server can look a lot like a ranking problem.

• DNS: lower the TTL ahead of time (see the launch day list), then once you switch, check the records are pointing at the new host.
• SSL: make sure the certificate is valid on the new server and every page loads over HTTPS.
• Response codes: check pages return a 200 status and there aren't any new errors or unexpected redirects.
• Robots.txt and canonicals: check neither has changed during the copy, and remove any temporary blocks you used while testing.
• Firewall: make sure security or denial of service protection on the new host isn't blocking Googlebot.
• Search Console verification: if you verified with an HTML file or meta tag, check it's made it across.

Googlebot often crawls a little less for the first few days on new hosting before picking back up, so a short dip in crawling is normal. I'd keep the old hosting running until its server logs show traffic has dropped to zero.

Domain Change

A domain change needs everything in the main checklist plus one extra step. Once your 301 redirects are live, you can use the Change of Address tool in Search Console to tell Google about the move, although you'll need both domains verified in Search Console under the same Google account first. Bear in mind the tool only covers moves from one domain or subdomain to another, so if you're switching from HTTP to HTTPS, between www and non-www, or changing paths on the same domain, the redirects on their own will handle it.

If you do use the tool, Google keeps recognising the old-to-new relationship for 180 days, so redirects need to stay live for at least that long. The year-long advice from earlier still applies though, so I'd stick with the longer figure.

At the point of change I'd keep the content, page structure and internal links as close to identical as you can, because the fewer things that change at once, the easier it is for Google to recognise the new domain as the same site.

Frequently Asked Questions

What Is SEO Migration?

An SEO migration is any change to a website that could affect how search engines crawl, index or rank it, such as changing the domain, moving to a new platform or CMS, switching host, restructuring URLs or launching a redesign. The aim is to make that change without losing your rankings or organic traffic.

How Can I Migrate My Website Without Losing My SEO?

Start by benchmarking your rankings and traffic, then build a one-to-one redirect map from every old URL to its closest new equivalent. At launch, keep content and internal links as close to the original as you can, remove any staging blocks and submit a new sitemap, then keep a close eye on Search Console and analytics for several weeks.

Will Changing Web Host Affect My SEO Rankings?

A hosting move on its own shouldn't cause a lasting drop in rankings, as your URLs and content stay the same. If rankings do fall after a move, it's usually down to a setting that changed along the way, so I'd check DNS, robots.txt, redirects, canonical tags, SSL and response codes on the new server before blaming the host itself.

How Long Should I Keep Monitoring After a Migration?

I'd keep monitoring for several weeks after launch. On a medium-sized site Google can take a few weeks or more to start showing the new URLs in place of the old ones, and longer on bigger sites. Problems with redirects, canonicals and internal links often only show up once Google has recrawled them.

If you've got a migration coming up and you'd like a second pair of eyes on the plan, I'm happy to help. I've been an SEO specialist since 2019 and website migrations are one of the SEO projects I take on. Every project starts with a free discovery call, so just drop me a message and we can talk through what you're moving and when.