Website Hosting Migration SEO

TL;DR — A hosting migration moves the machinery behind your website while visitors keep using the same URLs. Build and test the new host first, lower the DNS time to live (TTL) before launch, keep the old host running during the switch, and compare what both systems return. Watch DNS, certificates, status codes, content, speed, and crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. access. Shut down the old host only after its logs show that traffic has reached zero.

What is a hosting migration?

A hosting migration changes where or how a website is served without changing the URLs people see. Moving to a different hosting company is one example. Adding or replacing a content delivery network (CDN), changing an origin server, or switching DNS providers can be part of the same project.

The URL staying the same is the defining condition. https://example.com/page/ must remain https://example.com/page/ before and after the move.

Google treats this as a site move without URL changes. If the domain, protocol, hostname, or path changes, use the full site migrationsA site migration is any significant change to a website's URL structure, domain, platform, protocol, or hosting that can affect how search engines crawl, index, and rank it. The risk scales with how much you change at once. process instead. You may be doing two migrations at once.

Why can a same-URL move affect SEO?

A hosting migration can change everything behind a stable address. Search engines may encounter a different response code, slower server, expired certificate, firewall challenge, stale cached page, broken image, missing header, or rendered page.

The safest move preserves the observable response while replacing the infrastructure. Users and crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. should get the same successful page from the new system that they received from the old one.

What are the basic steps?

1. Copy or connect the site to the new infrastructure.
2. Test the new origin and CDN without changing public DNS.
3. Lower DNS TTL in advance so the eventual change propagates faster.
4. Confirm certificates, cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., security rules, and crawler access.
5. Change DNS to send traffic to the new infrastructure.
6. Keep both environments online while DNS caches expire.
7. Monitor logs, errors, speed, crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor., and search performance.
8. Shut down the old host only when its logs show no remaining traffic.

Google recommends this same prepare, switch, monitor, and shut-down sequence in its hosting-change documentation.

What does DNS TTL do?

DNS TTL controls how long a resolver may cache a DNS answer. A lower TTL before the move lets changed records expire from caches sooner. It does not make every resolver switch instantly, and lowering it at launch is too late for caches holding the old value.

Google suggests lowering TTL to a conservative low value, such as a few hours, at least one week before the move. Treat that as an example, not a universal number; your DNS provider and operational requirements decide the exact value.

Do you need redirects?

A true hosting migration needs no SEO redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. because the public URLs do not change. Adding blanket redirects during a host-only move creates new failure modes without solving the infrastructure problem.

Existing redirects still need to behave exactly as they did before. Test them on the new stack, including old legacy rules that may live in the current web server, CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms., load balancer, or CDN.

When is the move complete?

The hosting move is complete when the new infrastructure serves the intended responses consistently and the old infrastructure no longer receives real user or crawler traffic. Google explicitly recommends checking the old provider’s logs and shutting it down only after traffic reaches zero.

TL;DR — Treat a same-URL hosting, CDN, or DNS migration as a response-parity and traffic-routing project. Inventory every hostname and dependency, lower DNS TTL before launch, configure the new origin and edge, validate certificates and security controls, load-test realistic crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. and user demand, and compare raw plus rendered responses. Dual-run old and new infrastructure through DNS propagation. Monitor both log streams, DNS answers, errors, latency, cache behavior, crawl activity, and Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.. Roll back by restoring the previous routing only when a pre-agreed infrastructure failure occurs.

Decide whether this is really a same-URL migration

A same-URL hosting migration changes infrastructure without changing the exact public URL string. The scheme, hostname, port, path, query handling, and trailing slash behavior remain stable.

Classify the project before planning it:

Do not let a project manager label a URL change as “just hosting.” The deployment plan must include every migration type that actually ships.

Build the infrastructure inventory

Infrastructure inventory prevents the quiet dependencies from becoming launch-day surprises. Record:

