Website Domain Migration Checklist: Before, During and After Launch

Agree what is changing and who owns it

I begin a migration brief with a short scope: domain only, platform change, redesign, content consolidation or a combination. Each additional change makes it harder to isolate the cause of a problem. Where practical, separate a domain move from a substantial redesign.

Name an owner for redirects, hosting, analytics, content and the launch decision. Agree who can stop the release if key checks fail. A written go/no-go list is more useful than discovering during launch that the developer assumed someone else had access to the old server.

Record the commercial baseline too: important landing pages, enquiries, orders and seasonal context. You need to distinguish a tracking failure from a real loss of customer activity. My analytics work is relevant here because measurement continuity is part of a usable migration.

Build the old-to-new URL map

Collect addresses from a crawl, sitemaps, Search Console, analytics and known external links. Include downloadable files and images where they matter. Do not rely only on the new navigation: it tells you what you intend to keep, not everything that existed before.

Add columns for priority, owner and test result. Put the most important sales and service URLs at the top of the test queue, but validate the whole mapping mechanically where possible. A rule that works for the homepage may still break encoded paths or trailing slashes.

Google’s site-move guidance supports relevant permanent redirects and warns against sending unrelated old pages to the homepage. That shortcut can also leave a visitor unable to find what they came for.

Test the new site while it is still private

• Check the new page inventory against the approved map.
• Confirm titles, important copy, images and downloads survived the move.
• Inspect canonical URLs, internal links, structured data and language references for the old domain.
• Test forms, checkout, payments, account access and transactional email with the relevant owners.
• Confirm analytics works without duplicate events and preserves the required consent behaviour.
• Document exactly which staging protections must be removed at launch.

Keep staging protected appropriately during development. Before release, prepare a production configuration rather than relying on someone to remember every toggle. A leftover noindex header may not be visible in the page editor.

Save exports of the old pages, redirect rules and critical settings. A backup is valuable only if you know how to restore the part that fails. Confirm domain, certificate and hosting access before the launch window, not during it.

Use a launch acceptance checklist

After the new domain is serving the site, test the real public addresses. Check permanent redirects from old URLs to final destinations without unnecessary intermediate hops. Confirm HTTPS works on both sides and that a redirect does not depend on a certificate that has expired.

Update navigation, sitemaps, canonical URLs and other owned references to the final addresses. Verify the relevant Search Console properties. For an eligible domain move, use the Change of Address tool after the prerequisites are satisfied; it is not a substitute for redirects and is not used for every kind of URL change.

Keep a timestamped log of deployment, DNS and configuration changes. If enquiries stop, that log helps separate a form problem from a traffic change. Tell the sales or customer service team what is changing so they can report unusual failures quickly.

Monitor page groups, not a single ranking

During the first checks, focus on response errors, failed journeys and unexpected redirects. Then compare the important page groups across the old and new domains. Watch search clicks, indexing information and completed business actions together.

A temporary change in search visibility is possible while a move is processed. There is no reliable universal completion date. If a particular section drops while others transfer, inspect that section’s mapping and templates instead of assuming the whole migration needs to be reversed.

Retain redirects long term. Google recommends generally at least one year; customer bookmarks and external links can justify keeping them longer. Maintain control of the old domain and its working redirect infrastructure. Update valuable external references where you can, but do not make the move depend on every third party responding.

For unexplained exclusions, follow the crawling and indexing diagnosis. For a store, use the ecommerce checklist to test category, product and variant behaviour separately.

Close the project with evidence

The handover should contain the final mapping, tested failures and their resolutions, outstanding issues, access owners and the monitoring schedule. Record any deliberately retired pages so a future team does not mistake an intentional 410 for an accidental deletion.

I would also keep the launch baseline alongside the results. That makes a later discussion about performance more concrete than “rankings seemed fine on launch day”. A migration is an operational change with SEO consequences, not just a ranking exercise.

Common questions