Can I just redirect every old URL to the new homepage?

No. Google treats a mass redirect to the homepage much like a soft 404, so the old pages' rankings don't carry over. Redirect each old URL to its equivalent on the new domain with a 301.

How long should I keep the old domain and its redirects?

Google's guidance is to keep redirects as long as possible, generally at least a year. Keep the domain registered for good: if it lapses, someone else can buy it and inherit your links and your incoming email.

Do I need Search Console's Change of Address tool?

Use it. It tells Google the move is deliberate and site-wide. It requires you to verify both domains in Search Console and to have the old homepage 301-redirecting to the new one, and it only works for domain or subdomain moves.

Should I lower DNS TTLs before the move?

Yes, on any old-domain record that will point somewhere new, such as the redirect server. Lower it to around 300 seconds at least one full old TTL before the change, then raise it again once things are stable.

Domain Migration Checklist: Redirects, DNS, Email and SEO

What this covers

This is for moving a website from one domain to another, old.example to new.example, while keeping its search rankings, its inbound links and, if the domain sends mail, its email. Moving the same domain to a new host is a different and much smaller job: that’s mostly DNS and TTL planning.

One opinion up front: if you can, don’t combine the domain move with a redesign or a new URL structure. When traffic dips afterwards, and during a move it usually wobbles for a while, you want to know which change caused it. Move first, then restructure.

Before you start: list every URL that matters

The core of a domain migration is a redirect map: every old URL and where it goes. You can’t build it without a list of old URLs, and the sitemap alone isn’t enough. Combine:

the current XML sitemap,
landing pages from your analytics over the past year,
URLs that appear in server logs, including old ones that still get hits,
Search Console’s top pages and the Links report (pages other sites link to),
PDFs, images and other files people link to directly.

If you bought the new domain second-hand, look at its history before committing: the Wayback Machine for what it used to be, and Search Console’s Manual actions and Security issues once you’ve verified it. A domain with a spam past is a bad place to move a healthy site.

Weeks ahead: get the new domain ready

DNS, certificates and the site itself

Set up the new domain’s DNS, issue certificates covering every name you’ll use (at least the apex and www), and deploy the site there. The SSL check confirms each name serves a valid certificate, and the Go-Live check runs DNS, propagation, certificate, HTTP and registration checks in one pass, which is what you want on a domain that’s about to take traffic.

Keep it private without noindex

While you’re testing, protect the new domain with a password or IP allowlist rather than a noindex. A noindex left over from testing is one of the most common ways a migration goes wrong: the redirects send everyone to a site Google has been told not to index. If you do use noindex, put “remove noindex” on the cutover list in capitals, and check with the X-Robots-Tag guide. Check robots.txt for the same reason; a Disallow: / copied from staging blocks everything.

Search Console

Verify both domains. A Domain property, verified with a DNS TXT record, covers every subdomain and protocol in one go. The Change of Address tool later needs you to be a verified owner of both.

Everything that has the old domain hardcoded

This list is what turns a clean migration into a week of support tickets:

OAuth and SSO redirect URIs registered with Google, GitHub, Microsoft or your identity provider.
Payment provider webhooks and return URLs.
CORS allowlists and Content-Security-Policy sources.
Cookies. They’re scoped to a domain, so everyone gets logged out on the new one. Decide whether that’s acceptable.
Absolute URLs stored in the database: CMS content, image paths, email templates.
Analytics, tag manager, ad and affiliate settings.
Mobile apps and API clients that call the old hostname.

Email, if the domain sends or receives mail

If addresses on the old domain are moving too, set up email on the new domain well before anyone starts sending from it:

MX records for the new domain, pointing at your mail provider.
SPF, DKIM and DMARC on the new domain. Start DMARC at p=none with reporting so you can see who sends as you before you tighten it. The email check shows all of them, and MX, SPF and DMARC check explains what each one needs.
Expect the new domain to have no sending reputation. Ramp up volume rather than sending a full newsletter from it on day one.

Keep the old domain receiving mail for a long time, forwarding to the new addresses. People will keep writing to the old addresses for years.

The redirect map

One URL, one destination, 301

Each old URL redirects to the equivalent URL on the new domain with a permanent redirect (301, or 308). Where the paths stay the same, that’s one rule. Where they don’t, map them explicitly.

Don’t send everything to the new homepage. Google treats that much like a soft 404, and the old page’s standing doesn’t carry over. If a page has no equivalent, redirect it to the closest genuinely relevant page, or let it return 404 or 410. Use server-side redirects; meta refresh and JavaScript redirects are weaker signals.

Keep the path and the query string

nginx on the old domain:

server {
    listen 80;
    listen 443 ssl;
    server_name old.example www.old.example;
    # ssl_certificate / ssl_certificate_key for the old names

    location /.well-known/acme-challenge/ {
        root /var/www/acme;
    }

    location / {
        return 301 https://new.example$request_uri;
    }
}

$request_uri carries the path and the query string. For paths that change, add a map in the http block and check it before the catch-all:

