WordPress Migration Checklist: Move Your Site Without Breaking SEO or Email

Overview

If you only remember one rule, make it this: separate the migration into phases. Back up first, build and test on the destination, switch traffic carefully, then verify the site and supporting services after launch. Most migration problems happen when teams combine too many changes at once without a rollback plan.

A practical wordpress migration checklist should help you answer four questions before you touch production:

• What exactly is moving: files, database, domain, DNS, email, or all of them?
• What should stay unchanged: URL structure, metadata, email routing, analytics, and search visibility?
• How will you validate success: admin login, page rendering, forms, redirects, SSL, crawlability, and backups?
• How will you reverse the change if something fails?

For most site owners, a safe migration plan looks like this:

1. Inventory the current site and hosting setup.
2. Take complete backups and export critical settings.
3. Prepare the new hosting environment.
4. Copy files and database.
5. Update configuration and test on a temporary URL, hosts file, or staging domain.
6. Review DNS, SSL certificate, and email DNS records before cutover.
7. Launch during a low-traffic window.
8. Run post-launch checks for SEO, performance, forms, and email.
9. Monitor logs, uptime, and crawl errors for several days.

If you are still choosing a destination environment, it helps to compare hosting models before you move. See WordPress Hosting Comparison Guide: Shared, Managed, VPS, and Cloud Options and Shared Hosting vs VPS vs Cloud Hosting: Which Option Fits Your Website Now?.

Checklist by scenario

Use the scenario that matches your move. The core steps overlap, but the risk points differ depending on whether the domain, DNS, and email systems are changing too.

Scenario 1: Move WordPress site to a new host, same domain

This is the most common wordpress hosting migration. Your goal is to change infrastructure while keeping the public site address the same.

• Audit the current setup: note PHP version, database version, WordPress version, active plugins, theme, cron jobs, SSL method, CDN, WAF, caching layers, and disk usage.
• Document DNS: export or record A, AAAA, CNAME, MX, TXT, SPF, DKIM, and DMARC records. This matters even if email stays elsewhere.
• Lower DNS TTL in advance if possible: do this before cutover to shorten propagation delay.
• Take full backups: copy wp-content, WordPress core if needed, database dump, .htaccess or web server rules, robots.txt, and any custom config files.
• Build the destination environment: create database, upload files, import the database, and set file permissions appropriately.
• Update wp-config.php: confirm database name, user, password, host, table prefix, and any environment-specific constants.
• Test before switching DNS: use a staging URL, temporary domain, or local hosts file override.
• Verify plugin compatibility: pay close attention to caching, image optimization, security, backup, redirect, and page builder plugins.
• Install and test SSL certificate: confirm HTTPS works on the destination before making it public.
• Cut over DNS: point the domain to the new host only when the destination has passed testing.
• Keep the old host live briefly: do not cancel immediately; retain it as a fallback during propagation.

Scenario 2: Move WordPress and change domain

This adds SEO and URL mapping work. A domain change is not just a hosting task; it is also a search and brand continuity task.

• Export a full URL inventory: include top pages, posts, media URLs, landing pages, category pages, and important PDFs or downloads.
• Map old URLs to new URLs: preserve path structure where possible. The less unnecessary URL change, the better.
• Update site URLs carefully: change WordPress Address and Site Address, or handle URL replacement safely in the database.
• Run a controlled search-and-replace: update internal links, image references, and serialized data carefully.
• Apply 301 redirects: redirect old URLs to their new equivalents, not just the homepage.
• Update canonical tags: make sure they point to the new live domain.
• Update XML sitemap and robots.txt: regenerate sitemap and confirm robots rules do not block search engines by mistake.
• Verify search console and analytics settings: update properties, default URLs, referral exclusions, and goals as needed.
• Retain the old domain: keep it active long enough to support redirects and preserve link equity.

If the domain itself is also being moved between registrars, treat that as a separate project when possible. See Domain Transfer Checklist: How to Move a Domain Without Downtime.

Scenario 3: Move WordPress while keeping third-party email active

This is where many migrations go wrong. The website moves smoothly, but business email stops because DNS records were overwritten.

• List all current email records: MX, SPF, DKIM, DMARC, autodiscover, mail-related CNAMEs, and any verification TXT records.
• Confirm where DNS is hosted: registrar DNS, current host DNS, CDN DNS, or another provider.
• Do not replace the entire zone file blindly: merge web changes into existing records where required.
• Check mail routing after cutover: send and receive test messages from external accounts.
• Test forms and transactional mail: contact forms, order confirmations, password resets, and SMTP plugins are common failure points.

For a deeper walkthrough on DNS changes, see How to Connect a Domain to Web Hosting: DNS Steps for Every Setup.

Scenario 4: Move a WooCommerce or dynamic WordPress site

Stores, membership sites, LMS platforms, and communities need extra care because content changes constantly.

• Schedule a maintenance window: reduce the chance of lost orders or user-generated content during database sync.
• Freeze high-risk changes: pause product imports, plugin updates, design edits, and bulk content actions before migration.
• Take a fresh final database export near cutover: this captures latest orders, registrations, and form entries.
• Test payments and checkout: use sandbox or controlled live testing if available.
• Check scheduled tasks: confirm WP-Cron or server cron jobs run correctly on the new host.
• Review object cache and page cache exclusions: cart, checkout, account, and login pages should not be cached improperly.

Scenario 5: Move from shared hosting to VPS or cloud hosting

This migration often improves flexibility, but it introduces more operational responsibility.

