Website Migration SEO Checklist: How to Move Without Losing Rankings

A website migration is one of the few technical projects that can undo years of SEO work in a matter of days. Replatforming, redesigning, moving to HTTPS, or consolidating domains — each carries the same risk: search engines re-evaluate your site from scratch unless you give them clear signals that nothing of value has changed. The mistakes are rarely dramatic. They're quiet: redirects that resolve to the wrong page, canonical tags pointing at staging URLs, or a robots.txt file that never got updated after launch. This article gives you a structured website migration SEO checklist so you can move your site without handing your competitors a free rankings boost.

If you're looking for expert help in this area, explore how Indexed's technical SEO services can drive measurable results for your business.

What Counts as a Website Migration in SEO Terms

Teams often underestimate the scope of what triggers an SEO migration. A migration is not just moving from one host to another — it is any significant change to a site's URL structure, domain, protocol, platform, or content architecture.

Common migration types

• Domain change: Rebranding to a new domain name entirely
• HTTPS migration: Moving from HTTP to HTTPS (which changes every URL on the site)
• Platform change: Moving from Magento to Shopify, or WordPress to a headless CMS
• URL restructure: Changing folder structures, slugs, or removing/adding subdirectories
• Subdomain consolidation: Merging blog.example.com into example.com/blog
• Internationalisation changes: Restructuring hreflang and country-specific URLs

Each of these changes signals to Google that something fundamental has shifted. The job of your SEO checklist for website migration is to make that signal as predictable and clean as possible.

Pre-Migration: The Work That Decides the Outcome

Most migration failures are decided before the site goes live. The pre-migration phase is where you build the safety net. Skipping it because the launch date is immovable is the single most common reason teams come to agencies three months later asking why organic traffic halved.

Crawl and benchmark your existing site

Before touching anything, run a full crawl of the existing site using a tool such as Screaming Frog or Sitebulb. Export every indexable URL, its status code, title tag, meta description, canonical tag, and inbound internal links. This is your baseline — the document you will compare against post-launch to identify anything that broke.

At the same time, pull your top-performing pages from Google Search Console by clicks, impressions, and average position. These are the pages with the most to lose. They should be the first URLs you verify after launch, not the last.

Map your redirects before you build them

Create a URL mapping document that lists every old URL and its corresponding new destination. For large sites this is time-consuming — but a missing redirect on a high-authority page passes no link equity forward and the page effectively starts from zero in the index. Every redirect should be 301 (permanent). Chains of more than one hop should be collapsed into direct redirects wherever possible, as each hop dilutes the signal passed along.

Audit your backlink profile

Export your inbound backlink data from Google Search Console or a third-party tool. Identify the pages on your current site that receive the highest number of referring domains. These are migration priorities — they carry the most accumulated authority and any gap in redirect coverage here causes disproportionate damage.

Launch Day: What to Check Before You Flip the Switch

Launch day should be the quietest part of a well-managed migration because every decision has already been made. The role of your website migration checklist on the day itself is verification, not problem-solving.

Staging environment checks

• Confirm staging is blocked from indexing via robots.txt and/or a noindex meta tag — and that this block will be removed (not carried over) on the live site
• Test a sample of redirects across old URLs in the staging environment
• Verify canonical tags on the new site point to the correct live URLs, not staging versions
• Check that internal links have been updated to new URLs, not relying entirely on redirects

The HTTPS migration detail most teams miss

If your migration includes a move to HTTPS, every variation of your domain needs to resolve to a single canonical HTTPS version. That means HTTP, www, and non-www variants should all redirect in a consistent chain to https://www.yourdomain.com (or non-www if that is your preferred version). Mixed content — assets such as images or scripts loading over HTTP on HTTPS pages — will suppress the security benefit and can generate console errors that affect crawlability on some configurations. Run your new pages through a mixed content checker before declaring the HTTPS migration complete.

Post-Migration: The 72-Hour Verification Window

The first 72 hours after launch are when most migration errors become visible. Search engines begin recrawling quickly once a new sitemap is submitted, so catching problems early limits how far incorrect signals propagate.

Immediate technical checks

• Submit your updated XML sitemap to Google Search Console and Bing Webmaster Tools
• Use the URL Inspection tool in Search Console to test that key pages are indexable
• Re-crawl the live site and compare status codes against your baseline — flag any URLs returning 404 that should be redirecting
• Confirm robots.txt on the live site does not block Googlebot from crawling key directories
• Check that structured data (schema markup) has carried across correctly using Google's Rich Results Test

