Website Migration Checklist: Move Your Site to a New Host Without Losing SEO

Overview

This checklist is designed for site owners, creators, small businesses, and teams that need a practical way to move a live website to a new host. It focuses on hosting migration rather than a full rebrand or domain change, although some of the same principles apply.

The safest way to move a site to a new host is to treat it like a controlled launch. That means you prepare a full inventory, lower the chance of data drift during the move, test the new environment before changing traffic, and verify every critical function after go-live. SEO usually suffers during migrations for predictable reasons: broken redirects, inconsistent URLs, missing metadata, blocked crawling, slow performance, or DNS mistakes. A good hosting migration guide prevents most of these issues before they happen.

Before you begin, separate three related but different tasks:

• Website hosting migration: moving site files, databases, and application settings to a new server.
• DNS update: pointing your domain to the new host by changing nameservers or DNS records.
• Domain transfer: moving domain registration from one registrar to another. This is optional and does not have to happen at the same time.

If you are changing hosting only, keep the registrar and domain settings stable unless there is a clear reason to change them. Combining too many changes at once makes troubleshooting harder. If you also need to move the domain itself, review a separate domain transfer process so the hosting cutover stays clean. For background, see How to Transfer a Domain Name Without Downtime: Step-by-Step Checklist.

Use this operating principle throughout the migration: copy first, test second, switch traffic third, monitor fourth.

Checklist by scenario

This section gives you a website transfer checklist by phase and by common migration type. If you only remember one thing, remember this: do not point the domain to the new host until you have tested the new site carefully.

Universal pre-migration checklist

• Define the reason for the move. Are you leaving slow shared hosting, upgrading to managed WordPress hosting, moving to VPS or cloud hosting, or consolidating multiple sites? Your reason affects the setup and the testing plan.
• Audit the current site. List all live URLs, main templates, plugins or modules, forms, checkout flows, scripts, redirects, image directories, cron jobs, and integrations.
• Export a full backup. Save files, databases, media, and any application-specific settings. Store a copy outside both the old and new hosts.
• Record DNS settings. Export or screenshot existing A, AAAA, CNAME, MX, TXT, and any custom records before changing anything. This matters if your site, email, or verification records are split across providers. For help, see DNS Records Guide: A, AAAA, CNAME, MX, TXT, NS, and When to Use Each.
• Inventory email services. Confirm whether business email is hosted with your web host or a separate provider. Many site migrations go wrong because MX records are overwritten during cutover. If email is important to the business, double-check it separately using How to Set Up Business Email on Your Domain.
• Lower DNS TTL if appropriate. If you manage your own DNS and know your current setup, reducing TTL ahead of time can help changes propagate faster later. Do this well before launch, not at the last minute.
• Document current SEO signals. Save title tags, meta descriptions, canonicals, structured data, robots directives, sitemap URLs, top landing pages, indexed pages, and priority backlinks.
• Benchmark performance. Note current load speed, uptime expectations, and server response patterns so you can compare after the move.
• Choose the target environment carefully. The right destination depends on your CMS, traffic level, and maintenance needs. If you are comparing environments, see Managed WordPress Hosting vs Shared Hosting, Shared Hosting vs VPS vs Cloud Hosting, and Best Web Hosting for Small Business Websites.
• Freeze nonessential site changes. Pause design edits, plugin installs, and content publishing close to migration time unless your workflow includes a final sync plan.

Scenario 1: WordPress site moving to a new host

• Check PHP version compatibility, database version, memory limits, and file upload limits.
• List active plugins, theme dependencies, custom code snippets, and any server-level caching tools.
• Copy the database and the wp-content directory, including uploads, themes, and plugins.
• Recreate environment-specific settings in wp-config or host dashboard settings if needed.
• Disable or clear old cache layers before the final sync.
• Test permalinks, media URLs, forms, search, login, comments, and scheduled posts on the staging or temporary URL.
• Confirm that SEO plugins, XML sitemaps, robots settings, and canonical tags behave the same way on the new host.

Scenario 2: Static site or portfolio site moving hosts

• Copy the complete build output or source repository and confirm the deployment method.
• Check relative and absolute links, image paths, font files, JavaScript bundles, and form endpoints.
• Verify redirects and custom error pages if they were previously handled at server level.
• Confirm that analytics scripts, cookie banners, and tag manager snippets are still loading correctly.
• Check SSL behavior and mixed-content warnings after the move.

Scenario 3: Ecommerce or database-heavy site

• Schedule the migration during a lower-traffic window.
• Plan a content freeze or maintenance mode period for orders, customer accounts, inventory, and transactional data.
• Verify payment gateways, tax tools, shipping modules, and transactional emails in a test environment.
• Run a final database sync as close as possible to cutover time.
• Place a test order after launch and confirm order confirmation emails, stock reduction, and admin notifications.

Scenario 4: Multiple sites under one account

• Create a separate checklist per domain or subsite.
• Map each site to its own document root, database, SSL certificate, and backup plan.
• Check wildcard DNS, subdomains, multisite rules, and staging domains before go-live.
• Confirm that one site’s cache, rewrite rules, or security settings will not affect another site unexpectedly.

Cutover checklist: the actual switch

• Upload and configure the site on the new host.
• Test privately before changing DNS. Use a hosts file override, temporary URL, or staging domain if your host supports it.
• Install and validate SSL. The site should load securely and redirect to the canonical HTTPS version. If needed, review SSL Certificate Setup Guide: How to Secure Your Website and Fix HTTPS Errors.
• Check robots settings. Make sure staging noindex rules are removed from the production site before launch.
• Update DNS records or nameservers. Only change what is necessary to point the website to the new host. If you are unsure how to connect domain and hosting cleanly, see How to Connect Your Domain to Web Hosting.
• Do not cancel the old host immediately. Keep it live until traffic and services are confirmed stable.