• all public hostnames, including assets, images, APIs, international hosts, and legacy aliases;
• A, AAAA, CNAME, NS, SOA, CAA, MX, TXT, and relevant SRV records;
• certificate issuers, validation methods, Subject Alternative Names, and expiry;
• origin addresses, ports, health checks, load balancers, and failover behavior;
• CDN cache keys, cache rules, redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., transforms, workers, and purge methods;
• WAF, bot, rate-limit, geoGenerative Engine Optimization (GEO) is the practice of optimizing content and brand presence so AI-powered search engines and assistants — Google AI Overviews, ChatGPT, Perplexity — cite, recommend, or mention you when generating answers. Google's position is that it's still SEO., authentication, and IP allow/deny rules;
• response headers, compressionCompression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they're sent over the network, using an algorithm like Gzip, Brotli, or Zstd, so the browser or crawler downloads fewer bytes. It's not a ranking factor, but it speeds up page loads and helps pages stay under crawler fetch limits., cookie behavior, and security headers;
• log destinations, retention, sampling, fields, and time zones;
• Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. and analytics verification methods;
• third-party callbacks, webhooks, payment flows, feeds, and allowlisted IPs.

DNS review must include non-web records. Breaking MX, SPF, DKIM, DMARC, or service records may not directly change rankings, but it can break the business you were trying to protect.

Establish a response-parity baseline

Response parity means comparing the old and new systems for the same requested URL, not merely checking that both return 200.

Capture a representative set across templates and behaviors:

• status and redirect chainA → B → C instead of A → C. Each hop loses link equity and adds latency.;
• final URL and protocol negotiation;
• title, canonical, robots directives, hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others., and structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding.;
• raw HTML and browser-rendered main content;
• Content-Type, Cache-Control, Vary, compressionCompression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they're sent over the network, using an algorithm like Gzip, Brotli, or Zstd, so the browser or crawler downloads fewer bytes. It's not a ranking factor, but it speeds up page loads and helps pages stay under crawler fetch limits., and security headers;
• images, fonts, JavaScript, CSS, PDFs, and media assets;
• cookies and logged-in or personalized variants;
• mobile and desktop behavior;
• latency, time to first byte, and error rate.

Use the Staging vs. Production SEO Diff for paired page checks. A full crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. and scripted request suite should cover the larger inventory.

Prepare the new origin

Origin preparation starts with content and configuration parity. Copy current content, templates, media, robots rules, redirects, error handling, and verification files. Freeze or synchronize writes so the new database does not launch stale.

Test the origin directly through a controlled hostname, a local hosts-file override, or provider-specific preview mechanism. The test must preserve the production Host header because virtual hosts, application routing, certificates, canonicals, and absolute links often depend on it.

The new origin must also handle the post-cutover load. Warm the application and database, confirm connection pools and autoscaling, and load-test uncached demand. CDN cache misses can concentrate traffic at the origin immediately after launch.

Configure the CDN as a separate system

CDN migration changes more than geography. Compare the old and new edge behavior explicitly:

• cache key composition, including query strings, cookies, headers, and device variants;
• cacheable status codes and file types;
• browser TTL, edge TTL, stale serving, revalidation, and origin shielding;
• redirects, rewrites, header transforms, and edge functions;
• cache bypass rules for accounts, carts, search, and personalized pages;
• compression and image optimization;
• purge scope and propagation;
• WAF, bot management, rate limiting, and origin protection.

Cloudflare’s current documentation, for example, notes that its default caching may respect origin Cache-Control headers but can be overridden by edge rules. It also provides targeted or full purges to force fresh origin fetches. The exact behavior is vendor-specific, so export and compare configuration rather than assuming equivalent labels mean equivalent results. See Cloudflare’s cache documentation.

Treat cache parity as content parity

Cache configuration can serve the wrong page correctly and quickly. Test anonymous, authenticated, localized, mobile, and query-string variants. A cache key that omits a meaningful cookie or header can leak personalized content. A cache key that includes every tracking parameter can fragment the cache and overload the origin.

Purge or pre-warm critical assets and pages according to the launch plan. Do not blindly purge everything during peak traffic unless the origin has been tested for the resulting miss storm.

Validate TLS from user to edge and edge to origin

TLS validation has two legs when a CDN terminates HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.': browser to CDN and CDN to origin. Confirm hostname coverage, complete certificate chains, modern protocol support, renewal, and strict origin validation.

