What Actually Breaks When Your Company Changes Its Domain Name?

What Actually Breaks When Your Company Changes Its Domain Name?

Far more than the website. A domain is the identity behind your email authentication, your single sign-on callbacks, your webhook endpoints, your SSL certificates, and every link anyone has ever saved. The site itself is the easy part, and it is the only part most plans cover.

Rebrands, acquisitions and the slow realisation that the original name was a mistake all end in the same place: someone asks how hard it would be to move to a new domain.

The honest answer is that it is not hard, but it is wide. There are perhaps thirty places a domain is written down in a modern company, and missing any one of them produces a failure that shows up weeks later.

What Does Google Say About the Search Side?

That it is a solved problem if you use permanent redirects and keep them. Google's site move documentation is direct about the mechanism: "use HTTP permanent redirects if possible, such as 301 and 308."

It is equally direct about duration, advising you to "keep the redirects for as long as possible, generally at least 1 year." That single sentence undoes the most common plan we see, which is to redirect for three months and then retire the old domain to save money.

The documentation names a domain change as one of the scenarios it covers, alongside HTTP to HTTPS conversion, domain consolidation, and URL path changes. Only the first of those is a domain move in the sense meant here, and it is the highest risk of the four.

Do You Need the Change of Address Tool?

If you are moving between domains, yes. Google's Search Console documentation says the tool "tells Google about your change, and helps to migrate your Google Search results from your old site to your new site," and that it forwards "various signals from the old site to the new site."

There are prerequisites worth knowing before the day itself. You must own both properties in Search Console under the same Google account. It works only on domain-level properties, not path-level ones. And the 301 redirects must already be in place, because "the tool runs a quick check before sending the move request to Google, to confirm that you own both sites, and to check for 301s on a few pages on your site."

The detail that changes your timeline is the duration. Its actions "continue for 180 days after you start migration in Search Console," and after that "Google does not recognize any relationship between the old and new sites." So your redirects need to outlive the tool by a wide margin, which is why the one year minimum matters.

It is also narrower than people assume. The tool is not for HTTP to HTTPS moves, for www and non-www variations, or for moving pages within the same domain. And it does not handle subdomains for you: you submit it for each variant.

What Breaks in Email, and Why Is It the Worst Part?

Your sending reputation does not transfer. A new domain is an unknown sender, and every authentication record has to be rebuilt from scratch before you send anything at volume.

Google's email sender guidelines set the bar. Every sender must "set up SPF or DKIM email authentication for your sending domains." Bulk senders, defined as those sending "more than 5,000 messages per day to Gmail accounts," must set up both SPF and DKIM, and must "set up DMARC email authentication for your sending domain." These requirements took effect on 1 February 2024.

The guidelines also set a quality bar that a fresh domain can trip over. They require senders to "keep spam rates reported in Postmaster Tools below 0.3%," and recommend keeping them "below 0.10% and avoid ever reaching a spam rate of 0.30% or higher."

So the sequence matters enormously. Set up SPF, DKIM and DMARC on the new domain, send low volumes first, and watch the rates before you move a newsletter across. Migrating the marketing site on Monday and the mailing list on Tuesday is how a rebrand turns into a deliverability problem, which compounds the ordinary difficulties we covered in why marketing emails land in spam.

What Else Holds Your Domain Name That Nobody Remembers?

The integration layer, which has no owner and fails silently. This is where the post-migration bug reports come from.

Every OAuth application has a redirect URI. Every webhook you receive has an endpoint URL registered in someone else's system. Every third party script has an allowed domain list. Your content security policy names domains explicitly. Your CORS configuration does too. Analytics properties are bound to a hostname. Payment providers hold return URLs. Calendar booking tools hold embed origins. Your CDN and your SSL certificate both need the new name before the first request arrives.

None of these produce an error page. They produce a login that loops, a form that submits nothing, a payment that returns to a dead URL, and a report that shows traffic falling off a cliff for reasons unrelated to traffic.

Make a list of every external service that knows your domain, before you plan the move. Reading through your own content security policy is a surprisingly effective way to find half of them, as our guide to CSP explains.

What Should Happen in Which Order?

New domain live and boring first, then email, then search, then the old domain's long tail.

Buy and secure the domain. Issue certificates. Stand up the new site at the new address, reachable but not yet promoted. Configure SPF, DKIM and DMARC and start sending small volumes from it. Update every integration on the list above. Only then put the redirects in place, submit the Change of Address, and update your sitemap.

The reason for this order is that redirects are the point of no return for humans. Once the old address bounces visitors onward, every broken integration becomes a live incident rather than a staging problem.

How Long Should You Keep the Old Domain?

Longer than feels necessary, and longer than one year if email ever ran on it. Google's minimum guidance is at least a year for redirects. Email addresses have a much longer tail than links do.

People will email your old address for years. Invoices, legal notices, password resets on accounts nobody remembers creating, and the one supplier who never updates anything. Letting the old domain lapse means those messages bounce, and it means someone else can register it and receive them.

Our default recommendation is to hold the old domain indefinitely and treat the renewal as a cost of the rebrand rather than a temporary expense. It is a small annual fee against a category of problem that is impossible to fix afterwards.

What Should You Measure to Know It Worked?

Four things, watched for eight weeks rather than checked once. Indexed pages on the new domain rising while the old falls. Organic clicks in aggregate across both properties, because looking at only the new one hides a shortfall. Crawl errors on the new domain. And email delivery and spam rates for the new sending domain.

Keep both Search Console properties and read them side by side. The most common misdiagnosis is panic at week two, when the new domain has not yet absorbed the old one's visibility and the combined picture is actually fine.

Set an expectation with everyone involved before you start: there will be a dip, it is normal, and the question is whether the combined total recovers. If you have never done this, our notes on migrating a website without losing search visibility cover the measurement side in more detail.

What Goes Wrong Most Often?

Redirecting everything to the homepage. It is the single most damaging shortcut available, because it throws away the specific relevance of every old URL and tells search engines that a hundred different pages all became one page.

The other recurring failures are a redirect chain three hops long instead of one, retiring the old domain at the six month mark, forgetting a subdomain entirely, and updating the website while leaving the app, the docs and the status page on the old name.

Each of those is cheap to avoid with a mapping file. One row per old URL, one column for its new destination, checked before launch and again a week after.

Is It Ever Worth Not Moving?

Sometimes, and it is worth asking properly rather than treating the move as inevitable. If the current domain has years of accumulated links and the new name is only marginally better, you are spending real visibility on a preference.

The cases where it clearly pays are a name that actively confuses buyers, a legal or trademark requirement, a merger where two brands must become one, and a domain whose spelling has to be explained on every phone call.

The cases where it rarely pays are a slightly shorter name, a fashionable extension, and a founder who has gone off the old one. Those are real feelings and they are not usually worth a year of redirect maintenance and a rebuilt sending reputation.

If a domain change is on your roadmap and you would like someone to pressure test the plan before anything is redirected, we are happy to go through it with you at phoenix.studio.