The Domain Migration Technical Checklist: A Phase-by-Phase Plan to Move a Site to a New Domain Without Losing SEO Equity

The domain migration checklist, in one place

A domain migration is the controlled move of a live site from an old domain to a new one, preserving SEO equity through 301 redirects, Search Console signalling, and verification. It runs in six phases: the destination-domain decision, pre-migration benchmarking, staging build and test, URL-to-redirect mapping, the DNS cutover, and post-migration monitoring. Each phase has a defined task list and a failure that follows when it is skipped.

Every published 2026 migration checklist, from Semrush and Lumar to Marcel Digital and Serpstat, agrees on the same backbone: plan, prepare, test, launch, and monitor. That consensus is real, and this guide covers all of it. Where it goes further is at both ends of the sequence, with a destination-domain decision before the checklist starts and a rollback plan for when something breaks after launch.

Why a domain migration is different from a redesign

A redesign or a platform move keeps the same domain and changes what sits on it. A domain migration changes the address itself, which means every ranking signal Google holds against the old domain has to be transferred to a new one it has never crawled in this context. That transfer is what the redirect map and the Change of Address tool exist to do, and it is why a domain change carries more risk than a redesign.

The six-phase model at a glance

The phases run in order, and a phase is not closed until its checks pass. Phase 0 is the decision that frames everything after it. Phases 1 through 4 are the build and the move. Phases 5 and 6 are the handover to Google and the watch that follows. The timeline below maps the sequence so the whole migration can be seen at once before any single step is opened.

Phase 0: the destination domain decision

Before any redirect is written, the destination domain is chosen and checked. Migrating onto a fresh registration restarts authority from zero, so the new domain has to rebuild trust the old one already had. Migrating onto an aged domain that carries relevant, clean authority transfers that trust on day one and shortens the recovery dip. The destination is the single biggest lever on how a migration recovers, and it is the step the field treats as a given.

Fresh registration versus aged destination

A migration moves your equity through redirects, but the destination domain has equity of its own, and that matters. Point your site at a brand-new registration and Google sees a domain with no history, so the redirected signals land on an empty foundation. Point it at an aged domain that already holds relevant, editorially earned links and the redirected equity reinforces authority that is already there. The same redirect map produces a flatter dip and a faster recovery on the stronger foundation.

Screen the destination before you commit

An aged domain is only an asset if its history is clean. A name with a toxic inherited backlink profile or a record of prior spam will poison the migration before the first redirect fires, because the destination drags down the equity you are trying to transfer. That is why the destination is checked the same way any aged domain acquisition is checked: its backlink profile, its registration history through RDAP, and its spam screen are read before money changes hands. The diligence is detailed in the expired domain fundamentals hub and the metrics that separate a clean name from a junk one are in the domain authority metrics hub. When you are choosing the destination for a migration, browse screened aged and expired domains with clean, relevant profiles on the SEO Domains marketplace, where the inheritance is read before the domain is listed. The decision itself is covered in How to pick the new domain for migration.

Confirm the domain is transfer-ready

One technical constraint sits inside this phase. Under the ICANN Transfer Policy, a domain is locked from transfer for 60 days after it is registered or after it changes registrant, so a destination domain acquired right before a migration is not always movable yet. Confirm the destination is past that lock and fully in your control before you schedule the cutover, so a registrar hold does not strand the migration mid-move.

Phase 1: benchmark, inventory, and back up the old domain

Phase 1 captures the state of the old domain before anything changes. Crawl every URL into a complete inventory, record baseline rankings and organic traffic so the recovery can be measured against a real number, and take a full backup of files and database. Skip this phase and a migration becomes impossible to audit, because there is no before to compare the after against.

Crawl the full URL inventory

Run a full crawl of the old domain and export every indexable URL. This inventory is the source list for the redirect map in Phase 3, so it has to be complete. Pull URLs from the crawl, from the XML sitemap, from Search Console’s page report, and from your analytics, then reconcile the lists. A URL that exists but is missing from this inventory is a URL that will redirect to nothing after the move.

Record the baseline

Before the move, capture the numbers the migration will be judged against: organic sessions, top landing pages, indexed page count, and rankings for the queries that matter. Export them and date the export. A migration always produces a dip, and the only way to know whether the dip is normal or a sign of a broken redirect is to compare against a baseline that was recorded while the old domain was healthy.

Back up everything

Take a complete backup of the site files, the database, and the current redirect rules before you touch anything. This is the artefact the rollback plan in the mistakes section depends on. A migration that goes wrong with a clean, recent backup is recoverable. A migration that goes wrong without one is a rebuild.

