WordPress Hosting Migration Checklist: Move a Site Without Losing SEO or Email

Overview

A successful website migration is a controlled change, not simply a file upload. The safest approach is to build and test the new environment while the existing site remains live, then switch traffic only after the new copy is ready.

Before starting, record the current setup. Note the WordPress version, PHP version, database type and version, active plugins and themes, scheduled tasks, media directories, caching configuration, DNS records, SSL behavior, email provider, analytics tools, and any custom server rules. This inventory gives you a baseline for rebuilding the site and investigating differences after the move.

Choose a destination that supports the site's actual requirements rather than relying on a hosting label alone. Confirm available PHP and database versions, storage, memory limits, HTTPS support, automated backups, staging options, cron access, SSH or file access if needed, and the hosting control panel. For guidance on matching resources to traffic, storage, and email needs, see the hosting plan resource checklist.

Keep the old hosting account active until the new site has passed testing and the DNS change has had time to propagate. Do not cancel the old service immediately after the first successful page load; a delayed problem may require a temporary rollback.

Checklist by scenario

Before you copy anything

• Choose a migration window with low publishing, transaction, and support activity.
• Export a complete database backup and download all WordPress files, including uploads, themes, plugins, and configuration files.
• Verify that backups can be opened or restored. Keep at least one copy outside the current hosting account.
• List all domains, subdomains, aliases, parked domains, and development environments.
• Record DNS records, especially A, AAAA, CNAME, MX, TXT, and any verification records.
• Document forms, payment integrations, webhooks, API connections, analytics, tag managers, and firewall allowlists.
• Check the destination's PHP and database compatibility before changing versions. Use the site's tested versions rather than upgrading several components during the move.

If DNS will be changed, lower the relevant DNS record TTL ahead of the cutover, where your DNS provider allows it. Do this early enough for the lower value to be observed by resolvers. TTL reduction does not instantly remove cached records, so keep the old site available during the transition.

Build and test the new copy

• Create the destination database and database user with the required permissions.
• Copy the WordPress files and import the database using the destination hosting panel, a migration tool, or a command-line workflow.
• Update database credentials and, if necessary, table prefixes or site URL settings carefully.
• Use a temporary hostname, hosts-file entry, or password-protected staging URL to test the site before public DNS changes.
• Confirm that uploads, images, downloadable files, custom post types, menus, widgets, and theme assets load correctly.
• Check permalink settings and test representative posts, pages, category archives, author pages, search results, and feeds.
• Install or provision the SSL certificate on the new host and test both HTTP and HTTPS behavior.
• Recreate server-level rules, redirects, caching, compression, security headers, and PHP settings only after documenting the originals.

For version-related decisions, use the PHP compatibility and rollback guide. A host migration is usually a poor time to combine an untested PHP change with a major plugin, theme, or WordPress upgrade.

Prepare the cutover

• Place the site in a brief maintenance mode only if the final database sync requires it.
• Pause publishing, orders, registrations, and form submissions during the final synchronization when data loss is possible.
• Take a fresh database backup and copy files changed since the first transfer, especially the uploads directory.
• Confirm the new site's canonical domain, WordPress Address, and Site Address are correct.
• Update A or CNAME records as planned, but leave email records pointing to the existing mail provider unless email is also being migrated.
• Monitor DNS resolution from more than one network or location.

After DNS changes

• Test the homepage, key landing pages, login, admin area, forms, checkout or booking flows, search, and downloads.
• Verify that HTTP redirects to HTTPS and that the preferred hostname redirects consistently.
• Check that no staging URL, password protection, noindex directive, or development robots.txt file remains active.
• Review 404 logs and server logs for missing assets, incorrect redirects, PHP errors, and blocked requests.
• Confirm analytics, tag management, conversion tracking, and consent-related scripts still load as intended.
• Run a fresh backup on the new host and confirm that scheduled backups complete.
• Keep the old environment available until traffic, forms, email, and background tasks are stable.

