How to Move Your Website to a New Host Without Losing SEO

What a hosting migration means for SEO

There are two very different kinds of migration. A hosting migration moves the same site, on the same domain and the same URLs, to a different server. A site migration with URL changes changes the domain, the URL structure or the platform, and needs redirects and much more care. This guide covers the first. If your URLs are changing as well, read the migration audit guide and migration redirects too.

For a hosting move, Google's own advice is simple: set up the new server, copy everything, test it, switch DNS, and keep watching both servers until traffic has moved. You do not use the Change of Address tool in Search Console, because the domain has not changed. Google may crawl a little more slowly for a short time while it checks the new server can cope, then return to normal.

What can hurt you is not the move itself but what changes by accident:

What to move: the inventory

Before you touch anything, list everything the site depends on. Missed items are the main cause of a migration going wrong.

Save a crawl of the live site at the same time. A list of every URL and its status code is your baseline for checking the new server. The site crawler can export one.

DNS and TTL: how to avoid downtime

The switch happens when you change the A record (and AAAA record, for IPv6) for your domain to the new server's IP address. Resolvers around the world cache the old answer for the record's TTL, time to live, in seconds. If the TTL is 86400, some visitors and Googlebot may reach the old server for up to a day after the change.

Lower the TTL in advance. Set it to 300 seconds at least one full old TTL before the move, often 24 to 48 hours ahead, so the short value has spread everywhere by cut-over day. Check what is currently served:

# Current A record and its remaining TTL
dig example.com A +noall +answer
dig www.example.com A +noall +answer

# Which nameservers are authoritative
dig example.com NS +short

# Check from a public resolver after the change
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com AAAA +short

Because some visitors still reach the old server during the changeover, keep it running with the same content until its logs show traffic has stopped, usually a few days. That is what gives you zero downtime: both servers answer correctly while DNS settles.

If you use Cloudflare with the proxy on, visitors see Cloudflare's addresses, so changing the origin IP in the Cloudflare DNS panel takes effect almost at once and TTL waiting does not apply.

Copying files and the database

Copy server to server rather than downloading to your computer and uploading again; it is faster and keeps permissions intact. From the new server, pull the files over SSH:

# Files, including hidden files, preserving permissions and times
rsync -avz --progress \
  olduser@198.51.100.10:/var/www/vhosts/example.com/httpdocs/ \
  /var/www/vhosts/example.com/httpdocs/

# Database export on the old server, consistent snapshot for InnoDB
mysqldump --single-transaction --default-character-set=utf8mb4 \
  -u dbuser -p example_db | gzip > example_db.sql.gz

# Import on the new server
gunzip < example_db.sql.gz | mysql -u dbuser -p example_db

Update the database name, user, password and host in the site's configuration file on the new server. The domain is unchanged, so you should not need to search and replace URLs in the database.

For a shop or a site that takes bookings, orders keep arriving while you work. Either put the site into maintenance mode for the final copy, or run the database export again just before cut-over so nothing placed in the meantime is lost.

Plesk to Plesk

The free Plesk Migrator extension on the new server can copy subscriptions, including files, databases, mailboxes and many settings, from the old server. Check the migration report afterwards for warnings, and compare redirect and header settings by hand. See redirects in Plesk.

WordPress

The steps above work for WordPress. If you prefer a plugin, use one that moves the database and uploads together, and then check permalinks are still working. More detail is in the WordPress migration guide.

SSL and testing before cut-over

The new server must serve a valid certificate for every hostname, including www, from the first second it receives traffic. You have three options:

1. Copy the existing certificate and key to the new server. It works immediately and you can renew there later.
2. Issue a new certificate with a DNS challenge, which does not need the domain to point at the new server yet.
3. Issue a Let's Encrypt certificate with the normal HTTP challenge right after cut-over. Simple, but there is a short window with a certificate error, so it is the least safe choice.

Then test the new server as if DNS had already moved. curl --resolve sends a request to a chosen IP while using your real hostname, so the certificate and virtual host are tested properly:

NEW=203.0.113.20
for u in / /contact/ /robots.txt /sitemap.xml /old-page/; do
  curl -s -o /dev/null -w "%{http_code} %{time_starttransfer}s $u\n" \
    --resolve example.com:443:$NEW "https://example.com$u"
done
# Check the certificate name and expiry on the new server
curl -vI --resolve example.com:443:$NEW https://example.com/ 2>&1 | grep -E "subject:|expire date:"

To browse it yourself, add a line such as 203.0.113.20 example.com www.example.com to your computer's hosts file, then remove it after the test. Click through key pages, submit a form, check images, and compare your saved crawl against the new server. Make sure robots.txt is the live version, not a staging file with Disallow: /.

If certificates give you trouble, see SSL cannot be issued and SSL not working.

Checking crawling and rankings after the move

Do not assume Google has moved with you; check the new server's own access logs. Googlebot requests appearing there confirm it is reaching the new host:

# Plesk log path; adjust for your server
grep -i "googlebot" /var/www/vhosts/system/example.com/logs/access_ssl_log | tail -20

# Status codes Googlebot received today
grep -i "googlebot" /var/www/vhosts/system/example.com/logs/access_ssl_log \
  | awk '{print $9}' | sort | uniq -c | sort -rn

# Confirm an IP really is Googlebot
host 66.249.66.1

A genuine Googlebot address resolves to a name ending in googlebot.com or google.com. In Search Console, open Settings then Crawl stats, which shows requests per day, average response time and host status, including problems fetching robots.txt and server connectivity. Expect a short dip or wobble in crawl requests, then a return to normal. Watch the Pages report for new errors and the Performance report for clicks over the following two to four weeks. If you see server errors, the 5xx server error guide explains what to look for.

The fix, step by step

Edge cases worth knowing

• Apache to nginx. nginx ignores .htaccess. Every redirect, rewrite and header in those files has to be rewritten as nginx config, or old URLs will start returning 404.
• Email on the old host. If MX records point at the old host, cancelling that account stops email. Move mailboxes first, or point MX at your email provider before cancelling.
• Hard-coded IP addresses. Firewalls, payment callbacks, API allow-lists and CDN origin settings sometimes name the old IP. Update them before cut-over.
• HSTS. If the old server sent HSTS, browsers will refuse plain HTTP and certificate errors on the new server. Have SSL ready first; see HSTS on an HTTPS server.
• Slower response times. A cheaper server that answers in 1.5 seconds instead of 300 ms can slow crawling and Core Web Vitals. Compare time to first byte before and after; see fixing high TTFB.

Keeping the move safe afterwards

Keep the old server for at least a week after its logs go quiet, with a final backup taken before you cancel. Put the TTL back to a normal value, such as 3600 seconds, once you are happy. Set up backups, certificate renewal and uptime monitoring on the new server on day one, not later. Run a full crawl again after a week and compare status codes with your baseline, and keep an eye on Crawl stats for a month. A migration audit is a quick way to confirm nothing changed that should not have.