Phase 2: build and test on staging

Phase 2 stands the site up on the new domain in a staging environment and tests it before any visitor or crawler sees it. Replicate the site, block the staging environment from indexing, and verify every template, link, and asset renders on the new domain. The defining mistake here is letting a staging build get indexed, which creates duplicate content and a competing set of URLs Google has to untangle.

Block staging from the index

A staging copy of the site on the new domain is a full duplicate, and if Google crawls it before launch, the new domain enters the index with the wrong version of every page. Protect the staging environment with HTTP authentication, a robots.txt disallow, or a noindex directive, and confirm the block works before the build goes any further. The cleanest approach is server-level authentication, because a robots or noindex rule that is forgotten at launch becomes the reason the live site will not index.

Verify the build against the old site

Walk the staging build against the old site, template by template. Check that content, internal links, structured data, canonical tags, and images all carry over and point at new-domain URLs instead of old ones. Run a crawl of the staging build and compare it to the old-domain inventory from Phase 1, so missing pages and broken links surface before launch instead of after. The full staging test routine is covered in Testing migrations on staging.

Phase 3: map every URL to a 301 redirect

Phase 3 builds the 1:1 redirect map, the heart of the migration. Every old URL gets a permanent 301 redirect to its matching new URL, with no chains, no loops, and no page left pointing to the homepage as a lazy catch-all. The redirect map is what transfers ranking equity from the old domain to the new one, and a flawed map is the leading cause of a migration that loses traffic.

One old URL, one new URL

The redirect map pairs each URL in the Phase 1 inventory with its destination on the new domain, one to one. A 301 is a permanent redirect, and it is the type that passes ranking signals, so every rule in the map is a 301 and never a 302. Where a page has no direct equivalent on the new site, redirect it to the closest relevant page, not to the homepage. A mass redirect of unmatched URLs to the homepage is read as a soft 404 and passes no equity. The full mapping-sheet method is in Building the 301 mapping sheet.

No chains, no loops, force HTTPS

A redirect chain, where URL A redirects to B which redirects to C, dilutes the signal and slows crawling, so collapse every chain to a single hop straight to the final destination. A redirect loop, where two URLs point at each other, breaks the page entirely. And the rule set forces HTTPS on the new domain, so http requests resolve to the secure new-domain URL in one hop instead of two. The deeper redirect-implementation reference lives in 301 implementation best practices.

Carry the technical files across

The redirect map is the headline, but a handful of technical files migrate with it. The XML sitemap is rebuilt for the new domain. The robots.txt is rewritten for the new domain and checked that it does not carry a leftover staging disallow. Structured data, meta and Open Graph tags, hreflang annotations, and image source paths all update to new-domain URLs. Analytics and tag-manager codes carry across so measurement is not lost at the moment it counts.

Phase 4: cut over with DNS, TTL, HTTPS, and a launch window

Phase 4 is the move itself. Lower the DNS time-to-live a day or two beforehand so the cutover propagates fast, confirm a valid SSL certificate is live on the new domain, deploy the redirect rules, and launch in a low-traffic window. The mistake that defines this phase is launching cold, with a high TTL and an unverified certificate, so the change takes a day to propagate and visitors hit security warnings in the meantime.

Lower the TTL before the move

DNS time-to-live is how long resolvers cache your domain’s records. With a default TTL of 24 or 48 hours, a cutover can take that long to reach everyone. Lower the TTL to a short value, such as 300 seconds, a day or two before the planned move, so when you switch the records the change propagates in minutes. Raise it back to a normal value once the migration is stable.

Confirm HTTPS and choose the window

A valid SSL certificate has to be live and matched to the new domain before launch, because a certificate error blocks visitors and crawlers at the door. Verify the certificate, then choose a launch window when traffic is lowest, so the inevitable settling period touches the fewest users. Deploy the redirects, switch the DNS, and watch the first requests resolve in real time instead of walking away from a fresh cutover.

Phase 5: tell Google with verification and the Change of Address tool

Phase 5 hands the move to Google. Verify the new domain as a property in Search Console, keep both old and new properties verified, submit the Change of Address request from the old property, and submit the new XML sitemap. The Change of Address tool tells Google the move is intentional and accelerates the transfer of signals. Skipping it leaves Google to infer the move from redirects alone, which is slower.

Verify both properties first

Google’s Change of Address tool has a prerequisite: both the old domain and the new domain are verified properties in the same Search Console account, and the 301 redirects from old to new are already live. With both verified and the redirects in place, the Change of Address request, submitted from the old property’s settings, signals to Google that the old domain is moving to the new one. Per Google Search Central, this is the recommended way to migrate a site to a new domain.