Monitor Search Console coverage reports

Within a week of launch, watch the Coverage report for spikes in "Excluded" or "Crawled — currently not indexed" URLs. A sudden increase in either category is a signal that Google is encountering something unexpected. It does not always mean disaster, but it warrants investigation before allowing the pattern to continue unchecked.

The Redirect Chain Problem Competitors Do Not Talk About

Most SEO migration guides tell you to implement 301 redirects. Fewer explain what happens when those redirects accumulate over time — which is almost always the case for sites that have been through more than one migration.

Consider a site that moved from HTTP to HTTPS two years ago, then changed its URL structure last year, and is now replatforming. If each migration simply layered redirects on top of the previous ones, a single URL might now route through three or four hops before reaching the live page. Google's documentation on redirects confirms that while Googlebot follows chains, the equity passed through each hop reduces, and chains slow crawl budget consumption on large sites.

The correct approach during any migration is to audit existing redirect chains first and collapse them. If old-URL-A redirects to intermediate-URL-B which redirects to new-URL-C, update the redirect so old-URL-A points directly to new-URL-C. This is unglamorous work that rarely appears in a migration brief — but it is the difference between a clean authority transfer and a slow bleed of ranking power that nobody can trace back to its source six months later.

This is also where an HTTPS website migration SEO checklist diverges from a standard domain migration checklist: when every URL on a site changes protocol, the potential for chains to form is magnified across thousands of pages simultaneously.

FAQ

How long does it take to recover rankings after a website migration?

For a well-executed migration with clean redirects, correct canonicals, and prompt sitemap resubmission, most sites see rankings stabilise within four to eight weeks. Some fluctuation in the first two weeks is normal — Google is recrawling and reassessing. Sites that experience significant drops beyond eight weeks typically have a technical issue (broken redirects, incorrect canonicals, or a crawl block) that needs diagnosing rather than waiting out.

Do I need to notify Google before migrating?

If you are changing your primary domain, Google Search Console has a Change of Address tool that signals the move to Google directly and helps accelerate recrawling. For URL restructures on the same domain, the tool does not apply — your sitemap submission and redirect implementation do the equivalent job.

What is the most common cause of traffic loss after a migration?

In our experience, the single most common cause is a redirect mapping that was built from the site's sitemap rather than a full crawl. Sitemaps only include URLs the team intended to include — they miss orphaned pages, older blog posts, and legacy landing pages that still carry backlinks. A full pre-migration crawl captures all of these. Skipping it means those URLs return 404 after launch and pass no equity forward.

Should I migrate and redesign at the same time?

If you can avoid it, keep them separate. Combining a platform migration with a full content restructure and visual redesign introduces too many variables to diagnose if something goes wrong. If business constraints force them together, ensure your SEO checklist for website migration is signed off before the design brief is finalised — not retrofitted afterwards.

What to Do This Week

If a migration is on your roadmap in the next three to six months, here are the specific steps to take before your next planning meeting:

• Commission a crawl now. Do not wait until a week before launch. Run Screaming Frog against your current site today and export the full URL list. This is your baseline document — and it takes time to build the redirect map from it.
• Pull your top 50 pages from Search Console. Filter by clicks over the last three months. These are your non-negotiable redirect priorities. Brief whoever is building the redirect mapping to account for every one of them.
• Ask your development team one question: "Does our staging environment block indexing, and how are we confirming that block is removed at launch?" If they cannot answer immediately, add it to the technical brief.
• Book a redirect chain audit. If your site has been through any previous migration, run your current URLs through a redirect checker and identify chains longer than one hop. Collapsing them before the next migration is cheaper than rebuilding authority afterwards.
• Decide who owns post-launch monitoring. The 72-hour window after go-live needs a named person checking Search Console coverage daily. If that person is not already assigned, assign them now.

A website migration done well should be a non-event from an organic traffic perspective. The checklist exists precisely so that the hard thinking happens before go-live, not after.

Related Reading

• What Are Common SEO Mistakes?
• Why Does SEO Still Matter in 2026?
• What Makes a High-Quality Backlink? (And What to Avoid)
• Entity SEO: How to Build Knowledge Graph Authority
• Content SEO: How to Create Content That Ranks, Converts and Gets Cited by AI