Moving your website to different hosting: how to prevent downtime and SEO issues

Moving your website to different hosting sounds like you switch off the old server at one moment and hope the new one takes over. That is exactly how you end up with unnecessary downtime, missing email, or half a website on the wrong server.

A safe move works differently: you first build a complete copy on the new hosting, test it while the old website stays live, and only then change DNS. If you keep the same domain name and URLs, switching hosting doesn’t have to be a classic SEO migration with hundreds of redirects either.

When is it time to change hosting?

Switching hosting makes sense when the current environment is structurally holding your website back: recurring outages, slow server response, too few resources, unclear support, outdated software versions, or a plan that no longer fits the website.

Price can of course also be a reason, but don’t move solely for a few euros’ difference if that means giving up good support, backups or stability. For a business website, predictable support is often more important than the cheapest plan.

Before you decide, also check whether the problem really lies with the hosting. A heavy WordPress site with poor plugins will not automatically be fast on another server. If performance is the main reason, first investigate what is slowing the website down. The guide Speed up WordPress helps separate hosting issues from application issues.

What exactly needs to be migrated?

Component	Why it matters
Website files	WordPress/core, themes, plugins, uploads, custom code and configuration
Database	Pages, products, settings, users, and lots of plugin/store data
Domain/DNS	Determines which server the website and services point to
SSL/TLS	Ensures HTTPS works validly in the new environment
Email and MX records	Must be checked separately if email is tied to the same domain
Cron jobs / tasks	Can control orders, imports, backups, or synchronizations
External integrations	Payments, APIs, webhooks, SMTP, forms, analytics

In WordPress, files and the database are two separate parts of the same site. The official WordPress documentation therefore emphasizes that you need both for a complete backup.

Step 1. Create a restorable backup before you change anything

Start with a full backup of files and database. Store it outside the current hosting environment. A backup that is only on the same server is of little help if you no longer have access to it during the migration.

Also check that you know how to restore it. For an online store or a site with many changes, timing is important: a database copy from yesterday can mean new orders, forms, or accounts are missing. Therefore, plan when you do the last synchronization.

Step 2. Set up the new hosting before you change your DNS

First, set up the website environment, database, PHP version, certificates, and required server settings on the new hosting. Do not make anything live to the public yet.

Check whether the new environment matches your CMS and plugins. WordPress itself can be moved to a new server without having to be reinstalled. If the domain and URLs stay the same, files and the database can often simply be copied; if database details change, they must be updated, for example in wp-config.php.

Do you have server-specific items such as redirects, cron jobs, security rules, caching, or a CDN? Include them in your inventory. Copying only the visible pages is not the same as migrating the entire production environment.

Step 3. Copy the website and database to the new server

For a WordPress site, you can migrate manually, use a reliable migration tool, or have the move carried out by an administrator/hosting provider. The method you choose is less important than the checks afterward.

With a manual migration, the files are moved to the new webroot and the database is imported. Then check database connections, file paths, write permissions, and server configuration. With WooCommerce or other dynamic sites, you need to be extra careful that no new transactions diverge between the old and new database during the final switch.

Step 4. Test the new hosting while the old site remains live

This is the step that prevents downtime. Test the new site before the DNS switch via a temporary hostname or local hosts file, so only you see the new server while regular visitors still go to the old one.

Don’t check only the homepage. Open key landing pages, forms, search function, login, downloads, and mobile navigation. For an online store, test product variants, cart, checkout, payment provider in safe test mode, confirmation emails, and any stock or ERP integrations.

Also pay attention to robots and indexing settings. A test environment must not accidentally appear in Google. For a temporary test host, Google recommends noindex. When you go live, you must of course remove such temporary blocks.

Step 5. Check DNS and lower the TTL in advance where it makes sense

The final hosting switch happens when DNS starts pointing to the new infrastructure. For a planned hosting move, Google advises setting the TTL of relevant DNS records in advance to a conservatively low value, for example a few hours, and ideally doing so at least a week before the move. That way, caches can refresh faster when you switch over.

Before the change, make a copy of your current DNS zone. Don’t look only at the website’s A or AAAA record. MX records, SPF, DKIM, DMARC, subdomains, verification records, and external services can all be in the same zone. An incorrect “clean” DNS zone can make your website work while email or other services fail.

Step 6. Do a final synchronization right before going live

With a brochure website, nothing may change between the first copy and going live. With an online store, booking system, or heavily used form, that can be different. You must not lose new data that comes into the old database after you made the first copy.

Therefore, plan a short change window or a controlled final database synchronization. For stores, it can be wise to temporarily pause orders or use a brief maintenance notice if needed to guarantee data consistency. A few minutes that are planned and clearly communicated is better than reconstructing orders later.

Step 7. Change DNS only when the new site is truly ready

If the tests are green, you adjust the relevant DNS records or name servers. From that moment on, different internet providers will start using the new information at different times. That’s why the old website must keep running during the transition.