Submit the sitemap and keep the redirects live

Submit the new domain’s XML sitemap through its Search Console property so Google has a clean list of the new URLs to crawl. Then leave the 301 redirects in place for the long term. Google advises keeping migration redirects live for at least a year, because the ranking signals continue transferring across that window, and removing the redirects early strands the equity on the old domain. The full walkthrough is in Using GSC’s Change of Address tool.

Phase 6: post-migration monitoring for the first six months

Phase 6 is the watch. For the first six months, track index coverage, crawl errors, 404s, rankings, and organic traffic against the Phase 1 baseline, and audit redirect health on a schedule. A migration is not finished at launch. It is finished when the new domain has recovered to or past the baseline, which for a typical site takes three to six months.

What to watch and how often

In the first days, watch Search Console for crawl errors and a spike in 404s, which signal a broken or missing redirect. In the first weeks, watch index coverage as Google moves pages from the old domain to the new one. Across the first months, watch rankings and organic traffic recover toward the baseline. A dip in the early weeks is expected. A dip that deepens past the first month points at a redirect or signalling problem to investigate, not to wait out.

The realistic recovery window

Set expectations against a real number. Across the published 2026 migration guides from Semrush, Lumar, and the wider SEO field, the recovery window for a well-executed domain change is three to six months, and larger or more complex sites sit at the longer end. The expected pattern and the recovery timeline are detailed in Expected traffic loss during migration and recovery, and the six-month monitoring routine is in Post-migration monitoring for 6 months. This is also where the destination-domain decision from Phase 0 pays back: a migration onto a clean aged domain with relevant authority recovers toward the shorter end of that window, because the redirected equity reinforces a foundation that already carried trust.

The complete domain migration checklist, step by step

The six phases collapse into one ordered execution sequence. This is the checklist the field gates behind a download, laid out in full and in order, with the failure that follows each skipped step. Run it top to bottom, and do not close a step until its check passes.

Common domain migration mistakes and the rollback plan

The mistakes that wreck a migration are a short, repeatable list, and every one has a documented fix. The recurring theme is that they are preventable in the phases above, and that a recent backup makes the worst of them recoverable. This is the consolidated mistakes table, followed by the rollback plan for when a migration has to be reversed.

The table below pulls the failure modes scattered through the six phases into one place. The left column is the mistake, the centre column is the consequence, and the right column is the fix that the checklist already builds in. Read top to bottom, the fixes describe a migration that holds its equity and recovers on schedule.

The rollback plan

A rollback is the controlled reversal of a migration that has gone wrong. It is why Phase 1 takes a backup before anything changes. If the new domain fails to index, traffic collapses past the expected dip, or a critical error surfaces that cannot be patched live, the rollback restores the old domain from the backup, reverses the redirects, and returns the site to its pre-migration state while the problem is diagnosed. The rollback is only available if the backup exists, which is the practical reason Phase 1 is not optional. Plan the rollback before the cutover, define the trigger conditions that would invoke it, and confirm the backup restores cleanly in a test before you rely on it.

Source the right destination domain for your migration

The redirect map and the Change of Address tool transfer your equity, but the domain you transfer it onto decides how fast the recovery runs. A clean aged domain with relevant, earned authority is the raw material that flattens the migration dip; an unchecked drop is where a migration fails before it starts. Sourcing the destination from a screened catalogue is the step that separates a migration that recovers fast from one that bleeds. SEO Domains operates that curated marketplace.

Why the destination domain decides the recovery

Everything in this checklist protects the equity you already have. The destination domain is the one lever that adds to it. A migration onto a domain that already carries relevant authority gives the redirected signals a foundation to reinforce, while a migration onto an empty registration asks Google to rebuild trust from nothing. The technical execution is identical in both cases. The recovery curve is not.

The asset, screened before it is listed

A destination domain is only an asset if its history is clean, which is why diligence on the profile, the RDAP registration record, and the spam screen happens before purchase, not after the move. A junk domain fails that screen and becomes a liability the moment it is the destination of a redirect. A vetted domain passes it and is an asset whatever you migrate onto it. The decision of when a move is even worth making is covered in When to migrate from an old domain, and the pre-launch profile check is detailed in Pre-launch penalty check workflow.

Browse screened aged and expired domains for your migration

The legitimate demand behind every domain migration is a destination you can trust. That is the product, not a migration service, not hosting, and not a done-for-you move. SEO Domains operates the curated marketplace where aged and expired domains are screened across their backlink profiles and authority metrics before they are listed and priced, so a migration begins on a vetted, relevant name.