Domain migration checklist

Why domain moves go wrong

When you move from example.com to example.net, search engines have to recrawl every URL, follow the redirects and transfer signals from the old addresses to the new ones. Google handles this well, but only if the redirects are complete, permanent and point to equivalent content. Most traffic losses after a migration come from a handful of predictable mistakes:

• Old URLs that were forgotten and now return 404.
• Everything redirected to the new home page instead of the matching page.
• Temporary 302 redirects instead of permanent ones.
• Redirect chains through old HTTP, www and path redirects.
• Redirects removed after a few months because "Google has seen them by now".

If you can, avoid combining the domain move with a redesign, new URL structure or CMS switch. Every additional change makes it harder to tell what caused a drop. If you must change URLs as well, the redirect map below becomes even more important.

Before the move

1. Build a complete URL inventory. Collect every URL that exists or has existed on the old domain. Good sources: an XML sitemap, a full crawl of the site, the Search Console performance and page indexing reports, your analytics landing pages, backlink tools and server logs. Old URLs with backlinks matter most, even if they are no longer linked internally.
2. Create a redirect map. A simple spreadsheet with two columns: old URL and new URL. For every old URL, pick the most relevant new URL. If the paths stay the same, a single pattern rule is enough, but still write down the exceptions.
3. Map 1:1, not everything to the home page. Google treats mass redirects to the home page or to unrelated pages as soft 404s, so the signals of the old page are lost. If a page really has no successor, let it return 404 or 410 rather than redirecting it somewhere irrelevant.
4. Resolve old redirects. If the old site already has redirects, for example from a previous relaunch, update them so they point straight to the final URL on the new domain. Otherwise you create chains like old path → new path (old domain) → new domain.
5. Prepare the new domain. Set up DNS, TLS certificates for all hostnames (with and without www), the preferred host and HTTPS. Check that the new site is not blocked by robots.txt, noindex or HTTP authentication left over from staging.
6. Update on-page signals. Canonical tags, hreflang, internal links, structured data, Open Graph URLs and the XML sitemap must all use the new domain.
7. Verify both domains in Search Console. Ideally as domain properties. You need both for the Change of Address tool.
8. Record a baseline. Export rankings, traffic, indexed pages and top landing pages, so you can compare after the move.

During the move

1. Use permanent redirects. Every old URL should return 301 or 308 directly to its new URL. Both are a strong canonicalization signal and pass PageRank. See the 301 redirect guide for details.
2. Keep the path and query string wherever the structure is unchanged.
3. Redirect all variants of the old domain: http:// and https://, with and without www. Each should reach the new URL in a single hop. That means the old domain needs a valid certificate until the redirects are no longer needed.
4. Do not block the old domain in robots.txt. Googlebot has to crawl the old URLs to see the redirects.
5. Use the Change of Address tool in Search Console for the old property. It tells Google that the whole site has moved to the new domain. It only works for domain-level moves, requires that the old home page redirects to the new domain, and is not meant for HTTP to HTTPS or path changes.
6. Submit the new sitemap in the new property.

Redirect rules for the old domain

If the paths are identical, one rule on the old domain is enough. Apache (.htaccess on the old domain):

RewriteEngine On

# Individual pages whose URL has changed
RewriteRule ^about-us\.html$ https://example.net/about/ [L,R=301]
RewriteRule ^blog/(.*)$ https://example.net/magazine/$1 [L,R=301]

# Everything else: same path on the new domain
RewriteRule ^ https://example.net%{REQUEST_URI} [L,R=301]

nginx with a map for exceptions (the map block belongs in the http context):

map $uri $new_path {
    default         "";
    /about-us.html  /about/;
    /old-product    /products/new-product/;
}

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;

    if ($new_path) {
        return 301 https://example.net$new_path;
    }
    return 301 https://example.net$request_uri;
}

Note that the exception in the nginx example drops the query string. If you need it, append $is_args$args. Platform-specific options are in the guides for .htaccess, nginx and Cloudflare. For large redirect maps, Cloudflare Bulk Redirects are handy because the old domain does not even need its own server.

After the move

1. Bulk-check the redirect map. Paste the old URLs from your map into the bulk redirect checker. For every URL, check the status code (301/308), the number of hops (ideally one) and that the final URL matches the target column and returns 200. Repeat the check for the http:// and www variants of your most important URLs.
2. Spot-check individual URLs in the redirect checker, including deep links with query strings and URLs with trailing slashes.
3. Monitor Search Console for both properties: the page indexing report of the new domain should grow while the old one shrinks. Look for spikes in "Not found (404)" and "Redirect error".
4. Watch your server logs on the old domain for URLs that return 404. These are gaps in your redirect map; add them.
5. Compare with your baseline. Rankings and traffic often fluctuate for a few weeks. A persistent drop usually points to missing or wrong redirects.
6. Update backlinks. Contact the sites behind your most valuable links and ask them to link to the new domain. A redirect passes signals, but a direct link is always better and removes the dependency on the old domain.
7. Update everything you control: social profiles, Google Business Profile, ad campaigns, email signatures, newsletter templates, app store listings, payment providers and OAuth callback URLs.

How long should you keep the redirects?

Google recommends keeping redirects for at least one year. In practice: keep them permanently if you can. Backlinks, bookmarks, printed material and old emails will point to the old domain for many years, and without redirects all of these hit a dead end. Google also recommends keeping ownership of the old domain for as long as possible.

If you let the old domain expire, someone else can register it and inherit your old links. That is a risk for your brand, too.