Keeping your rankings while you change host

Changing host is one of the few maintenance jobs that can genuinely dent your search visibility, yet done properly it should be invisible to Google and to your visitors. The good news is that a move which keeps your URLs identical is not a "site move" in the way search engines treat a domain change or an HTTPS switch. If the same pages return the same content at the same addresses, the crawler barely notices which machine served the bytes. Ranking loss during a host change is almost always self-inflicted: a broken redirect, a lapsed certificate, a DNS record pointing at nothing, or content that quietly changed in transit. This guide walks through how to move without giving any of that away.

Why a host change usually does not move rankings

Google indexes URLs, not servers. The IP address behind a domain is not a positive ranking signal, and swapping it does not reset your authority, your backlinks, or your history. What matters is that every ranked URL keeps responding with the same status code, the same canonical, and substantially the same content before, during, and after the cutover. Where the IP does matter is defensive: you want to land on a clean address with a good neighbourhood reputation rather than a recycled IP carrying spam history. For operators running several sites, footprint control is the other reason to care which network you sit on, which is exactly what a dedicated Class C IP is for. Neither of those is a ranking boost; both are ways to avoid an avoidable problem.

Before you touch anything: freeze and inventory

Rankings survive migrations that are boring and reversible. Build a snapshot of the current site so you can prove, afterwards, that nothing changed by accident:

• Export a full list of indexed URLs from Search Console and your XML sitemap, plus the top pages by organic traffic.
• Record the exact response for a sample of important URLs: HTTP status, canonical tag, robots meta, and any redirects in the chain.
• Note your current DNS records (A, AAAA, CNAME, MX, TXT for SPF and DKIM) and the current TTL values.
• Copy every server-side rule that affects SEO: .htaccess or nginx redirects, HTTPS enforcement, hotlink rules, and canonical host rewrites (www vs non-www).
• Take a database and file backup you can restore from, independent of both hosts.

If anything in this list is a mystery today, resolve it before the move, not during it. A migration is the worst time to discover an undocumented redirect rule.

Migrate in parallel, never in place

The safest pattern is to stand the site up completely on the new server while the old one keeps serving live traffic, then switch only once the copy is verified. Point a temporary hostname or a local hosts-file entry at the new IP and test the real site there: load key pages, submit a form, check that HTTPS resolves, and compare the rendered HTML against the old server. You are looking for parity, not just "it loads". Confirm the same canonical tags, the same meta robots directives, the same structured data, and the same redirect behaviour. Only when the new copy is indistinguishable from the old one should you plan the DNS switch.

Getting DNS and TTL right

The actual cutover is a DNS change, and its smoothness depends on TTL, the time resolvers cache your records. Lower the TTL on the records you are about to change (typically the A record) a day or two ahead, so the world stops caching the old IP for hours at a time. Make the change, and because some resolvers ignore TTL, keep the old server online and serving the identical site for at least 48 to 72 hours afterwards. During that window visitors may hit either machine; as long as both return the same pages, there is no split-brain and no ranking risk.

Keep HTTPS unbroken

A certificate that fails to install on the new server, or expires because nobody renewed it, will throw browser warnings and can interrupt crawling. Issue and install the certificate on the new host before the DNS switch, so the site is already valid on the new IP the moment traffic arrives. With free automated certificates this is usually painless, but a domain-validated certificate needs the DNS or HTTP challenge to succeed, which sometimes only works after the domain resolves to the new server. Plan for that ordering, and if you use custom certificates keep the private key and chain to hand. If you need certificates provisioned as part of the move, our SSL options cover the common cases, and matching your previous cipher and protocol settings avoids surprising older clients.

Preserve the rules that hold your rankings together

The single most common cause of a post-migration drop is a redirect or canonical rule that did not travel with the files. Copy them deliberately:

• HTTP to HTTPS enforcement, so secure URLs stay the canonical version.
• www versus non-www consolidation, matching whatever Google currently indexes.
• Any legacy 301s from old URLs to current ones, so link equity keeps flowing.
• Trailing-slash handling and case rules that were in place before.
• robots.txt and your XML sitemap, byte-for-byte, unless you are deliberately changing them.

A staging server often ships with a blanket "Disallow: /" in robots.txt or a site-wide noindex. If either of those follows the files onto production, you can deindex the whole site in days. Check both explicitly after cutover.

Special care for multi-site and network operators

If you run a network, moving one site is straightforward; moving many at once concentrates risk. Two footprint issues deserve attention. First, do not stack sites that are meant to look independent onto the same new IP or the same nameservers just because it is convenient during the move. Keeping each property on its own dedicated address is the whole point of IP diversity, and a rushed migration is a classic way to accidentally collapse that separation. Second, verify the reputation of any IP before you rely on it, because addresses get recycled. ASEOHosting assigns clean, dedicated addresses precisely so that a move does not drop you into a bad neighbourhood; if you are planning a batch migration, start from the Migrating to ASEOHosting hub, which covers phased cutovers for networks. Remember that a dedicated IP is not itself a ranking factor; its role here is to keep your sites separated and out of trouble, not to lift them.

After the switch: watch, do not fiddle

Once DNS has propagated, resist the urge to change anything else for a week or two, so you can attribute any movement to the move alone. Monitor deliberately:

1. Re-run your URL sample and confirm identical status codes, canonicals, and content on the new IP.
2. Check Search Console for crawl errors, coverage changes, and a spike in 404s or 5xx responses.
3. Watch server logs to confirm Googlebot is reaching the new machine and getting 200s.
4. Keep an eye on Core Web Vitals, since a new server can change response times in either direction.
5. Only decommission the old host once logs show all crawler and visitor traffic has fully shifted.

Small ranking wobbles in the first days are normal as caches expire and the new server warms up; a sustained slide is a signal something did not transfer correctly. If traffic drops and does not recover, Google's own guidance on moving a site is the right first reference for isolating the cause. Handled with a parallel build, a lowered TTL, an overlapping cutover window, and faithful redirect and robots rules, a host change should cost you nothing in the rankings, which is exactly how a migration ought to feel.