Website migration checklist: domain, platform and hosting moves without lost rankings

A website migration checklist is a step-by-step plan for moving a site to a new domain, platform, CMS or host without losing search traffic. The core is simple: inventory every URL, redirect each old URL permanently to its closest new page, test before launch, then monitor Google Search Console and fix errors for months afterwards.

Most migrations that lose traffic fail on the same few things: missing redirects, redirects to the home page instead of the matching page, content or metadata left behind, and nobody watching Search Console after launch. This checklist is built around Google's own documentation, with each step linked to the instruction it comes from. It covers moves; if you're redesigning on the same platform and domain, use our website redesign SEO checklist instead.

What counts as a website migration?

The rule of thumb: risk follows URL changes. Google calls these "site moves with URL changes" and "site moves without URL changes", and treats them differently. When several changes stack up (new domain, new platform and a redesign all at once), problems become harder to diagnose.

What should you do before you start?

Inventory

• Crawl the live site and export every indexable URL, status code, title, meta description, canonical and H1.
• Export URLs with traffic from your analytics (12 months), with impressions and clicks from Search Console, and with backlinks from your link tools.
• List XML sitemaps, robots.txt rules, hreflang tags and structured data.
• Record images, PDFs and other files that get traffic or links.

Baselines

• Save Search Console performance by page and query, Core Web Vitals, index coverage and crawl stats.
• Record organic sessions, conversions and revenue by landing page.
• Note your top 50 to 100 keywords and their positions.

Backups and access

• Full backup of files and database, stored outside the old host.
• Access to the registrar, DNS, old and new hosting, CDN, Search Console (both properties), analytics and tag manager.
• Keep the old site's hosting until you've confirmed the move is stable.

Plan

• Choose a launch date away from your peak season.
• Agree who owns each task and who can approve a rollback.
• Set up a staging site that search engines can't index.

How do you build the redirect map?

The redirect map is the single most important document in a migration. It's a spreadsheet with one row per old URL and the new URL it should go to.

1. Map one-to-one wherever possible: each old page to the new page that best matches its content.
2. When pages merge, redirect all of them to the merged page. When a page is removed with no equivalent, send it to the closest relevant parent, or let it return 404 or 410 if nothing fits. Mass redirects to the home page waste the old pages' signals and confuse users.
3. Use permanent redirects. Google says: "we recommend that you use HTTP permanent redirects if possible, such as 301 and 308." Its redirects guide adds that "Google Search interprets instant meta refresh redirects as permanent redirects", and to "Only use JavaScript redirects if you can't do server-side or meta refresh redirects."
4. Avoid chains. Point old URLs straight at their final destination, and update older redirects that point at URLs you're now moving.
5. Update internal links to point at new URLs directly, so the site doesn't depend on its own redirects.
6. Test the full list with a crawler before launch and again after.

What extra steps does each migration type need?

Domain change

• Verify both old and new domains in Search Console.
• Redirect every old URL to its matching URL on the new domain, page by page.
• Submit a Change of Address. Google's site move guide says: "If you're changing domain names or subdomains, submit a Change of Address in Search Console for the old site."
• Follow the tool's prerequisites. Google's Change of Address help says to "Implement a 301 redirect from your old homepage to your new homepage."
• Keep the old domain registered and renewing. If it lapses, every redirect dies.
• Ask your most valuable linking sites to update their links.

Platform or CMS change

• Check how the new platform builds URLs (trailing slashes, forced folders such as /products/ or /blogs/news/) and plan redirects around them.
• Move content in full: body copy, headings, images with alt text, titles, meta descriptions, canonicals and structured data.
• Rebuild templates for every page type and compare them with the old ones for missing content.
• Recreate forms, tracking and conversion events and test them end to end.
• For moves to WordPress, check the host meets current requirements: PHP "version 8.3 or greater".
• Choosing between platforms? See Webflow vs WordPress.

Hosting only (URLs stay the same)

Google's guide to site moves without URL changes covers this case.