Post-migration checklist: first 24 to 72 hours

• Load the homepage, top landing pages, blog posts, category pages, and contact page on desktop and mobile.
• Check logins, forms, search, comments, carts, account pages, and media playback where relevant.
• Confirm redirects from old URL patterns still work.
• Review crawlability: robots.txt, XML sitemap, canonicals, status codes, and noindex tags.
• Check analytics and search console verification if scripts or DNS records changed.
• Monitor server errors, broken image paths, mixed content, and 404 pages.
• Confirm email delivery and DNS health, especially MX, SPF, DKIM, and TXT records if they share the same zone.
• Submit the sitemap again if your platform regenerated it or the location changed.

What to double-check

This is where many site migration SEO issues appear. A site can look fine on the surface while still sending the wrong signals to search engines or breaking important business functions.

URLs and canonical structure

Check whether the live site resolves consistently to one preferred version:

• HTTPS instead of HTTP
• Preferred www or non-www version
• Single canonical URL for each page
• No accidental duplicate archives, tags, or filtered URLs being exposed

If URL structure changed at all, map old URLs to the closest new destination with proper redirects. Avoid sending many old pages to the homepage unless there is no better equivalent.

DNS and domain settings

Make sure only the records that needed to change were changed. It is common to update A records for the website and accidentally remove mail-related records or domain verification TXT entries. If your registrar and host are different providers, keep a written record of where DNS is managed and who controls nameservers. If you are reviewing domain setup more broadly, a companion piece on domain privacy protection can help you tidy registration settings while keeping migration scope separate.

SSL and mixed content

A valid certificate is not the same as a complete HTTPS migration. Double-check:

• Automatic redirect from HTTP to HTTPS
• No internal links still pointing to HTTP
• No images, scripts, or fonts loading over HTTP
• Canonical tags and sitemap URLs using HTTPS

Technical SEO signals

• Robots.txt allows crawling where appropriate
• No accidental noindex on templates or key pages
• XML sitemap is accessible and current
• Schema or structured data still renders correctly
• Core page titles and meta descriptions survived the move
• Internal links still point to valid URLs

Performance and server behavior

• Server response is stable under normal traffic
• Caching is not serving old versions after launch
• Compression, image handling, and CDN settings work as intended
• Redirect chains are minimized
• Error pages return the right status codes

Business-critical functions

• Contact forms send and arrive
• Checkout works end to end
• Lead magnets, downloads, and gated content still deliver
• Membership or subscription logins work
• Business email is unaffected

Common mistakes

A strong website migration checklist is valuable because the same mistakes happen repeatedly. Here are the ones most likely to create downtime, SEO loss, or cleanup work.

Changing host, domain, design, and URL structure all at once

Every extra moving part makes root-cause analysis harder. If possible, change hosting first. Rebrand, redesign, or restructure later.

Skipping a full backup because the host offers migration assistance

Host-assisted migration can be useful, but you should still keep your own backup copy and your own list of current settings.

Testing only the homepage

Templates can hide deeper problems. Test top pages, old blog posts, form pages, media-heavy pages, and any custom templates.

Forgetting about email and DNS side effects

This is one of the most expensive simple mistakes. Website traffic may recover quickly; lost email leads or support tickets may not.

Leaving noindex or password protection in place

Staging safeguards are good until they are accidentally pushed live. Always verify indexability after launch.

Removing the old host too early

Propagation, cache layers, and delayed issues can surface after the first successful page load. Keep the old environment available until you are confident the new one is stable.

Ignoring redirects after URL changes

If folder structures, slugs, or trailing slash behavior changed, rebuild redirect logic deliberately. Do not assume the new host will replicate the old rules automatically.

Not monitoring after cutover

A migration is not complete at DNS change. Watch traffic patterns, crawl errors, form submissions, and user reports for several days.

When to revisit

This checklist is worth revisiting any time the inputs around your site change. A migration plan should not live in your head or in an old support ticket. Keep it as a working document and update it before major site operations.

Revisit this guide in these situations:

• Before seasonal planning cycles. If your site has busy periods, plan migrations well outside revenue-critical windows.
• When workflows or tools change. New plugins, a new CDN, a different email provider, or changes in DNS management all affect migration steps.
• Before upgrading hosting tiers. Moving from shared hosting to VPS, cloud hosting, or managed WordPress hosting often changes caching, server rules, and support boundaries.
• When consolidating websites. Multi-site environments need clearer mapping of domains, SSL, backups, and redirects.
• Before redesigns or CMS changes. Even if the trigger is a redesign, review the hosting migration checklist because SEO risk often overlaps.

For practical use, turn this article into a simple action plan:

1. Create a migration document with owners, dates, rollback steps, and a list of critical URLs.
2. Export backups and DNS records before touching the new host.
3. Build and test the new environment privately.
4. Switch DNS only after content, SSL, forms, and SEO settings are confirmed.
5. Monitor the site for at least several days before cancelling the old host.

If you are launching a site for the first time rather than moving an existing one, keep a separate launch checklist handy: How to Launch a Website on a New Domain: Complete Beginner Checklist.

The best migrations feel almost uneventful to visitors. That is usually the result of careful preparation, not luck. Save this checklist, adapt it to your stack, and review it every time you need to move a website to a new host.