Changing a website's domain name

Every URL changes at once, so every external link, bookmark and search result depends on the redirects from the old domain.

The domain is also the identity of the site's mail, cookies and certificates, which do not move by themselves.

Search engines treat it as a site move with URL changes, and their documentation describes it as a process lasting weeks, during which both domains matter.

The redirect mapping for individual pages is its own job with its own question page; this page covers the domain-level work around it.

A certificate covering every host name you will serve, apex and `www` included.

HTTP redirected to HTTPS, and one canonical host that the other redirects to.

Strict-Transport-Security introduced with a short `max-age` first, since a long one is hard to undo if something is wrong.

Canonical tags, sitemap URLs and hreflang annotations written with the new domain — absolute URLs copied from the old site are the usual leftover.

If mail moves too: MX records, a sender policy, DKIM keys and a DMARC record on the new domain before anything sends from it.

Every URL redirecting permanently, in one hop, to its equivalent on the new domain — not everything to the new home page.

A valid certificate on the old domain too, since visitors arriving over HTTPS must complete a TLS handshake before any redirect can happen.

DNS and registration kept active and renewing: the old domain's expiry date is now a date on which every old link breaks.

Mail authentication kept on the old domain while anything still sends from it, and a strict policy once nothing does, so it cannot be used for spoofing.

Cookies scoped to the old domain do not follow visitors; sessions start again on the new one.

On the new domain: certificate coverage and details, TLS versions, HTTPS redirection, HSTS and its directives, the canonical host, canonical tags, sitemap and robots rules, and mail authentication records.

On the old domain: how each URL redirects, the number of hops, loops, the certificate still served, and the registration's expiry date.

Scanning both, and comparing the new domain's findings with a baseline of the old site, separates problems the move introduced from problems it carried over.

Recurring scans on the old domain are a cheap guard against the slow failure — a renewal missed a year later.

Redirect chains on the old domain usually come from stacking the new domain redirect on top of an existing HTTP-to-HTTPS or `www` redirect; collapse them to one hop.

A canonical tag on the new site pointing to the old domain tells search engines the old URLs are the originals, which works against the move.

A certificate error on the old domain breaks the redirect for every HTTPS visitor, even though the redirect rule itself is correct.

A missing DKIM key or DMARC record on the new domain shows up as mail landing in spam in the days after the move.

A CAA record on the new domain restricts which certificate authorities may issue for it. Copying the old domain's DNS without it is harmless; copying a CAA record that names an authority you no longer use blocks issuance.

Nameserver changes that accompany a domain move are a common source of lost records: TXT records for verification and mail authentication are the ones nobody remembers to recreate.

The new domain's registration should be checked as carefully as the old one's: registrar, expiry and automatic renewal.

Cookies set by the new site are scoped to the new domain; a cookie still declaring the old domain in its Domain attribute is rejected by the browser.

Scanning the new domain before the switch — under a temporary host name if needed — gives the baseline the post-move scan is compared against.