map $uri $moved_to {
    default          "";
    /about-us        /about;
    /blog/2019/hello /blog/hello;
}
# inside location /, before the catch-all return:
#   if ($moved_to) { return 301 https://new.example$moved_to; }

Apache:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteRule ^ https://new.example%{REQUEST_URI} [R=301,L]

mod_rewrite passes the original query string through unless you write a new one.

On Cloudflare, use a Redirect Rule (or Bulk Redirects for an explicit list) with the path kept and “Preserve query string” enabled. The old hostnames need DNS records set to proxied, otherwise traffic never reaches Cloudflare’s edge where the rule runs.

Don’t redirect the certificate challenge

Notice the acme-challenge exception in both examples. If the old domain’s certificate renews with Let’s Encrypt’s HTTP-01 challenge, the CA follows redirects. Send the challenge to the new domain and it finds no token there, the renewal fails, and months later every HTTPS link to the old domain starts showing a certificate error. Exclude that path, or switch the old domain’s renewals to DNS-01.

Test the whole list

Put every old URL from your inventory in a file and check where each one ends up:

while read -r url; do
  printf '%s -> ' "$url"
  curl -s -o /dev/null -L -w '%{http_code} after %{num_redirects} redirect(s): %{url_effective}\n' "$url"
done < old-urls.txt

You want 200 after 1 redirect(s) and the right destination on every line. More than one hop means a chain (old http → old https → new www → new apex). Collapse it so each old URL goes straight to its final address. For individual URLs, the HTTP check shows each hop and its status code. The 301 vs 302 guide covers status codes, and redirect loops the failure that sometimes shows up when both domains sit behind the same CDN.

A few days before: lower the TTLs

If redirecting means pointing the old domain’s records at a different server, lower those records’ TTL to about 300 seconds ahead of time. It has to be at least one full old TTL before the change, so a record at 86400 needs lowering more than a day ahead. The TTL guide explains why, and how to check at the authoritative server.

On the new domain, avoid looking up hostnames before you’ve created them. Resolvers cache “doesn’t exist” answers for the negative TTL in your SOA record, and a premature test can leave a resolver saying NXDOMAIN after the record exists.

Cutover day

Switch on the redirects on the old domain.
Remove the password, IP restriction or noindex from the new domain, and check robots.txt allows crawling.
Point canonical tags at the new URLs. Absolute URLs, new domain. A canonical still pointing at the old domain tells Google the old URL is the real one, the opposite of what the redirect says.
Update hreflang so every alternate in each cluster uses the new domain.
Publish a sitemap with only new URLs and submit it in the new domain’s Search Console property.
Update internal links to the new domain directly. Don’t make your own pages rely on redirects.
Run Change of Address from the old domain’s Search Console property. It checks that the old homepage 301s to the new one. It’s for domain and subdomain moves only; it doesn’t apply to an http-to-https change or to moving a directory.
Bing Webmaster Tools has its own site move tool, and Naver Search Advisor needs the new site registered and its sitemap submitted.
Check from outside: the propagation check for the old domain’s changed records, and the HTTP and SSL checks on a sample of old and new URLs.

The old domain, from now on

The old domain isn’t finished on cutover day. It has a job for years.

Keep it registered. Indefinitely. Turn on auto-renew and keep the registrar’s payment details current. When an old domain lapses, someone else can register it, collect your remaining backlinks, receive mail sent to your old addresses, and look like you to anyone who remembers the name.
Keep the redirects running. Google’s guidance is as long as possible, generally at least a year. As long as you own the domain, there’s little reason to stop.
Keep HTTPS valid on every old hostname. Any HTTPS link to the old domain needs a valid certificate before the redirect can even happen. If the old domain sent HSTS, browsers that remember it refuse to fall back to plain HTTP, and if it’s on the HSTS preload list, that applies in every browser and to every subdomain, since preloading requires includeSubDomains. See the HSTS preload checklist.
Don’t block the old domain in robots.txt. Google has to crawl the old URLs to see the redirects.
Lock down email once nothing sends from it. If the old domain will never send mail again, publish v=spf1 -all and a DMARC policy of p=reject, so nobody else can send convincingly as it. Do this only after you’re sure no forgotten system still sends from the old addresses.

Afterwards: what to watch

Search Console, both properties. In the new property, indexed pages should rise; in the old one, “Page with redirect” should grow as Google recrawls. Google’s own documentation describes a few weeks for most pages of a medium-sized site to move, longer for large sites, and fluctuating rankings along the way.
404s on the new domain. They mostly mean a wrong entry in the redirect map. Fix the map, not just the page.
Old-domain logs. Requests landing on the catch-all rule show URLs your inventory missed that may deserve their own mapping.
Mail. DMARC aggregate reports for the new domain, and bounce rates for the first campaigns.
TTLs. Raise anything you lowered once you’re confident there won’t be a rollback.
Important backlinks. Ask the sites that send you the most traffic to update their links. Redirects carry links over, but a direct link is one hop less forever.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.