Origin-only certificates may not be publicly trusted. Cloudflare warns that its Origin CA certificates can produce browser trust errors if proxying is disabled or paused. That matters during rollback: a DNS-only fallback to an origin using an edge-only trust model may fail for users. See Cloudflare Origin CA guidance.

Test every public hostname, including wildcard assumptions and rarely used asset or regional hosts. A valid apex certificate does not prove every subdomain is covered.

Lower DNS TTL before the move

TTL planning starts before cutover. Google recommends lowering the relevant TTL to a conservative low value, such as a few hours, at least one week before the move. A DNS provider may impose different minimums; proxied records may also have fixed values.

Cloudflare’s TTL documentation explains the basic tradeoff: longer values increase cache reuse, while shorter values allow record changes to take effect sooner. Record the original TTL and schedule its restoration only after the new infrastructure is stable.

DNS changes can be non-atomic across distributed systems. Change as little as possible during the cutover, verify answers from several public resolvers, and keep the old destination available while cached answers remain valid.

Verify crawler access and security controls

Security parity is not rule-count parity. A WAF copied from another provider can challenge or block crawlers, strip query parameters, rewrite responses, or rate-limit high-volume crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. differently.

Google’s hosting guide says to ensure firewalls and denial-of-service protection do not block GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. from DNS or hosting servers. Verify Googlebot using Google’s documented verification methods, not a user-agent string alone.

Test both ordinary crawler behavior and legitimate bursts. Avoid broad allowlisting that disables protection for spoofed user agentsA user agent is the HTTP request header a client (browser, crawler, or bot) sends to identify itself. For crawlers, a short user-agent token — a substring of that string — is what robots.txt rules actually target.. Preserve security logs so blocked requests can be distinguished from origin failures.

Plan the dual run

Dual running means both old and new infrastructure can serve correct production responses during propagation. The old environment must keep receiving content or data changes that affect the site. Otherwise users routed by cached DNS answers may see stale inventories, broken sessions, or outdated pages.

Pick a synchronization strategy:

• one read/write database shared by both stacks;
• replicated data with an understood lag and conflict policy;
• a controlled content freeze during cutover;
• one-way event replication for orders, forms, or user writes.

Session state, uploads, cache invalidations, and background jobs need the same decision. “Both servers are on” is not a dual-run plan if their state diverges.

Execute the cutover

Hosting cutover should be deliberately boring:

1. Stop unrelated deployments and confirm the change window.
2. Run the final parity, certificate, capacity, and backup checks.
3. Remove temporary crawl or access blocks from the new production path.
4. Change only the planned DNS or CDN routing records.
5. Confirm expected answers from multiple resolvers.
6. Request protected pages through the public route as a user and crawler.
7. Confirm logs are arriving from edge, new origin, and old origin.
8. Watch errors, latency, cache misses, origin load, and conversions.

Do not use Google’s Change of Address toolA setting in Google Search Console that tells Google you've moved your whole site to a new domain or subdomain. It's a supporting signal for a domain migration — the 301 redirects do the real work of transferring rankings. for a host-only move. No public URL has changed, so there is no address change to report.

Monitor the evidence that proves the move

Infrastructure monitoring should separate old and new traffic. Use a deployment marker and compare the same time-of-week baseline where seasonality matters.

Watch:

• DNS answers and resolver propagation;
• old-host and new-host requests by user and verified crawler;
• edge and origin status-code distribution;
• TLS, connection, timeout, and application errors;
• latency percentiles and uncached origin response time;
• cache hit ratio and origin request volume;
• Googlebot requests, Crawl Stats, Page IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and representative URL Inspection;
• synthetic checks across regions and networks;
• analytics, conversions, and critical business transactions.

Google says a temporary Googlebot crawl-rate drop immediately after a hosting change can be normal, followed by an increase over the next few days. Anchor any decision to accessibility and error evidence, not that expected pattern alone.

Define rollback before launch

Rollback returns routing to a known-good infrastructure state. It is not a vague promise to “switch DNS back.” Document:

• the exact records, routes, and configurations to restore;
• who can authorize and execute the reversal;
• how changed content, sessions, forms, orders, and uploads will reconcile;
• whether the old certificates and dependencies remain valid;
• cache purge steps on both routes;
• the failure thresholds that trigger rollback;
• the maximum safe decision time.

Rollback triggers should be observable: sustained availability failures, material conversion breakage, widespread wrong content, certificate failures, crawler blocks, or capacity collapse that cannot be corrected within the window. A temporary crawl rate fluctuation by itself is not a rollback trigger.

Retire the old infrastructure from logs, not a calendar

Old-host retirement happens after logs show that users and crawlers no longer reach it and all dependent services have moved. Google recommends shutting down the old host after its traffic reaches zero.

Retain configuration exports, logs, and rollback artifactsClaude's feature for generating and publishing interactive mini-apps from chat. according to business requirements. Restore DNS TTL to the intended steady-state value after stability is proven. Remove temporary firewall exceptions and duplicate scheduled jobs so the migration does not leave a permanent maintenance mess.

AI summary

• A hosting migration changes servers, CDN, origin, or DNS while public URLs remain identical.
• URL changes require the broader site-move process. A true host-only move needs no new redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. map or Change of AddressA setting in Google Search Console that tells Google you've moved your whole site to a new domain or subdomain. It's a supporting signal for a domain migration — the 301 redirects do the real work of transferring rankings. submission.
• Inventory DNS, TLS, origin, CDN, WAF, cache, logs, verification, assets, and business dependencies before launch.
• Lower DNS TTL ahead of the cutover, retain the old value, and restore it after the new path is stable.
• Compare old and new raw responses, rendered pages, headers, assets, redirects, status codes, latency, and business behavior.
• Validate browser-to-edge and edge-to-origin TLS, plus certificates on any rollback path.
• Dual-run the environments and synchronize writes until cached DNS answers no longer send traffic to the old stack.
• Monitor both log streams, DNS answers, errors, origin load, cache behavior, verified crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. access, Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results., and conversions.
• Retire the old host only when its logs show traffic has reached zero.

Official documentation

Google

• Changing your web hosting and SEO explains the same-URL prepare, DNS switch, monitor, and shut-down process.
• Site moves with URL changes applies when scheme, hostname, or path changes too.
• Verify Googlebot documents reverse/forward DNS and published-IP verification.
• Crawl Stats report helps monitor GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. requests and host availability.

Infrastructure references

• Cloudflare DNS TTL explains TTL and propagation tradeoffs.
• Cloudflare cache documents edge cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency., cache rules, and purging.
• Cloudflare Origin CA documents edge-to-origin certificates and the browser-trust limitation.

Quotes from the source

• “This guide is only for migrations that don’t affect the user-visible URL.” Google Search Central. Jump to the hosting guide
• Paraphrase: Google recommends reducing DNS TTL ahead of the move, ensuring firewalls still admit verified GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. traffic, expecting a temporary crawl-rate dip, and keeping the old host available until its traffic has ended. TTL guidance, firewall guidance, crawl-rate guidance, and shutdown guidance.

Hosting migration checklist

Scope and baseline

• Confirmed no public URL will change.
• Inventoried every web, asset, API, and regional hostname.
• Exported DNS, CDN, WAF, cache, redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., TLS, and origin configurations.
• Saved representative raw and rendered response baselines.
• Recorded traffic, error, latency, crawl, indexation, and conversion baselines.

New infrastructure

• Synced current content, media, redirects, robots rules, and verification files.
• Tested Host-header routing and every public hostname.
• Validated browser-to-edge and edge-to-origin certificates.
• Matched cache keys, bypasses, TTLs, cookies, transforms, and purge behavior.
• Matched WAF, botA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index., rate-limit, and origin-access behavior.
• Load-tested cache misses, application dependencies, and database capacity.
• Confirmed edge, origin, application, and security logs are retained and searchable.

DNS and launch

