Moving a WordPress site to a new host or server

A WordPress site changes host or server for good reasons: poor performance, an offer that costs too much, a PHP version that is no longer maintained, a need for security or support. The content does not change, but everything that runs it moves: the files, the database, the configuration, the certificate. Done well, the move is invisible to visitors and to Google alike.

This article covers moving a site that is already on WordPress. If your site is not on WordPress yet, see our articles on migrating an HTML site to WordPress and migrating from Wix to WordPress.

A WordPress site has two parts, which move together:

• the files: the WordPress core, the wp-content folder (themes, plugins, uploaded media), the wp-config.php file and, on Apache, the .htaccess file that holds the permalinks and redirects;
• the database: posts, pages, settings, accounts, comments, and orders if there is a shop.

Add what lives at the host and is not copied: the HTTPS certificate, scheduled tasks, the domain's email addresses, and the web server rules if it runs Nginx. List them before you start.

Plugins such as Duplicator or All-in-One WP Migration bundle files and database into an archive, which you restore on the new server. Many hosts also offer their own migration tool. It is the simplest route for a modest site; on a large site, the archive size or the server limits can make it fail.

Copy the files over SFTP or rsync, export the database (mysqldump or WP-CLI) and import it on the new server, then update wp-config.php with the new database credentials. If the site address changes, run the search and replace with wp search-replace or a plugin that respects serialised data: a raw replacement in the SQL file breaks theme and plugin settings.

1. Back up the whole site, files and database, and keep the copy off both servers.
2. Test the new server before switching: by pointing the domain to the new IP address on your own computer only (hosts file), you see the site as it will be, with its real domain name.
3. Lower the time to live (TTL) of the DNS records a day or two beforehand, so the change propagates quickly.
4. Freeze the content during the switch: a comment or an order received on the old server after the copy would be lost.
5. Change the DNS, and keep the old server online for a few days, until every visitor reaches the new one.

As long as page addresses stay the same, changing host needs no redirect. It is different if you use the move to change domain name, switch to HTTPS or change the permalink structure: every old URL must then answer with a 301 redirect to the new one, in a single hop. For a domain change, also declare it in Search Console (Change of Address tool). See our article on switching to HTTPS and the one on redirects in WordPress.

Crawl the site before the move and keep the list of its URLs with their response codes; crawl it again after the switch and compare. Also check what gets lost most often:

• the "Discourage search engines from indexing this site" box, ticked on the test server and copied as is;
• the robots.txt file and the sitemap, which must answer on the new server;
• the HTTPS certificate, installed and valid before the DNS change;
• response times, often the reason for the move: compare them.

Then watch Search Console for a few weeks: crawl errors, indexed pages, rankings.

If the move comes with a redesign or a change of addresses, the redirect plan becomes the main issue. Swan crawls the old site and the staging site, proposes for each old URL the page that replaces it by semantic proximity, lets you validate the doubtful cases, then checks the redirects before and after go-live. The steps common to any platform change are described in the CMS change procedure.