• Confirm server stack parity: web server, PHP modules, database engine, memory limits, and image libraries should support your existing site.
• Review security baseline: firewall, fail2ban or equivalent, SSH access, user permissions, update policy, and backup automation.
• Set up monitoring before launch: uptime, disk, CPU, memory, error logs, and certificate expiry should be visible from day one.
• Benchmark after migration: measure page generation, cache behavior, and database response to verify the move actually improved performance.

If you are comparing environments for a small business site, these guides can help: Best Hosting for Small Business Websites: Features, Limits, and Upgrade Paths.

What to double-check

This is the part to revisit right before launch and immediately after launch. A migration can appear successful while still breaking SEO signals, email flows, or admin tasks in less obvious ways.

1. Backups and rollback readiness

• You have a current downloadable copy of files and database.
• You know where backups are stored and how to restore them.
• You have not canceled the old hosting account too early.

2. DNS and domain routing

• The domain points to the intended host.
• www and non-www resolve consistently.
• Required subdomains still work.
• TTL changes have been planned, not improvised.

3. SSL certificate and HTTPS behavior

• The SSL certificate is active for the correct hostname.
• HTTP redirects to HTTPS properly.
• There is no mixed content from hard-coded assets.
• Admin and login pages work securely.

4. SEO integrity

• Meta titles and descriptions are intact.
• Canonical tags point to live URLs, not staging or old domains.
• 301 redirects are in place where URLs changed.
• XML sitemap is current and reachable.
• robots.txt is correct and not blocking the site unintentionally.
• Staging noindex settings have been removed from production.

For wordpress migration seo, the main priority is continuity. Search engines generally handle infrastructure changes better than structural URL changes. If you preserve the domain, URL paths, content, metadata, and internal linking, the SEO risk is usually lower than many site owners expect.

5. WordPress functionality

• You can log in to wp-admin.
• Permalinks work on posts and pages.
• Media files load correctly.
• Search, forms, comments, and user login work.
• Scheduled posts and cron-driven tasks run.
• Backups resume on the new environment.

6. Email and form delivery

• MX records are unchanged or intentionally updated.
• SPF, DKIM, and DMARC records still exist after DNS edits.
• Contact forms deliver to the right inboxes.
• Password resets and order emails are sent successfully.

7. Performance and caching

• Page cache and object cache are configured for the new host.
• CDN settings are updated if origin IP changed.
• Old cache is purged after launch.
• Core pages load without unusual delay.

8. Security and access

• File permissions are sane and not overly permissive.
• Security plugins are active and not locking out valid users.
• Firewall or rate limiting rules are not blocking crawlers or payment callbacks.
• Administrative passwords and secrets have been reviewed if the site changed environments significantly.

Common mistakes

These are the migration errors that create the most disruption, even on otherwise straightforward projects.

Changing too many variables at once

A hosting move, domain rebrand, redesign, plugin cleanup, and analytics rewrite should not happen in one cutover unless there is a strong reason. When something breaks, the root cause becomes harder to isolate.

Testing on staging but not on the actual destination setup

A staging site may not match the exact PHP version, cache layer, SSL path, or DNS behavior of production. Test where the site will really run.

Forgetting hidden dependencies

Examples include SMTP plugins, external API callbacks, image offload tools, payment webhooks, cron jobs, hard-coded asset URLs, custom font hosts, and server-level redirects.

Overwriting DNS zone records

This is the classic email outage. A site owner updates A records for the website and accidentally removes MX or TXT records required for business email hosting.

Leaving noindex or password protection in place

Many teams protect staging environments, which is sensible. The mistake is pushing those settings live and quietly blocking indexing or user access.

Not checking redirects page by page

If the domain changes, redirecting every old URL to the homepage is a weak fallback. It creates a poor user experience and can dilute relevance signals.

Ignoring post-launch monitoring

A migration is not finished at DNS cutover. Some issues only appear after real traffic arrives: checkout errors, slow uncached pages, image path problems, and intermittent mail failures.

When to revisit

Keep this website migration checklist handy whenever your infrastructure or workflows change. The best time to review it is before you need it urgently.

Revisit and update your migration plan when:

• You are changing web hosting type, such as from shared hosting to managed WordPress, VPS hosting, or cloud hosting.
• You are planning a domain change, subdomain restructure, or registrar move.
• You adopt a new CDN, WAF, SMTP provider, or DNS management workflow.
• You add ecommerce, memberships, multilingual routing, or other dynamic features.
• You change backup tools, deployment methods, or team responsibilities.
• You are heading into a seasonal traffic period and need a safer change window.

Before your next migration, do this short preparation pass:

1. Create a one-page inventory of hosting, DNS, SSL, email, backups, and critical plugins.
2. Record who owns access to the registrar, DNS provider, host, CDN, and email system.
3. Decide whether the move affects only hosting, or also the domain and email stack.
4. Set a rollback threshold in advance, such as checkout failure, admin lockout, or unresolved SSL issues after a defined time.
5. Book a low-traffic launch window and assign one person to DNS, one to application testing, and one to communications.

That final step matters more than it seems. Even a technically sound migration becomes stressful if nobody owns the checklist.

If your move also includes domain lifecycle decisions, it is worth reviewing related guidance on domain renewal and registrar access controls ahead of time.

Use this checklist as an operational document, not just a one-time article. Every WordPress site has a slightly different combination of hosting, plugins, DNS, and email dependencies. The process stays stable, but the details change. Update your checklist when tools change, repeat the same validation steps every time, and you will make cleaner moves with fewer surprises.