• Lowered relevant TTLs ahead of the move and recorded original values.
• Preserved non-web records, DNSSEC, verification, and service dependencies.
• Documented the exact routing change and rollback commands.
• Kept old and new infrastructure live with a data synchronization plan.
• Removed every temporary production-path crawl or access block.
• Verified DNS answers through multiple independent resolvers.

After launch

• Compared status, content, headers, renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., assets, and redirects in production.
• Confirmed users and verified crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. are not challenged or blocked.
• Watched old/new logs, errors, latency, cache misses, origin load, and conversions.
• Checked Crawl StatsA Google Search Console report (under Settings) that shows how Google has crawled your site over the last 90 days — total requests, download size, and average response time, broken down by response code, file type, Googlebot type, and purpose. It's only available for root-level properties (a Domain property or a URL-prefix property verified at the site's root)., Page IndexingThe Google Search Console report (formerly Index Coverage) showing how many of your URLs are indexed vs. not indexed, and grouping the not-indexed ones by reason., and representative URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. results.
• Restored steady-state TTL only after stability was proven.
• Retired the old host only after its traffic reached zero.

The five-layer parity framework

The migration state model

Prepared means the new stack passes parity and load tests. Switching means DNS answers and requests are split. Stabilizing means the new stack serves nearly all traffic while the old stack remains available. Complete means old-host traffic reaches zero and all dependencies are retired or transferred.

Do not call the project complete at “DNS changed.” That is the start of the switch, not the end of the migration.

Which migration plan applies?

Common hosting migration failures

Some regions still reach the old host

Likely cause: cached DNS answers, resolver behavior, or records that were not changed consistently. Fix: compare authoritative answers with several public resolvers, keep the old host serving current content, and inspect TTLs rather than forcing repeated changes.

Googlebot requests fall after launch

Likely cause: a normal short-term crawl-rate adjustment, a firewall challenge, DNS failure, latency, or server errors. Fix: check Crawl StatsA Google Search Console report (under Settings) that shows how Google has crawled your site over the last 90 days — total requests, download size, and average response time, broken down by response code, file type, Googlebot type, and purpose. It's only available for root-level properties (a Domain property or a URL-prefix property verified at the site's root). and verified-botA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. access logsLog file analysis is reading a web server's raw access logs to see exactly which URLs search engine crawlers actually requested, when, how often, and what status code they got. Unlike crawl tools or Search Console, logs are the unsampled, ground-truth record of what really happened.. Google’s documented short-term dip is not a reason to ignore real access failures.

Pages are fast but show stale content

Likely cause: an edge TTL, cache key, purge failure, or divergent data source. Fix: inspect Age, Cache-Control, Vary, and provider cache-status headers; test meaningful variants; purge narrowly; then verify the origin and edge separately.

The site works through the CDN but fails when bypassed

Likely cause: origin certificate trust, Host-header routing, firewall allowlists, or a missing direct-origin dependency. Fix: validate the intended edge-to-origin path and the documented rollback path. Do not expose a private origin merely to make an unplanned bypass test pass.

Assets fail while HTML works

Likely cause: omitted asset hostnames, CORS, certificates, absolute URLs, cache rules, hotlink protection, or origin permissions. Fix: crawl and browser-test the asset inventory, including fonts, images, CSS, JavaScript, PDFs, and media.

Origin load spikes immediately

Likely cause: cold caches, a changed cache key, bypassed cache, missing shielding, or bot traffic reaching the origin directly. Fix: restore intended cache rules, warm high-value objects carefully, and add capacity. Roll back if sustained failures cross the agreed threshold.

Tools for a same-URL infrastructure move

• DNS Checker compares common record types through several public resolvers. Use it during propagation, but compare the result with the authoritative zone too.
• HTTP Header Checker shows headers across redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't., including CDN fingerprints, compressionCompression (HTTP content encoding) shrinks text-based responses — HTML, CSS, JS, JSON, SVG, XML sitemaps — before they're sent over the network, using an algorithm like Gzip, Brotli, or Zstd, so the browser or crawler downloads fewer bytes. It's not a ranking factor, but it speeds up page loads and helps pages stay under crawler fetch limits., security, and cache controls.
• Staging vs. Production SEO Diff compares paired URLs across status, canonicals, directives, selected headers, schema, and content.
• Bulk HTTP Status Code Checker checks status, redirects, destination, and latency across a representative URL set.
• Google Index Checker checks observable crawl and indexability blockers, then points you to Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. for Google’s own view.
• Server and edge logs prove where traffic went, what response it received, and when the old infrastructure is genuinely unused.
• Synthetic monitoring tests public availability and critical transactions from several networks and regions.