Google Search Central advises that, in a hosting switch without URL changes, you should monitor traffic on both the old and the new infrastructure. Once the old server no longer receives any traffic and the new environment works correctly for users as well as Googlebot, you can shut down the old hosting later.

Step 8. Check SSL, forms, email and external links

A homepage that loads is not a successful migration. Check HTTPS and the certificate chain, forms, SMTP, email delivery, webhooks, payment providers, analytics, Search Console verification, caching and scheduled jobs.

Send a test yourself via each important form. For an online store, place a full test order if that can be done safely. Check whether confirmations arrive, transactions are recorded correctly and external systems receive the correct callbacks.

Also review server and application logs. A site may look normal to visitors while errors, time-outs or failed cron jobs occur in the background.

Step 9. Is the URL not changing? Then truly keep it the same

If you are only changing hosting, it is actually an advantage that the visible URLs remain the same. Keep the same HTTPS URLs, canonicals, internal links and sitemap. Then Google doesn’t have to learn a new URL structure.

During testing, don’t use a temporary domain name that later accidentally remains in links, images or canonicals. After going live, check a sample of important pages with Search Console and watch for crawl or indexing errors.

Step 10. Are your domain or URL structure changing as well? Treat that as a separate SEO migration

A hosting switch and a domain switch are not the same project. If old URLs change, create a mapping from each important old URL to the most relevant new URL and use permanent server-side redirects, such as 301 or 308.

Google advises not to make all major changes at the same time where possible. So: if you want to change hosting, domain, CMS and a complete design, reduce the risk by separating those changes when that is practically possible.

A domain migration also involves updated internal links, canonicals, hreflang where relevant, a new sitemap, monitoring in Search Console and, for a real domain change, the Change of Address tool. Leave redirects in place for a long time; Google generally recommends at least a year.

What can go wrong after a WordPress move?

Symptom	Likely direction
White page / 500	PHP error, plugin/theme conflict, configuration or missing extension
Error establishing database connection	Incorrect database details, host or database not reachable
Images missing	Files incomplete, permissions or old paths/URLs
Redirect loop	HTTPS/proxy/cache/redirect configuration conflicts
Form does not send anything	SMTP, DNS, firewall or external email configuration
Only you see the old site	Local/ISP DNS cache or hosts file
Checkout fails	Webhook, API, SSL, session/cache or payment settings

In such a situation, don’t randomly delete plugins or keep changing DNS. Note the error, compare old and new, and work systematically. If the site is completely unreachable after the move, that is a different diagnostic path than a regular hosting choice.

How do you prevent downtime during a website migration?

The principle is simple: the old environment remains available until the new one is proven to work and DNS has largely been switched over. So you copy first, then test, and only switch over as the very last step.

With a dynamic site, “zero downtime” is not the same as “zero migration risk”. Orders, bookings, or forms can still end up on the old environment during the transition. That is why data consistency is just as important as the question of whether the homepage stays online.

When is it better to have the move carried out?

You can move a simple brochure website yourself if you have sufficient technical knowledge. Bring in help as soon as email, online store orders, member accounts, multilingualism, custom work, external APIs, or important SEO positions come into play.

Even if you do not have access to DNS, the database, or the old hosting, it is wise to first arrange ownership and access. A migration under time pressure while the old provider already wants to shut down is exactly the scenario in which mistakes become expensive.

Moonbeetle can support technical moves and checks via the webmaster services. The safest sequence is always the same: inventory, copy, test, switch over, check, and only then close the old environment.

Frequently asked questions about moving a website to other hosting

Will I lose my Google rankings if I change hosting?

Not automatically. If your domain and URLs stay the same and the new server continues to serve the pages quickly and reliably, a hosting change is mainly an infrastructure change. Google does warn that crawl activity can fluctuate temporarily. Major problems mainly arise with downtime, blocks, or unexpected URL changes.

Do I need to set up 301 redirects if only the hosting changes?

Normally not if all visible URLs remain exactly the same. Redirects are needed when URLs or domains change. Do check that HTTPS, www/non-www, and existing redirects keep the same behavior.

How long should the old hosting keep running?

Until you are certain that users, crawlers, and services are using the new environment and the old server is no longer receiving relevant traffic. Google advises monitoring the logs of both environments during the transition.

Can I move a WordPress website without rebuilding it?

Yes. WordPress explicitly documents that when moving to a new server you do not need to reinstall. You move the files and database and adjust configuration where the new environment requires it.

Does email need to move along with the website?

Not necessarily. The website and email can remain with different providers. But carefully check MX, SPF, DKIM, and DMARC records so that a DNS change does not accidentally interrupt mail.

When is a hosting move also an SEO migration?

As soon as the domain name, protocol, or URL paths visibly change. Then you need URL mapping, permanent redirects, and extra Search Console checks.

Sources for further checks

• Google Search Central — changing hosting without URL changes
• Google Search Central — site moves with URL changes
• WordPress Developer Resources — Moving WordPress
• WordPress Developer Resources — Backups