Moving a WordPress site to a new hosting provider is one of those tasks that sounds simple until rankings start slipping a week later. Most site owners worry about the same thing: will Google still see the pages the way it did before, or will the move cause lost traffic, broken links, and a drop in visibility? The good news is that a host change does not have to damage SEO. Most ranking losses after migrations come from avoidable mistakes such as changed URLs, broken redirects, blocked crawlers, slow servers, or missing content, not from the move itself. This guide explains how to migrate a WordPress website to a new host while keeping the URLs, content, and technical signals that search engines rely on.

Why a Hosting Migration Can Affect Search Rankings

Search engines do not rank your hosting company. They rank the pages they can reach, load, and understand. A migration touches several things at once: the server responding to requests, the files and database that make up your site, the domain's DNS records, and sometimes the URL structure itself. If any of these change in a way that search engines notice, you may see temporary fluctuations or, in worse cases, lasting losses.

The most common causes of post-migration ranking problems include:

• Pages returning 404 errors because permalinks or files were not transferred correctly.
• Redirect chains or missing 301 redirects when URLs change.
• Staging or development settings, such as noindex tags or password protection, left active on the live site.
• Slower server response times on the new host, which can affect crawling and user experience.
• Mixed content warnings or SSL certificate issues after the move.
• Robots.txt files that block search engines, often copied over from a staging environment.
• Internal links pointing to an old domain, old subdomain, or an HTTP version of the site.
• Caching or CDN configuration that serves outdated or broken pages to crawlers.

Most of these issues are preventable with a checklist and a few hours of careful testing. The sections below walk through that process in the order most migrations should follow.

Before You Start: Document the Current State

You cannot protect rankings you have not measured. Before touching anything, record how the site performs now so you can compare it after the move.

Start with Google Search Console. Export the performance report for the last three to six months, including top queries, top pages, impressions, clicks, and average position. Also download the coverage or indexing report so you know which URLs are currently indexed and which have errors. Google Analytics or another analytics tool should be captured the same way, focusing on organic traffic by landing page.

Next, crawl the site with a tool such as Screaming Frog SEO Spider or a similar crawler. Export a list of every indexable URL, its status code, its title tag, its canonical tag, and any redirects in place. This list becomes your reference for verifying the new site later. Keep a copy of your current .htaccess or Nginx configuration if you have custom rules, as well as your robots.txt and XML sitemap.

Finally, create a full backup. This includes the WordPress files, the MySQL database, and any uploads folder. Store at least one copy outside the current hosting account.

Choose the Right Migration Method

There are three common ways to move a WordPress site, and the right choice depends on your technical comfort and the complexity of the site.

Host-assisted migration

Many hosting providers offer free or paid migration services where their team copies your files and database. This is the simplest option for non-technical owners, but you should confirm exactly what is included, whether email accounts and DNS are handled, and what happens if something breaks.

Migration plugin

Plugins such as All-in-One WP Migration or Duplicator can package the site and import it into the new environment. They work well for small to medium sites. Be cautious with large databases, serialized data, and sites with custom server rules, as plugins can struggle with those.

Manual migration

A manual move involves exporting the database with a tool like phpMyAdmin or WP-CLI, downloading the files over SFTP, creating a new database on the new host, importing the data, and updating the wp-config.php file with the new database credentials. This gives you the most control and is often the cleanest option for larger or customized sites. It also requires the most care with search-and-replace of URLs inside the database.

Whichever method you use, the key principle is the same: the new site should be as close to an exact copy of the old one as possible, with no unintended changes to URLs, content, or technical settings.

Build and Test on a Staging Environment

A staging copy lets you find problems before visitors and search engines do. Most new hosts provide a temporary URL or a staging area. Import the site there first, then review it thoroughly.

Check that the homepage, key service or product pages, blog posts, forms, and checkout processes all work. Click through the main navigation and compare it against your crawl export. Make sure images load, custom fonts render, and any scripts that depend on file paths still function.

Because staging sites are often set to noindex and blocked by robots.txt, you should be careful that these settings do not accidentally carry over to the live site. This is one of the most common and most damaging migration errors, so it deserves its own check later in the process.

Handle URLs, Permalinks, and Redirects Correctly

URL structure is the core of SEO continuity. If the URLs stay the same after the move, search engines have no reason to treat the pages as new. Your goal is to keep every indexable URL identical unless you are deliberately changing it.

Confirm that the permalink structure on the new host matches the old one. Go to Settings > Permalinks in WordPress and check that the structure is the same. Then, if you are using a custom server configuration, verify that rewrite rules work correctly, since a missing rule can turn every inner page into a 404.

If the domain itself is changing, for example from a non-www to a www version, or from HTTP to HTTPS, you need permanent 301 redirects from every old URL to its matching new URL. Redirects should be one step, not chains. A chain such as old URL to intermediate URL to final URL wastes crawl budget and can dilute signals.

When you update the site address and WordPress address in Settings > General, make sure both use the final canonical version of the domain. Then run a search-and-replace on the database to update any hard-coded old URLs in posts, widgets, menus, and theme options. Be sure to use a tool that handles serialized data safely, such as WP-CLI's search-replace command or a dedicated plugin, because a plain text find-and-replace can corrupt serialized values.

Preserve Technical SEO Signals

Beyond URLs, several technical elements influence how search engines understand your site. Each should be verified after the move.

Robots.txt and meta robots tags

Open your live robots.txt file in a browser and confirm it allows crawling of your important sections. Check that no page