Choose an infrastructure move, URL move, or both

Generate a website migration checklist

Build a printable migration checklist for DNS, URL mapping, redirects, rollback, and a per-URL evidence log for status, media, forms, login, email, and redirects.

Choose what changes to generate a focused checklist. A hosting or DNS move can keep every visitor-facing URL unchanged; a search migration changes URL, host, protocol, or paths and needs a URL map and redirect checks. If both change, use the combined checklist.

What is changing?

0 checklist items checked.

Shared preparation and cutover checks

Name an owner, cutover window, decision-maker, and contact path for the current host, destination host, DNS provider, registrar, and mail provider as applicable.
Record the current DNS zone and key settings before editing: A/AAAA/CNAME, MX, TXT, nameservers, TTLs, proxy/CDN settings, and any service-specific records that apply.
Inventory files, database(s), uploads, forms, scheduled jobs, redirects, TLS certificates, mailboxes, and third-party integrations that the destination must support.
Make and verify a restorable backup of the source files and database. Confirm how writes made after the copy will be handled at cutover.
Build the destination copy and test pages, images, downloads, forms, login, checkout or other critical flows, and mobile layout on a protected staging URL.
Check TLS certificate coverage and expiry for the destination hostname, and confirm the destination serves the intended hostname over HTTPS.
Confirm Search Console verification, analytics/logging, firewall rules, access controls, and any temporary staging noindex or crawl blocks have a documented production plan.
Set a go/no-go time and named rollback owner. Write down the exact trigger, DNS or routing values to restore, and who can authorize the change.

Infrastructure move: same visible URLs

Compare representative old and new responses while DNS still points to the old destination. Verify the new origin directly using your provider's safe test method.
If changing DNS TTL, choose a value with your DNS provider and apply it ahead of the move; record the original value so it can be restored later.
Confirm the destination is ready to receive production requests, including capacity, HTTPS, application configuration, and any required mail or external service settings.
At cutover, update only the DNS records required to point the unchanged hostnames to the new infrastructure. Keep the old service available during transition.
Monitor old and new server logs, representative DNS answers, HTTP responses, forms, and Search Console crawl/indexing reports. Retire the old service only after traffic and dependencies are accounted for.

Rollback plan to fill in before cutover

Trigger: Define measurable stop conditions, such as a critical user journey failing, widespread server errors, or data integrity problems. Set a time limit for deciding.
Routing: Record who can restore the prior DNS/routing values, where the saved zone is, and which caches or proxies may delay the reversal.
Application and data: Decide how to handle writes received by the destination after launch before switching traffic back. Do not overwrite newer data with an older backup.
URL changes: Preserve the old-to-new map and know how to disable or correct bad redirect rules. If the old URLs still serve the original content, coordinate routing and redirects so users do not land on stale or duplicate versions.
Communications: Keep provider support contacts and an update message ready. Record the final decision and the time each rollback action is completed.

A DNS reversal is not instant everywhere because recursive resolvers and clients may cache answers. Rollback safety depends on the application, write activity, DNS setup, and provider behavior; adapt this plan to the actual architecture.

Acceptance commands

Run from a terminal you control after replacing the example hostnames and paths. These requests show what that network observes; one sample cannot verify every URL or location.

Check DNS answers

dig +short A www.example.com
dig +short AAAA www.example.com

Check a page response and final URL

curl -sS -L --max-redirs 10 -o /dev/null \
  -w 'status=%{http_code} final=%{url_effective} redirects=%{num_redirects}\n' \
  'https://www.example.com/important-page'

Check an old URL during a URL migration

curl -sS -L --max-redirs 10 -o /dev/null \
  -w 'status=%{http_code} final=%{url_effective} redirects=%{num_redirects}\n' \
  'https://old.example.com/old-path'

For a changed URL, confirm that the final URL is the mapped destination and returns the expected successful status. For an infrastructure-only move, the visitor-facing URL should remain the same. Review TLS errors, response content, and the full URL list separately. See the HTTP status and redirect guide for header and chain inspection. To format a reviewed map as Apache or Nginx rules, use the local 301 redirect rule generator, then test the result in the right server configuration context. Compare old and new sitemap entries with the sitemap URL-set diff worksheet, and check recorded redirect destinations against new-page canonicals with the canonical and redirect consistency checker; both check only the values you provide.

Per-URL validation evidence before cutover

Record checks you performed against the destination before changing production DNS. Enter one URL per row and note what you observed for HTTP status, media, forms, login, email, and redirects. This worksheet stays in this browser tab; print or save it before closing if you need a record. It does not request URLs or verify results.

0 URL rows.

URL tested	HTTP status	Media	Forms	Login	Email	Redirect destination	Observed evidence / issue	Action

Sources checked November 3, 2026

Google Search Central: changing hosting without URL changes — prepare and test the new infrastructure, update DNS, monitor both servers, then retire the old host when traffic has moved.
Google Search Central: site moves with URL changes — prepare and test the new site, map old to new URLs, use redirects, update sitemaps, and monitor Search Console. The guide says Change of Address applies to domain or subdomain moves and recommends keeping redirects for at least one year where possible.
RFC 9110: HTTP Semantics — HTTP status and redirection semantics.

This checklist does not inspect your site, change DNS, create redirects, back up data, or guarantee search traffic or zero downtime. Follow the instructions for your CMS, DNS provider, host, mail services, and application.

How it works

Choose whether you are changing infrastructure, visible URLs, or both. Check off the applicable preparation, cutover, rollback, and acceptance items. Add a row for each destination URL you manually check, record status and critical-function evidence, then print or save the checklist and evidence log.

Good to know

Does changing hosts always require redirects or a Search Console Change of Address?

No. If visible URLs remain the same, Google documents a separate hosting-change process centered on preparing and testing the new host, changing DNS, monitoring both servers, and shutting down the old host after traffic moves. Redirect mapping is for moves that change URLs. Google's Change of Address tool applies to domain or subdomain moves, not path-only or HTTP-to-HTTPS changes.

Does the checklist perform the migration or inspect my website?

No. It runs locally in your browser, shows checklist sections, lets you enter and remove evidence rows, counts checked items, and opens the print dialog. It does not request URLs or verify results. Run the example commands yourself after replacing the sample hostnames and paths.

Can I safely roll back by restoring the old DNS records?

Not in every architecture. DNS caching can delay a reversal, and application writes made after launch may need reconciliation. Define your rollback trigger, routing steps, and data plan with the people responsible for the site before cutover.

Impact — TODO: apply/approval and configure referral URL — referral link not configured.

CJ Affiliate — TODO: apply/approval and configure referral URL — referral link not configured.

PartnerStack — TODO: apply/approval and configure referral URL — referral link not configured.