Prove the hosting migration worked

DNS propagation and old-host drain test

• Test to run: Query authoritative DNS plus several public resolvers, then graph request volume on old and new infrastructure.
• Expected result: Public answers converge on the intended route while old-host traffic declines to zero.
• Failure interpretation: Inconsistent records, cached answers, or untracked hostnames are still routing traffic elsewhere.
• Monitoring window: From cutover through at least the longest prior relevant TTL and until old-host logs remain at zero.
• Rollback trigger: Material regions cannot resolve or reach the new service and the issue cannot be corrected inside the recovery window.

Response-parity test

• Test to run: Compare the baseline with production using the Staging vs. Production SEO Diff, a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index., and rendered browser tests.
• Expected result: Intended status, canonicals, robots rules, content, structured data, internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., assets, and headers are preserved.
• Failure interpretation: The new origin, edge, or application configuration has changed a search-visible response despite stable URLs.
• Monitoring window: Immediately before and after cutover, then after each launch fix.
• Rollback trigger: A site-wide indexability, canonical, content, or asset failure affects protected templates and cannot be hot-fixed safely.

Crawler-access and capacity test

• Test to run: Inspect verified crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. logs, Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. Crawl StatsA Google Search Console report (under Settings) that shows how Google has crawled your site over the last 90 days — total requests, download size, and average response time, broken down by response code, file type, Googlebot type, and purpose. It's only available for root-level properties (a Domain property or a URL-prefix property verified at the site's root)., origin latency, error rates, and uncached load-test results.
• Expected result: Verified crawlers receive successful responses without challenges, while the origin stays inside its established capacity envelope.
• Failure interpretation: WAF, DNS, TLS, rate limiting429 Too Many Requests is an HTTP client-error status code that means a client sent too many requests in a given time window — a mechanism called rate limiting. Unlike other 4xx codes, Google treats 429 as a server-overload signal and slows crawling instead of removing content., or origin capacity is preventing reliable crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor..
• Monitoring window: Continuous through launch and the first several days of crawl-rate stabilization.
• Rollback trigger: Sustained crawler and user failures exceed the approved error or availability threshold.

Cache-safety test

• Test to run: Request anonymous, authenticated, localized, mobile, and query variants while inspecting cache keys and response headers.
• Expected result: Public content is cached as designed; private or personalized responses are not shared; meaningful variants remain distinct.
• Failure interpretation: Cache-key or bypass rules can serve incorrect content or overload the origin.
• Monitoring window: Before launch, immediately after cutover, and after any cache rule or purge change.
• Rollback trigger: Personalized data is exposed, widespread stale content is served, or the origin cannot sustain the miss rate.

Resources worth your time

My related writing

• A Website Migration Takes More Than a Checklist to Be Successful covers the broader migration process, baselines, staging, and monitoring.
• Redirects for SEO explains the legacy redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. behavior that must survive an infrastructure move.

Related guides on this site

• Site MigrationsA site migration is any significant change to a website's URL structure, domain, platform, protocol, or hosting that can affect how search engines crawl, index, and rank it. The risk scales with how much you change at once. covers migration classification and the universal process.
• Website Migration Checklist provides the phase-based project checklist.
• HTTP Status CodesAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index. explains the response layer you should preserve and monitor.

From around the industry

• Google: Changing your hosting
• Google: Verify Googlebot
• Cloudflare: DNS TTL
• Cloudflare: Manage DNS records
• Cloudflare: Cache documentation
• Cloudflare: Origin CA
• Bing: IndexNow

Test yourself: Website Hosting Migration SEO

Five questions on classifying, launching, and validating a same-URL infrastructure move. Pick an answer for each, then check.

Changelog