How to Move a WordPress Site to a New Host (Without Downtime or Lost Rankings)
Changing hosts sounds scary because the whole site is at stake, but the actual risk comes from doing the steps in the wrong order. Do it copy-first, and there is a safe moment to test everything before a single visitor is affected. This guide walks the move end to end, calls out the two things that trip people up most (DNS timing and email), and then asks a fair question: if the reason you are moving is that WordPress hosting is slow, pricey or high-maintenance, is a new host really the fix?
Before you touch anything: what a WordPress site is made of
A WordPress site is two things living together. There are the files (WordPress itself, your theme,
your plugins and your uploaded images in wp-content) and there is the database (your pages,
posts, settings and users). A move has to bring both across intact, and your DNS, the address book that tells the world
which server answers for your domain, has to be repointed at the end. Miss any of those and the site arrives broken. Get
all three right and it arrives whole.
The safe order: copy first, switch last
Here is the sequence that avoids downtime. The golden rule is that your domain keeps pointing at the old host until the copy on the new host is proven to work.
1. Back up everything. Take a full backup of your files and a full export of your database, and download both to your own computer. A migration plugin can do this, or you can do it by hand over SFTP plus a database export. Either way, this is your safety net; do not skip it.
2. Set up the new host as a copy. Create the site on the new host, upload the files, import the
database, and enter the database connection details in wp-config.php. You now have a second, identical
WordPress install waiting in the wings, with your live site still untouched.
3. Test it on a temporary URL. This is the step careless guides skip. Most hosts give you a staging or preview URL, or you can add a line to your computer's hosts file, so you can load the new site at your real domain in your browser only, before the rest of the world sees it. Click every important page. Submit a form. Check images, the checkout, the contact page. Fix anything broken now, while it costs you nothing.
4. Lower your DNS TTL a day ahead. TTL is how long the internet is allowed to cache your old DNS answer. Drop it to a low value (say 300 seconds) a day before the switch, so when you flip the record the world picks up the change in minutes instead of hours.
5. Switch the DNS. Point your domain's A record (or CNAME) at the new host. Because you lowered the TTL and the old host is still running, visitors flow gradually to the new server with no gap. Some see the new host in minutes; a few stragglers take up to 24 to 48 hours as caches expire.
6. Keep the old host running for 48 hours. Do not cancel the old hosting the moment DNS flips. Leave it live for a couple of days so anyone still hitting the old server sees a working site until every cache has moved over.
The two traps most guides skip
DNS caching. A hosting move is never instant, because the world caches DNS. If you forget to lower the TTL first, some visitors keep landing on the old host for a day or more, which is fine if it is still running and a disaster if you already cancelled it. Lower the TTL ahead of time, switch, and wait before you tear anything down. Our domain-cutover write-up in moving off WordPress without losing rankings goes deeper on this.
Email. This is the classic 2 a.m. surprise. If your email lives on the same provider as your old hosting, repointing the domain can silently break sending and receiving, because the mail-related DNS records move too. Before you switch, write down your current MX, SPF, DKIM and DMARC records, make sure they are set at whoever will manage your DNS after the move, and test that mail works the moment the cutover finishes. For the wider list of things people forget, see WordPress migration mistakes to avoid.
Does moving hosts hurt SEO?
It should not, as long as your URLs stay the same. Google ranks a page by its address, example.com/services,
not by which server answers for it, so serving that exact URL from a new host is invisible to search. Rankings only slip
when URLs change without redirects, when pages return errors during a sloppy cutover, or when the new host is noticeably
slower. So: keep every URL identical, add 301 redirects for any that genuinely have to change, avoid downtime by testing
before you switch, and resubmit your sitemap in Google Search Console afterward so Google re-crawls fast. WordPress
publishes its own guide to moving WordPress
if you want the platform's own reference on the mechanics.
A fair question: is a new host actually the fix?
Most people move hosts because the current one is slow, expensive, or a hassle. A new host can help with speed and price, but it does not touch the hassle: you carry the same WordPress across, which means the same updates, the same backups, the same security patches and the same plugin conflicts, now with a new landlord. If maintenance is the real pain, changing hosts treats the symptom.
The alternative is to convert the site to fast static pages that no longer need a database or plugins, so most of that ongoing work simply disappears. That is what ShiftPress does: it migrates your existing WordPress site as-is, the same design, the same content, the same URLs, to static pages that load fast, almost never go down, and need no patching. The cutover follows the same copy-first, test, then switch-DNS discipline above, so there is no downtime and no lost rankings, and it handles the backup, the testing and the redirects for you. See how it works on move off WordPress without the risk.
| Concern | Move to a new WordPress host | Migrate to static (ShiftPress) |
|---|---|---|
| Downtime during the move | None, if you copy-first and switch DNS last | None, same copy-first cutover |
| Rankings | Kept, if URLs stay the same | Kept, same URLs, plus a speed gain |
| Ongoing maintenance | Same as before: updates, backups, patches | Mostly gone: no database or plugins |
| Page speed | Depends on the new host | Fast static pages by default |
| Security surface | Same plugins and login to attack | Far smaller, nothing to hack in the usual way |
| Who does the work | You (or an agency) | ShiftPress migrates it for you |
Move once, and stop maintaining WordPress.
Instead of carrying WordPress to a new host, ShiftPress moves your site to fast static pages, same look, same URLs, same rankings, with no downtime and nothing left to patch. Start with a free look at your site.
Get started ↗The move-hosts checklist
- Back up all files and export the database, and download both to your own computer.
- Set the new host up as a full working copy: files, database, and
wp-config.phpconnection details. - Test the copy on a temporary or staging URL, every key page, form and image, before touching your domain.
- Lower your domain's DNS TTL a day before the switch so the change propagates fast.
- Repoint DNS (A or CNAME) to the new host only after the copy is confirmed working.
- Keep the old host running for at least 48 hours so no one hits a dead page during propagation.
- Note and re-set your MX, SPF, DKIM and DMARC records so email keeps working.
- Keep every URL the same (or add 301s), then resubmit your sitemap so Google re-crawls quickly.
Frequently asked questions
How do I move a WordPress site to a new host without downtime?
Will moving hosts hurt my Google rankings?
What's the difference between moving hosts and migrating off WordPress?
What about my email when I move WordPress hosts?
The bottom line
Moving a WordPress site to a new host is safe when you copy first, test on a temporary URL, and switch DNS last, with the old host kept alive through propagation and your email records carried over. Do that and you get no downtime and no lost rankings. But if the reason you are moving is the endless maintenance, a new host just relocates it. Converting to static removes it. If that is the real goal, start with migrating WordPress to a static site.