What to double-check

Email and DNS

Website DNS and email DNS are related but separate. A web migration may require changing an A or CNAME record while leaving MX records unchanged. Recheck MX, SPF, DKIM, and DMARC records with the email provider before and after the change. Send and receive test messages using more than one mailbox, and test website-generated messages such as contact forms, password resets, order notices, and notifications.

If email is moving too, treat it as a separate migration project. Export or synchronize mailboxes, verify aliases and forwarding, publish the provider's required records, and plan for delivery delays. Do not assume that copying WordPress files transfers email.

SSL, URLs, and redirects

Test the certificate on the final domain, including common subdomains that are expected to work. Inspect pages for mixed content caused by hard-coded HTTP image, script, stylesheet, or iframe URLs. A redirect should send each retired URL to its most relevant current destination rather than redirecting every old page to the homepage. Preserve existing URL paths where practical; if paths change, prepare one-to-one permanent redirects and test them individually.

Review the SSL troubleshooting checklist if browsers report certificate, redirect-loop, or mixed-content errors.

SEO and crawlability

Compare the old and new site's title tags, canonical URLs, meta robots directives, XML sitemap, structured data, internal links, and status codes. Confirm that the production site is not blocked by robots.txt or a staging noindex setting. In Google Search Console or the relevant webmaster tool, verify the property, inspect important URLs, submit the current sitemap if appropriate, and watch indexing and coverage reports after the move.

Use a crawl or a representative URL sample to find 404 responses, redirect chains, accidental 302 redirects, duplicate hostnames, and canonical tags pointing to the old environment. A host change by itself should not require changing content or URL structure.

Cron jobs and performance

WordPress scheduled actions may depend on traffic or on a server cron job. Confirm that publishing, backups, cache clearing, email queues, imports, and other recurring tasks run on the new host. Check the host's cron syntax, timezone, PHP executable path, and permissions.

Compare response times and resource usage with the old setup under normal conditions. Recheck page caching, object caching, image delivery, PHP workers, database connections, and CDN settings. For ongoing checks, use the monthly hosting uptime and reliability review.

Common mistakes

• Relying on one backup: Keep independent copies and test restoration before the cutover.
• Changing too many variables: Avoid combining migration, redesign, plugin replacement, PHP upgrade, and URL restructuring unless there is a clear reason and rollback plan.
• Forgetting recent database changes: A database-only final sync may be required for stores, memberships, comments, bookings, and form submissions.
• Moving the website but breaking email: Preserve MX and authentication records when email remains with the current provider.
• Testing only the homepage: Test real user journeys, logged-in areas, forms, downloads, and transactional messages.
• Leaving staging controls enabled: Remove temporary passwords, noindex directives, hosts-file overrides, and development URLs before launch.
• Closing the old host too soon: Retain it until DNS, applications, backups, and monitoring are confirmed stable.
• Having no rollback trigger: Define in advance which errors justify restoring the old DNS target and how you will do it.

A practical rollback plan includes the old hosting account, a current backup, the previous DNS values, access to the DNS provider, and a short record of every change made during cutover. If the new site causes severe errors, restore the previous DNS target, pause writes where necessary, and investigate using logs before trying again.

When to revisit

Use this checklist before every host change, domain move, major redesign, staging deployment, or recovery from a failed migration. Review it before seasonal planning cycles if the site handles campaigns, transactions, or unusually high publishing volume.

Refresh the operational details whenever WordPress, PHP, database software, migration tools, DNS services, hosting panels, SSL automation, or search-console workflows change. The exact menu names and supported versions vary by provider, so confirm them in the destination host's current documentation before execution. A formal review twice a year is a sensible minimum for frequently maintained sites.

Final action: copy this checklist into the migration ticket, assign an owner to each item, record the old and new DNS values, define the rollback threshold, and obtain a second review of backups, email records, SSL, redirects, and crawlability before changing DNS. After cutover, document the final configuration so the next migration starts with an accurate baseline.