• Lower DNS TTL in advance. Google suggests you "Consider lowering the TTL to a conservative low value (for example, a few hours)".
• Copy the site, test it on the new host by IP or a temporary hostname, then switch DNS.
• Keep the old server running until traffic has fully moved.
• Expect Googlebot to slow down briefly: "it's normal to see a temporary drop in Googlebot's crawl rate immediately after the launch".
• Moving servers or applications to the cloud, not just a website? See cloud migration and our cloud migration checklist.

HTTP to HTTPS

• Install a valid certificate covering every hostname you use.
• Redirect every http:// URL to its https:// equivalent with a permanent redirect.
• Update canonicals, internal links, sitemaps, hreflang and embedded resources to HTTPS.
• Don't use the Change of Address tool. Google's help page lists HTTP to HTTPS as a case where the tool should not be used.

What should you check on launch day?

• Remove staging blocks: noindex tags, password protection, a disallow-all robots.txt.
• Run the redirect map through a crawler. Every old URL should return a single 301 or 308 to a 200 page.
• Spot-check the top 50 pages by traffic: content, title, meta description, canonical, structured data.
• Submit the new XML sitemap in Search Console. Google notes that "Submitting a sitemap can help make the discovery process quicker".
• Confirm analytics and tag manager fire on every template, and test a real conversion.
• Check page speed and Core Web Vitals on key templates.
• Watch server logs and error monitoring for spikes in 404 or 5xx responses.

What should you do after launch?

First week

• Check Search Console daily: page indexing, crawl stats and any manual action or security messages.
• Fix any 404s that receive traffic or links by adding redirects.
• Inspect key URLs with the URL Inspection tool and request indexing for the most important.

First three months

• Compare organic clicks, impressions and conversions with your baseline, page by page.
• Re-crawl monthly to catch new redirect chains or broken internal links.
• Update any remaining internal links, canonicals and hreflang tags that still point at old URLs.

First year and beyond

• Keep redirects in place. Google says: "Keep the redirects for as long as possible, generally at least 1 year."
• For domain moves, remember that Change of Address signals have a fixed window: "These actions continue for 180 days after you start migration in Search Console."

How long does recovery take, and when should you roll back?

Expect some movement. Google needs to recrawl old URLs, follow the redirects and process the new pages, and that takes time, especially on large sites. For a well-run hosting move, the effect is usually small. For domain and platform moves, plan for weeks of fluctuation and judge the result over months, not days.

Set your rollback triggers before launch, not after:

Rolling back an SEO change after Google has started processing it can cause a second disruption, so most teams fix forward unless the site is broken for users. That's why testing on staging matters more than anything you do after launch.

What's different about ecommerce migrations?

Online stores have more URL types and more data than brochure sites, and errors cost sales immediately. Add these to the checklist:

• Map product, category, collection, brand and filtered URLs separately. Faceted URLs often shouldn't be indexed at all; decide which ones carry traffic before redirecting.
• Keep product identifiers (SKUs, GTINs) consistent so shopping feeds and marketplace listings keep working.
• Migrate reviews, ratings and their structured data, not just product descriptions.
• Move customer accounts and order history, and plan how customers set new passwords.
• Re-create discount codes, gift cards, tax rules and shipping rates, then test real orders with each payment method. Our payment gateway integration team handles that part.
• Update product feeds in Google Merchant Center and other channels on launch day.
• Avoid launching in your peak trading period; choose a quiet week and keep the old store ready.

Who should own each part of the migration?

Write the names in, not just the roles. Migrations stall when everyone assumes someone else is watching.

What are the most common migration mistakes?

• Redirecting everything to the home page.
• Launching with the staging noindex tag still on.
• Forgetting images, PDFs and old campaign URLs that still get links.
• Changing domain, platform, URLs and design all at once with no baseline.
• Letting the old domain expire.
• Removing redirects after a few months to "clean up".
• Nobody owning Search Console for the first month.

How can Elgrith help?

Elgrith has delivered 1,000+ projects for 250+ clients since 2015, from our New Delhi headquarters and client centers in New York, London and Shanghai. Our website migration team plans and runs domain, platform and hosting moves, our technical SEO team builds the redirect map and monitors recovery, and we build destination sites on Webflow, WordPress and Shopify, including Shopify moves for US brands through our New York Shopify team. You get a fixed written quote after a free call. Book a call or start a project.