The Easiest Way to Move WordPress to a New Host

The easiest way to move WordPress to a new host is to change the host and nothing else. Copy files and database across, test the site on the new server before any DNS change, lower the TTL a day in advance, then switch only the records that point at the website. Every URL stays identical, which is why WPBuildAI treats a host move as the one migration with almost no SEO risk: Google distinguishes moves with URL changes from moves without them, and a move without them gives search engines nothing to relearn. The danger is not the move. It is bundling it with a redesign, a domain transfer or a URL change so that three variables land on the same afternoon.

Why is a host move so much safer than a platform move?

Because the thing that carries your rankings is the address, and no address changes.

A platform move rebuilds every page, usually changes some URLs, and asks search engines to reprocess the site one address at a time. That is where redirect maps, recrawl delays and recovery curves come from.

A host move changes which computer answers when someone requests exactly the same address. The HTML that comes back is the same HTML. There are no redirects to write, no map to test, and no signal transfer to wait for.

What remains is operational rather than editorial: do not lose data, do not go down, and do not break email. Those three are the whole risk, and all three are avoidable with a sequence rather than skill.

What is the actual sequence?

Six steps, in this order, and the order is what keeps the downtime at zero.

Step three is the one people skip and the one that removes almost all the anxiety, because it turns the switch into a formality rather than a test.

How do you test the site before switching?

With a hosts file entry, which makes your computer resolve your domain to the new server while everybody else still gets the old one.

Add a line mapping your domain and its www form to the new host’s IP address. Your browser now loads the new server at the real URL, so links, images, forms and the admin all behave as they will after the switch, rather than at a temporary preview address that hides path problems.

Click through the real pages: the homepage, a service page, a blog post, the contact form, and the checkout if you have one. Submit a form and confirm it arrives. Log into the admin.

Then remove the line. This is the step people forget, and its symptom is confusing: everything looks fine to you for days while visitors see something else entirely.

Which DNS records do you actually change?

Only the ones pointing at the website. Everything else stays exactly as it is, and this distinction is what keeps a host move from taking down email.

Export the whole zone before touching it, not just these rows. A screenshot of the DNS panel takes a minute and turns a bad afternoon into a two minute rollback. Cloudflare’s DNS documentation covers the mechanics if your records live there.

The failure to guard against is a host that manages DNS deleting records it did not create when the old account closes. Keep the old hosting active for a week or two after the switch, and cancel deliberately rather than letting it lapse.

What can actually go wrong?

Four things, and none of them is caused by the move itself.

A slower server. Ranking impact is indirect and real: time to first byte is the part of performance the host controls, and moving from a good host to a cheap one is a downgrade visitors feel. Measure the new host through the hosts file entry before switching, not after.

A robots file arriving from the new host. Some hosts ship a default that blocks crawlers, or a staging configuration comes across with the copy. Read the live robots file on the production domain immediately after the switch, and view source on three pages for a stray noindex.

An older PHP version on the new host. WordPress documents a minimum, and a site copied onto an older version can break on arrival. Check the version before copying rather than after.

Mixed content, if the old host handled the certificate differently. Pages load and images do not, because content references http while the page is served over https.

What should you check after the switch?

Six things in the first hour, from outside your own network, because your machine may still be answering from cache.

Load the site on mobile data rather than office broadband. Check both the bare domain and www, over both http and https, since visitors and old links use all four forms and only one of them is the one you tested.

Send yourself a message from an outside address and confirm it arrives in the inbox rather than spam. Send one from your domain to an outside address and check the same. Then submit the site’s contact form, because form mail often sends through a different route than your normal email.

Read the live robots file, and confirm the site returns a genuine not found status for a deliberately invalid address rather than a friendly page with a 200.

Then leave it alone. There is no recrawl to monitor and no recovery curve to watch, which is the pleasant difference between this and a platform move. The version of that monitoring that does apply to bigger moves is in what to do in the first week after a migration goes live.

What does it cost, and should you pay someone?

Two to four hours of competent work, or a fixed fee from most hosts, and the decision turns on how much of the six step sequence you are comfortable owning.

Many hosts migrate for free as part of onboarding, and that offer is genuinely good value for a straightforward site. What it usually covers is step two, copying files and database. What it usually does not cover is testing on the new host before the switch, managing the TTL, protecting your mail records, or verifying afterwards from outside your network.

So the practical approach is to accept the free copy and own the sequence around it. Ask the new host to stage the site without touching DNS, then do steps three to six yourself.

Paying somebody is worth it in three situations. A store, because a checkout that breaks mid switch costs more than the fee. A site whose email runs on the same domain and hosting, because that is where the expensive mistakes live. And any site where nobody in the business can confidently read a DNS panel, since the whole risk in a host move is concentrated in one screen.

For a brochure site with mail at a separate provider, this is a genuinely straightforward afternoon and there is no reason to pay for it.

When is a host move the wrong fix?

When the problem is the site rather than the server. A slow WordPress site with twenty six plugins and a page builder generating the markup will be slow on any host, and moving it produces a small improvement and a large sense of anticlimax. Measure first, and the diagnosis is in why is my WordPress site so slow.

It is also the wrong fix when the real cost is maintenance rather than hosting. Hosting is usually under fifteen percent of what a WordPress site costs to run, so changing it barely moves the annual total, which is itemised in what does a WordPress site really cost per year.

And it is wrong to combine with anything else. A host move plus a redesign, or plus a domain transfer, or plus a URL change, turns a zero risk operation into a project where several things can fail with one set of symptoms. Do the host move on its own, confirm it, then do the next thing a fortnight later.

Where a host move genuinely helps: a server that is slow or unreliable, a host you cannot get support from, a plan that no longer fits your traffic, or an account in somebody else’s name. Those are real reasons and each is fixed by exactly this sequence.

Key takeaways: moving hosts without drama

No URL changes, so there is no redirect map, no recrawl and no recovery period. This is the safest migration there is.

Test on the new host through a hosts file entry before any DNS change. That single step turns the switch from a test into a formality.

Change only the records pointing at the website. Mail and verification records stay untouched, and the whole zone gets exported first.

Keep it a single variable. A host move bundled with a redesign or a domain transfer stops being a host move and starts being a project with three ways to fail.

Questions we get on this

What is the easiest way to migrate WordPress to a new host? Copy files and database to the new host, test the site there through a hosts file entry before touching DNS, lower the TTL a day in advance, then switch only the records that point at the website. Keep every URL identical. WPBuildAI treats a host move as the one migration with almost no SEO risk, provided nothing else changes at the same time.

Will changing hosts affect my SEO? Not by itself. No URL changes, so search engines have nothing to relearn and no redirects are needed. What can affect rankings is a slower server, a period of downtime during the switch, or a robots file that arrives from the new host blocking crawlers. All three are avoidable and none is caused by the move itself.

How do I test the site on the new host before switching? Add an entry to your computer’s hosts file pointing your domain at the new server’s IP address. Your browser then loads the new host while the rest of the world still sees the old one, so you can click through the real site at its real URLs. Remove the entry afterwards, or you will keep seeing the old copy.

How long does the switch take? Minutes, if the TTL was lowered a day beforehand. The DNS record change itself is instant, and resolvers pick it up within the TTL window you set. Both hosts serve the same site during the overlap, so visitors see one or the other and neither is broken, which is why nobody should see downtime.

Should I not just use a migration plugin? A plugin is fine for a straightforward site and it is not a substitute for the sequence. It copies files and database, which is the mechanical part, and it does not verify the site on the new host, manage the TTL, protect your mail records, or check the result afterwards. The plugin does one step of six.