How to Migrate WordPress to New Hosting Without Losing SEO or Data

Overview

A WordPress hosting migration usually involves more than copying a few files. A working site depends on its WordPress files, database, media library, configuration, themes, plugins, scheduled tasks, domain records, SSL, and sometimes separate email services. SEO also depends on URLs, redirects, indexability, internal links, canonical settings, and site availability.

The safest approach is to treat the move as a controlled deployment rather than a single upload. Keep the existing site online while you prepare the new environment, create a restorable backup, test the copied site before changing DNS, and keep the old hosting account available until the new site has been verified.

Before starting, record the current environment:

• WordPress and PHP versions, active theme, plugins, and custom code.
• Database name, file locations, upload directories, and configuration requirements.
• Important URLs, XML sitemaps, robots.txt rules, redirects, canonical settings, and analytics or search tools.
• DNS records for the website, email, verification services, CDN, and other connected tools.
• Current performance, uptime, forms, checkout flows, login areas, and other business-critical functions.

If you are also changing the domain, review the domain and DNS steps in How to Connect a Domain to Web Hosting. If the domain stays the same, the migration is generally simpler because the public URLs do not need to change.

Checklist by scenario

Scenario 1: Moving WordPress while keeping the same domain

1. Choose and prepare the new hosting account. Confirm that it supports the WordPress version, PHP version, database engine, SSL, cron jobs, backups, and resource needs of the site. Create a staging location or temporary hostname if the host provides one.
2. Make a complete backup. Save both the WordPress files and the database. Include wp-content/uploads, themes, plugins, must-use plugins, custom configuration, and server rules such as .htaccess where applicable. Store a copy outside the current hosting account.
3. Check backup integrity. A backup is useful only if it can be restored. Confirm that the archive opens, the database export is readable, and you know the credentials and steps needed to restore it.
4. Copy the site to the new host. Upload the files, create the database and user, import the database, and update the new environment's configuration. Protect the staging site from indexing while it is under review.
5. Test before DNS changes. Use a temporary URL, hosts-file override, or staging domain to check pages, media, forms, logins, search, comments, payments, integrations, and administrator access.
6. Reduce the final data gap. If the site receives orders, registrations, comments, or other database changes, schedule the final copy during a quiet period. Put the site into maintenance mode only when necessary, and record the time of the final database export.
7. Point DNS to the new host. Change only the records required for the website. Do not replace email records blindly. Keep a copy of the old DNS zone and verify A, AAAA, CNAME, MX, TXT, and verification records before editing.
8. Confirm SSL and the canonical domain. Visit both HTTP and HTTPS versions, the preferred hostname, and any www or non-www variant. Confirm that the chosen version resolves correctly and redirects consistently.
9. Monitor after the switch. Test the homepage, key landing pages, forms, transactions, login, media, analytics, search visibility, and error logs. Keep the old host available until the new site is stable.

Scenario 2: Moving to a new domain as well

A domain change adds URL migration work. Build a complete mapping from every important old URL to its corresponding new URL. Use permanent server-side redirects where appropriate, update internal links, canonical tags, XML sitemaps, structured data, social metadata, and configuration references. Do not send every old URL to the new homepage; redirect to the closest relevant replacement or return an appropriate not-found response when no equivalent exists.

Update domain properties and preferred URLs in the search, analytics, advertising, email, and third-party tools you use. Keep the old domain registered and configured long enough for users and crawlers to encounter the redirects. The Website Migration Checklist provides a broader sequence for planning these changes.

Scenario 3: Using a migration plugin or managed migration

Migration plugins can package files and databases, while managed WordPress hosting may provide transfer tools. They can reduce manual work, but they do not remove the need for verification. Check archive size limits, serialized database replacement, excluded files, multisite compatibility, cron behavior, caching, and temporary URL handling. Always retain an independent backup and complete the same pre- and post-launch tests.

What to double-check

• URLs and redirects: Compare a crawl or export of the old site with the new site. Look for broken internal links, redirect chains, incorrect canonicals, missing trailing-slash handling, and accidental redirects to staging.
• Indexing controls: Make sure staging restrictions do not remain on production. Check the WordPress visibility setting, robots.txt, meta robots directives, XML sitemap, and canonical URLs.
• Database and media: Confirm that recent content, authors, metadata, custom fields, thumbnails, PDFs, and image URLs were transferred. Search for references to the old hostname in the database and configuration.
• Email and DNS: Website DNS and email DNS are related but separate concerns. Verify MX records, SPF or other sender records used by your setup, mailbox access, contact forms, and transactional email before closing the old account. For DNS timing and verification methods, see DNS Propagation Explained.
• Performance and security: Confirm caching, compression, image delivery, scheduled backups, firewall rules, file permissions, admin access, and SSL renewal. Check that a CDN or external proxy points to the new origin if one is in use.
• Monitoring: Review server logs, application errors, uptime monitoring, analytics, and search reporting for several days. Compare important page response times with the previous environment rather than relying only on the homepage.

Common mistakes

• Changing DNS before testing: This turns the live domain into the test environment. Test the copied site privately first.
• Backing up only the database: Posts may survive, but uploads, themes, plugins, and custom code may not. A WordPress backup and restore plan needs files and database data.
• Forgetting recent changes: A long migration window can leave new orders, comments, or edits on the old database. Plan a final synchronization or temporary content freeze.
• Replacing the entire DNS zone: This can interrupt email, verification, subdomains, or external services. Edit only the records that must change.
• Leaving staging indexable: Duplicate or unfinished copies can confuse visitors and search engines. Keep staging private and remove those restrictions when production is confirmed.
• Closing the old host immediately: Retain the old environment until backups, redirects, email, and critical workflows have been checked. A rollback is much easier when the original site still exists.
• Ignoring caching: Old pages or redirect behavior can remain visible through host, plugin, CDN, or browser caches. Purge relevant layers and retest from an independent connection.

When to revisit

Revisit this checklist before every WordPress hosting migration, domain change, major redesign, or infrastructure upgrade. It is especially useful before seasonal planning cycles, high-traffic campaigns, product launches, or a period when the site cannot easily tolerate downtime.

Update the checklist when your workflows or tools change. A new CDN, DNS provider, backup system, deployment process, payment integration, or managed WordPress host may introduce different validation steps. Also revisit it after a migration incident: add the missing check to the process while the cause is still clear.

For the next move, save the final DNS records, backup locations, test results, URL map, rollback decision, and launch timestamps in one accessible document. Then use this short action list:

1. Freeze the migration plan and assign an owner for each technical check.
2. Create and test independent backups of files and the database.
3. Build and privately test the new WordPress environment.
4. Record and verify DNS, email, SSL, redirects, and indexing settings.
5. Switch traffic during a monitored window and test the highest-value user journeys.
6. Keep rollback materials and the old hosting account available until evidence shows the move is complete.

A careful migration is not defined by how quickly DNS changes. It is defined by whether visitors, administrators, search engines, and connected services continue to reach the right content after the move.