How to Migrate WordPress Without Losing SEO

Migrating WordPress means moving your files, database, plugins and themes from one server to another, then pointing your domain at the new location. Done properly, visitors and search engines never notice the switch happened. Done badly, you get broken links, missing images and a Google ranking drop that takes months to claw back.

I've watched clients migrate sites themselves at 2am with no backup, and I've watched agencies charge £2,000 for a job that took forty minutes with the right plugin. This guide covers the WordPress-specific parts of migration: exports, the database, plugin conflicts and the DNS (domain name system, the internet's phone book that turns your domain into a server address) cutover. If you haven't chosen a new host yet, read our guide on changing web host without losing rankings first, then come back here for the WordPress mechanics.

How do I migrate WordPress to a new host?

You migrate WordPress by copying three things across: your files (themes, plugins, uploads), your database (all the content and settings), and your domain's DNS records. Get those three right and the site works identically on the new server.

The order matters more than most tutorials admit. Set up WordPress on the new host first, without pointing the domain there yet. Import your files and database, test everything on a temporary URL, and only then switch DNS.

Most people skip the testing step and pay for it later. A site that looks fine on the old server can break silently once it hits new PHP versions or missing server modules. Testing before cutover catches this while nobody but you can see it.

• Back up everything on the old server before touching a single file.
• Set up the new environment and get WordPress core installed and working.
• Transfer files and database, then test on a staging URL or via a local hosts file edit.
• Update DNS only once the new site checks out completely.

What's the safest way to move a WordPress database?

Export it as a SQL file through phpMyAdmin or WP-CLI (WordPress's command line interface), then import it cleanly on the new server. Don't try to copy database files directly between servers. It rarely works.

WordPress stores your site's URL inside the database itself, in the wp_options table and scattered through post content. Import the old database without updating those URLs and your new site will keep redirecting visitors back to the old one.

This is where most DIY migrations fall over. People forget the URL is baked into hundreds of database rows, not just one setting. A search-and-replace tool built specifically for WordPress databases, rather than a generic find-and-replace, is essential because it handles serialised data correctly.

Serialised data is WordPress's way of storing structured information, like widget settings, as a single text string with character counts embedded in it. Edit that string with a normal text editor and you corrupt it. Use a proper database migration tool and this gets handled automatically.

Which WordPress migration plugin should I use?

For most sites, a dedicated migration plugin beats manual file transfer because it handles the database search-and-replace and packages everything into one transferable file. There's no single best plugin for every situation. It depends on site size and hosting setup.

Duplicator is the most widely used option and works well for sites under a few gigabytes. It creates an installer file plus an archive, and you run the installer on the new server to unpack everything automatically.

All-in-One WP Migration is another solid choice, particularly liked for its straightforward interface, though free versions cap the file size you can export without a paid add-on. For larger sites, especially anything running on a VPS (a virtual private server, your own slice of a physical machine with dedicated resources), command-line tools like WP-CLI give you more control and speed.

Whichever plugin you choose, test the exported package on a staging URL first. Plugins occasionally choke on unusual file structures, custom tables from page builders, or oversized media libraries, and you want to find that out before your domain points at a broken site.

How do I move a WordPress site without losing rankings?

You keep your rankings by preserving your URL structure exactly and setting up 301 redirects for anything that changes. Google cares about consistency, not which server hosts your files, so an invisible migration protects your rankings completely.

The biggest ranking-killer is an accidental URL change. Switching from www to non-www, or from http to https during the same migration, changes every URL on your site at once. Do that alongside a host move and you've made two changes simultaneously, which makes any problem twice as hard to diagnose.

Keep the migration and any URL structure change as separate events. Migrate first, confirm everything works and Google is indexing the new server, then make structural changes weeks later if you need to.

Once DNS has switched, check Google Search Console for crawl errors and submit an updated sitemap. HTTP Archive's data on real-world site performance shows migration-related downtime is one of the most common causes of temporary ranking dips, so minimising that window matters more than almost anything else.

What's a proper WordPress migration checklist?

A proper checklist covers preparation, transfer, testing and cutover as four distinct stages, each with its own verification step. Skip verification between stages and small errors compound into a broken launch.

Preparation means auditing what you actually have: how many plugins, how large the media library is, whether you're running any custom code that talks directly to the database. Write this down before you start, because you'll need to confirm nothing was lost afterwards.

The most overlooked item on any checklist is the uploads folder. Media files sit outside the database and outside most plugin exports if the site is large, so they need a separate file transfer via SFTP (a secure file transfer protocol) or your host's file manager.

Should I migrate WordPress manually or use a plugin?

Manual migration works best for large, complex sites with custom infrastructure, while plugins suit the vast majority of standard WordPress sites. Choose based on your site's complexity and your own comfort with server-level tools, not on price alone.

Manual migration gives you full control. You export the database yourself, transfer files over SFTP, and edit the wp-config.php file (which holds your database connection details) by hand. This suits developers and sites with unusual server configurations that plugins don't handle well.

Plugin migration is faster for everyone else. It automates the database search-and-replace, packages files sensibly, and cuts down the number of places you can make a manual typing error. For a standard brochure site or blog, this is the sensible default.

WordPress remains the platform behind well over 40% of all websites according to W3Techs' web technology surveys, which is exactly why migration tooling for it has matured so much. You're not solving a niche problem, you're using tools refined by millions of prior migrations.

How long does a WordPress migration take?

A straightforward WordPress migration takes between thirty minutes and a few hours of hands-on work, plus DNS propagation time running separately in the background. Site size and hosting complexity are the main variables.

Small brochure sites with a handful of plugins can be fully migrated, tested and cut over within an hour using a good plugin. Larger sites with big media libraries, custom database tables from page builders, or e-commerce functionality can take a full working day once you factor in thorough testing.

DNS propagation is the part people misunderstand most. Once you update your domain's records, it can take anywhere from a few minutes to 48 hours for the change to reach every network globally, because of DNS caching at internet service providers. Cloudflare's explainer on DNS covers why this varies so much.

You reduce this waiting window by lowering your DNS TTL (time to live, how long a record is cached) a day or two before migrating. Set it low, migrate, then raise it again once you've confirmed the cutover went smoothly.

What goes wrong during WordPress migrations?

The most common migration failures are missed database URLs, forgotten plugin licence reactivations, and mismatched PHP versions between old and new servers. Nearly all of these are preventable with the testing step most people skip.

PHP version mismatches cause white screens or broken layouts that look catastrophic but are usually a quick fix. Check your new host's default PHP version against what your theme and plugins require before you migrate, not after.

Plugin licence keys tied to a specific domain or server IP address often need manual reactivation post-migration. This catches out premium theme and page builder users constantly, so keep your licence details handy before cutover day.

SSL certificates (which enable https and the padlock icon in browsers) sometimes need reissuing on the new server. Most hosts now provision these automatically through Let's Encrypt, but confirm this before you flip DNS, so visitors never see a security warning.

Best hosts for smooth WordPress migrations

Some hosts make WordPress migration genuinely painless with free migration services and built-in staging environments, others leave you to do everything by hand. This is exactly the kind of detail our HRI score (HostList's independent Hosting Reliability Index) is built to surface, since it weighs real support quality and infrastructure, not marketing claims.

Below is a snapshot of how migration-friendliness varies across host types. Check our full WordPress hosting rankings for current pricing and the complete list.

If you're still comparing providers rather than mid-migration, browse the full hosting directory to filter by migration support, price and HRI score before you commit.

Recommendations

Back up your full site, files and database, before you touch anything else, and store that backup somewhere other than the server you're migrating from.

Test the new site on a temporary URL or hosts file edit before switching DNS, and check forms, checkout and login pages specifically, not just the homepage.

Lower your DNS TTL two days before cutover, keep the old hosting account active for at least a week after, and monitor Google Search Console for crawl errors once the switch is live.

Frequently Asked Questions

Can I migrate WordPress without a plugin?

Yes, by manually exporting the database via phpMyAdmin, transferring files over SFTP, and editing wp-config.php on the new server. This suits developers comfortable with server tools but takes longer and carries more risk of manual error than a migration plugin.

Will migrating WordPress affect my Google rankings?

Not if URLs stay identical and downtime is minimal. Rankings drop when migrations change URL structure, introduce broken links, or cause extended downtime. A clean migration with proper redirects is generally invisible to search engines.

How do I migrate WordPress without downtime?

Build and test the site fully on the new host under a temporary URL before touching DNS. Only switch DNS once everything is confirmed working, so visitors move seamlessly from old server to new with no gap.

Do I need to migrate my email when moving WordPress hosts?

Only if your email is hosted with the same provider as your website, which is common on shared hosting. Check this before migrating, since email and web hosting can usually be moved independently of each other.

What happens to my SSL certificate during migration?

Most modern hosts issue new SSL certificates automatically through Let's Encrypt once your site is live on their servers. Confirm this before DNS cutover so visitors never hit an insecure connection warning during the transition.

The bottom line

WordPress migration is a mechanical process, not a mysterious one, and the failure points are well known and avoidable. Back up properly, test before you cut over, and treat DNS as the last step rather than the first. Do that and you'll move your site without anyone but you ever knowing it happened.