Domains get changed for a few reasons: the company was renamed, two brands merged, the original is long or hard to spell, or a better one became available.
The work is not difficult, but done wrong it costs years of accumulated search authority — and the loss appears gradually rather than immediately, disappearing over several weeks, by which point diagnosing it is hard.
Here is the whole procedure, including the step most often got wrong.
First: is it necessary
Changing domain always costs something; the only question is how much. Even done perfectly, Google takes weeks to months to rebuild trust.
Worth it for: a company rename with a new legal entity, two brands merging, a domain with negative history.
Not worth it for: preferring the sound of a new one, wanting something shorter, or hearing that a particular extension helps SEO, which it does not.
If your current domain merely falls short of ideal, it usually is not worth it. Buy the new one and point it at the existing site — you keep the brand asset without disturbing what works.
The critical step: map page to page
This is where it goes wrong, and the failure is not obvious.
The common approach redirects every old address to the new home page. Simple to configure and the site “works”, but Google reads that as a soft 404, because the destination has nothing to do with what the visitor requested.
The consequence is that authority accumulated by the old pages does not transfer. The redirect achieves nothing.
Map them individually instead: /about/ on the old domain to /about/ on the new one, /services/ to the corresponding service page. Where structure is unchanged, map the pattern; where it changed, list the correspondences by hand.
In a merge we ran recently, the old site had 28 indexed addresses and a structure that did not match the new one. The answer was a table: /en/services to the build services page, /zh/case-studies to client work, and several old articles each to whichever new article was closest in subject. One at a time, with nothing dumped on the home page.
What about old pages with no equivalent? Two options: redirect to the most relevant category page, or return 404. Do not send them to the home page. Where nothing relevant exists, a 404 is more honest than a soft 404 and Google handles it more cleanly.
301, not 302
301 means permanently moved: Google transfers authority and updates its index. 302 means temporarily moved: the old address stays indexed and nothing transfers.
Domain changes require 301. Get this wrong and everything else was wasted.
Verify it: request an old address from the command line and read the status code. Do not trust a setting labelled “permanent” — test it.
Keep the old domain
Consistently underestimated.
Renew the old domain for at least a year, preferably longer. Search engines need time to swap the index. Links on other people’s sites will not be updated. Business cards, brochures and customers’ bookmarks all still carry it.
The redirect has to stay running. Let the domain lapse and every one of those entry points dies at once, silently — nobody will tell you.
Mind the email as well. If your addresses are on the old domain, letting it lapse stops mail arriving. It is a separate matter from the website and easy to overlook when the focus is the site.
Five other things that have to happen
1. Update and resubmit the sitemap. It should contain only new-domain addresses and nothing that redirects. Submit it in Google Search Console.
2. Use the Change of Address tool in Search Console. A dedicated function that tells Google explicitly. Both domains must be verified there first.
3. Check every internal link. Hard-coded old addresses inside pages send visitors from the new site back to the old domain and forward again, adding a pointless hop. Canonical tags, hreflang and structured data all carry addresses too and all need changing.
This is easy to miss because none of it is visible on the page. Our approach is to replace them at build time and then check hard: if a single file still mentions the old domain, the release aborts. Checking this by hand guarantees eventually missing one.
4. Update external listings. Google Business Profile, social profiles, industry directories, links on partner sites. Leaving them raises no error and keeps pointing authority at the old address indefinitely.
5. Keep company details consistent. If the domain change accompanies a rename, then the website, business profile, social accounts and invoices should all move to the same name at once. While they disagree, neither search engines nor AI assistants can confirm these are one company, which weakens everything else.
What to watch afterwards
Three things over the following weeks:
Index counts. Pages indexed on the new domain should climb while the old declines; the curves crossing is normal. If the new one stays flat, check whether anything is blocked by robots rules or noindex.
Redirect errors. Search Console will list old addresses under not-indexed, marked as redirecting, which is expected. Soft 404s appearing there mean a mapping is wrong and needs revisiting.
Traffic. A short-term drop is normal and usually recovers within weeks. Still down after a month points back at the page mapping.
A way to reduce the risk
Where possible, go in two stages: apply the redirect to a narrow path first — one directory — and confirm the redirects resolve correctly, the destinations work, and nothing loops, before widening it to everything.
We did this on our own merge: one directory first, verifying three things — that redirects were correct, that requests still reached the origin where needed, and that logged-in users were unaffected — and only then opening it up. If something had been wrong, the blast radius was one directory.
Twenty extra minutes buys “a problem affects one directory” instead of “the site is down”.
We completed a domain merge recently and the order above is what was actually done. Ask if you are planning something similar — these operations are irreversible and the checklist is worth completing before starting.