How to Migrate Web Hosts Without Losing SEO (Checklist)

The direct answer: migrating hosts does not inherently risk SEO — your URLs, content and links are untouched — but migrating carelessly does, and the failure modes are boringly consistent: server rules that did not travel, redirects that silently vanished, staging environments left crawlable, DNS cutovers that strand users on a dead origin, and performance regressions nobody benchmarked. The checklist below is the process we run for client migrations. It is unglamorous by design; migrations reward paranoia and punish improvisation.

Step 1: Benchmark everything before touching anything

The baseline dataset is the entire diagnostic apparatus for whatever happens after cutover. Capture: current rankings for your tracked keyword set; the full indexed-URL inventory (Search Console export plus a complete crawl); Core Web Vitals field data and lab TTFB from your key markets; crawl-stats trends; and — critically — a dump of every server-level rule that lives in configuration rather than application: redirects, headers, caching directives, security rules, rewrite logic.

That last item is where migrations die. Redirect rules accumulated over years in server config are invisible in a content export; move the site without them and hundreds of legacy URLs 404 simultaneously — a link-equity hemorrhage that looks, in Search Console, like an inexplicable rankings slide three weeks later. Inventory them explicitly, and decide where each will live on the new host before anything moves.

Timestamp the baseline and store it outside both hosting environments. If rankings wobble in week two, this dataset is the difference between a targeted fix (“these 40 URLs lost their redirects”) and a month of speculative thrashing.

Steps 2–3: Stage with parity, then pre-stage the DNS

Replicate the full site on the new host under a staging hostname, blocked from indexing via authentication (safer than robots directives, which have leaked staging sites into the index countless times). Then verify parity systematically: crawl the staging copy and diff it against the production crawl — URL set, status codes, redirect chains, canonical tags, response headers, SSL configuration, rendered output on JavaScript-dependent templates. Every difference is a defect to resolve before cutover, not after.

Performance-test staging honestly: same pages, same test locations, lab TTFB against production. The migration is presumably meant to improve infrastructure — verify it does, because discovering a performance regression post-cutover means you migrated twice. If the move changes server geography, re-check the market-latency math from our analysis of whether server location still matters before committing.

In parallel, drop the DNS TTL on the relevant records to 300 seconds at least 48 hours ahead. Long TTLs are the silent cutover killer: with a day-long TTL, some visitors and crawlers hit the old server for 24+ hours after the switch — an eternity if anything needs rolling back. The five-minute TTL converts cutover from a propagation gamble into a reversible switch.

Step 4: The cutover window

Cut over in your lowest-traffic window with the old server left running and untouched — it is your instant rollback for as long as it stays warm. Switch DNS, then immediately verify the critical path on the new origin: SSL validity across all hostnames, the redirect inventory (spot-check the legacy URLs from the baseline), form submissions and transactional flows end to end, and the absence of any staging artifacts — noindex headers, robots blocks, authentication walls — that must not travel to production.

That last check deserves its own alarm: the single most catastrophic migration error in the wild is shipping the staging crawl-block to production. A site-wide noindex or robots disallow on the live domain starts deindexing within days, and recovery takes far longer than the mistake did. Make “confirm production is crawlable” a named checklist line with a named owner, verified in the first hour.

Email and ancillary services ride along more often than teams remember: MX records, transactional-mail configuration, cron jobs and webhook endpoints all live partly in the old environment, and a migration that silently breaks order-confirmation email damages the business faster than any ranking wobble. Inventory the ancillaries with the server rules.

Keep monitoring dashboards open through the window: real-time analytics for traffic continuity, server logs on the new origin for error rates, uptime checks from multiple regions. The first two hours tell you whether the cutover held; the next two weeks tell you whether the migration succeeded.

Step 5: The two-week crawl watch

Post-cutover, Google re-learns your infrastructure, and the monitoring window is where subtle failures surface. Daily for two weeks: Search Console crawl stats (response-time shifts and any 5xx spikes — Google throttles crawl on servers that error under its requests), index coverage deltas against the baseline inventory, server-log review for crawler behavior and 404 patterns, and field-data trends as real-user measurements accumulate on the new origin.

Interpret with the baseline, not with anxiety. Crawl-rate fluctuation for a few days is normal re-learning; a sustained 5xx pattern is a capacity or configuration defect demanding immediate fix; a cluster of 404s mapping to the legacy-redirect inventory means rules did not travel — restore them within the window and the equity loss rounds to zero. The old host stays alive and warm until the fourteen-day data is clean; decommissioning it early to save a month's hosting fee is the falsest economy in this entire process.

If the migration accompanied a hosting upgrade, this window is also where the case for it lands: TTFB and field-data improvements should be visible in the same dashboards — the measurable payoff we quantified in how hosting affects SEO, now on your own timeline.

Step 6: Day-30 sign-off — and the variants that add risk

Close the job formally: at day 14 and day 30, re-run the baseline captures — rankings, index coverage, crawl stats, Core Web Vitals — and diff against the before dataset. Clean diffs (or improvements) sign the migration off; residual deltas get triaged with the baseline as the map. Only then decommission the old environment, and archive both datasets with the migration log — the next migration inherits the playbook.

Know when your migration is not the simple case. Same-host-same-URLs is the low-risk baseline this checklist covers; add-ons multiply risk multiplicatively: domain changes and URL restructures introduce redirect mapping at equity-critical scale; CMS replatforms introduce template and rendering drift; consolidations introduce content parity questions. Each variant deserves its own workstream on top of this process, staffed accordingly — the “while we're at it” migration that bundles three changes into one weekend is how sites lose a year of organic growth in a fortnight.

And schedule with the calendar in mind: never migrate during your peak season, never on a Friday, and never in the same week as a major content launch — clean attribution needs one variable at a time, which is the whole spirit of the process.

The one-page version to pin above the desk

Before: capture the baseline (rankings, URL inventory, vitals, crawl stats, server rules); stage with verified parity; lower DNS TTL 48 hours out. During: cut over in a quiet window, old server running; verify SSL, redirects, forms, and above all that production is crawlable, in the first hour. After: daily crawl-and-log watch for fourteen days with the old host warm; day-14 and day-30 diffs against baseline; decommission only on clean data; archive everything.

Every line exists because its absence has cost some site real rankings. The process is deliberately boring — migrations are one of the few SEO activities where the perfect outcome is that nothing visible happens at all: users notice nothing, Google notices only that the site got faster, and the rankings graph draws a straight line through the cutover date.

If you are choosing the destination host as part of the move, do that homework with the same data discipline — our testing methodology in the hosting guides covers what actually predicts SEO-relevant performance — and then run this checklist to arrive there with everything you had.

Frequently asked questions