Hosting migration without losing SEO

The website migrations guide in this section covers domain changes, HTTP-to-HTTPS switches, or URL structure changes. This is a different, and more common than it sounds, case: the domain doesn't change at all, the URLs are exactly the same, but the server answering them does change, because the site is moving to a different hosting provider or a different IP within the same provider. Since no URL changes, there's no mapping or redirects needed, but the technical risk is real and different: during the transition window, two distinct servers momentarily exist, both answering for the same domain depending on who each visitor or crawler happens to ask.

Preparation: lowering the DNS TTL in advance

The DNS record that points the domain to a specific IP (usually an A record, or CNAME if using an alias) carries a TTL (Time To Live) value that tells DNS resolvers worldwide how long they can cache that answer before checking again. A typical TTL on an already-stable domain might be several hours or even 24 hours, a reasonable value when no change is expected, but a serious obstacle on migration day: if the IP is changed while a high TTL is still active, part of the traffic (and of the crawlers) will keep reaching the old server for that entire duration, with no way to control it.

; Before migrating (several days ahead, never the same day):
; lower the TTL to a short value so you can react quickly
www.yourdomain.com.  300  IN  A  203.0.113.10   ; TTL = 300s = 5 minutes

; After confirming the migration is stable,
; raise the TTL back to a normal value (e.g. 3600s or more)

The low TTL needs to go live several days ahead of the actual switch, not the same day: the previous high TTL is still in effect for resolvers that already cached the answer, until it expires on its own, so lowering it at the last minute speeds nothing up for anyone who already has the old answer cached. Only once enough time has passed for the short TTL to be propagated to the vast majority of resolvers worldwide does it make sense to go ahead with the IP change.

Keeping both servers in sync during the transition window

While DNS hasn't finished propagating to every resolver, the same domain can resolve to different IPs depending on the visitor's or crawler's geographic location, and on when that specific resolver last refreshed its cache. This means that during that window (which can range from minutes to a couple of days depending on the prior TTL and the real behavior of certain resolvers that ignore the declared TTL), both servers, old and new, must serve exactly the same content. That means syncing not just files and code, but any data that changes during the window: if the site has a mini-CMS, a shopping cart or any content edited in production, an edit made on the new server while part of the traffic still reaches the old one (or vice versa) can be lost or create a visible inconsistency depending on which server answers each visit.

Cutover day: verify propagation, don't assume it

Before considering the migration complete, you need to verify actual DNS propagation, not assume "enough time has passed by now." Distributed DNS lookup tools (which query resolvers in different regions of the world simultaneously) show at a glance whether some specific resolver is still returning the old IP, something a local query from your own machine can't catch because your local resolver probably already has the new answer.

# Query the authoritative DNS server directly,
# bypassing any intermediate resolver that might have a cache
dig www.yourdomain.com @ns1.yourdnsprovider.com +short

# Check the remaining TTL of the answer a specific
# public resolver sees right now
dig www.yourdomain.com @8.8.8.8

Active monitoring during the transition window

Throughout the cutover it's worth having active monitoring of two things at once: the availability and response code of both servers (to immediately catch if one of them starts failing while it's still receiving part of the traffic), and, if you have access to server logs on both, the volume of requests from Googlebot and other crawlers on each, which lets you confirm in real time how crawling is splitting between the two IPs as DNS propagates, instead of discovering it days later while reviewing Search Console.

What to check immediately after cutover

Once propagation has been confirmed to be practically complete, there's a specific checklist to run against the new server, not something to assume upfront: that the main pages' HTTP response codes are still 200 (a new-server config error, like a rewrite rule that didn't get migrated, can turn whole sections into 404s or 500s without a single URL changing); that the new server's TTFB is equal to or better than the old one's, not worse (a poorly sized hosting migration can hurt performance, with the resulting Core Web Vitals impact); and, with particular attention, that no mixed content from hardcoded old-server URLs has appeared in the code or database (an absolute URL pointing to the previous server's IP or internal hostname, for example in a CDN or image-upload config, still pointing at a server that should no longer be used).

Rollback planning: decide the criteria before you need them

A rollback plan only works if it's decided before the migration, not mid-incident under time pressure. That means fixing in advance: how long the old server stays fully operational and in sync after cutover (never shutting it down or reusing its IP immediately); what specific threshold of errors or performance degradation triggers the decision to revert (a percentage of 5xx errors, a TTFB above a certain value); and that reverting is technically as simple as switching the DNS record back to the old IP, which is only fast if the TTL is still low at that point, another reason not to raise it back to a high value until you're certain the migration was stable.

Frequently asked questions