How to rebrand when your domain no longer fits

First, name the actual problem

Before assuming a full rebrand, be precise about what is wrong. The problems look similar from the inside and have very different remedies.

That fourth row is worth pausing on, because it is the most common and the cheapest. If the company name still works and only the web address is awkward, you may need a domain purchase and a redirect rather than a rebrand — no new logo, no announcement, no confused customers.

Decide the scope explicitly

There are three different projects hiding under 'rebrand', and mixing them up is how a domain change turns into six months of work.

• Domain only. The name stays, the address changes. Invisible to most customers, and the whole job is redirects and email.
• Name and domain. The identity changes. Everything below applies, plus communication.
• Name only. Rare, and usually a mistake — a company operating under a name that does not match its address teaches customers two things instead of one.

Write down which one you are doing before you start, because it determines whether this is a week of technical work or a quarter of everything.

Choose the new name with stricter tests than last time

You have something you did not have the first time: evidence. You know exactly how this name failed, and that failure is the first thing the replacement has to survive.

So run the tests you skipped. Say the candidate once and have somebody type it. Show it and have somebody read it. Check recall after a delay. Read the whole address in lowercase and in an email. And this time test the scope question directly: describe the business you might be in three years and see whether the name still fits it.

Do the clearance research properly too, since a rebrand into a trademark conflict is the one version of this you cannot fix with redirects. From shortlist to registered covers what to search, and what makes an invented name easy to say and spell covers the tests.

One rule specific to rebrands: do not choose a name that is a small variation of the old one. It sounds like continuity and behaves like confusion — customers cannot tell which address is current, and neither can anything that indexes you.

Audit everything that depends on the old domain

This is the step that determines whether the migration is uneventful. Do it before you announce anything, and do it as a written list rather than from memory — a domain reaches into more systems than anyone remembers unprompted.

Two of those are the ones that bite. Webhooks and OAuth redirects are configured by other people in other systems and fail silently, sometimes weeks later. And transactional email is easy to forget precisely because it works without anyone looking at it.

Build the redirect map before launch

The single biggest avoidable loss in a domain move is sending everything to the new homepage. Every inbound link to a specific page, every bookmark, every search result becomes a visitor who wanted one thing and got a front door.

Map old URLs to the equivalent new URLs, one to one, with permanent redirects. Where no equivalent exists, redirect to the closest relevant page rather than the homepage, and only fall back to the homepage for pages that genuinely have no successor.

1. 1Export the full list of old URLs — from your sitemap, your analytics, and your server logs, because each of those knows about pages the others do not.
2. 2Sort by traffic and inbound links, so the pages that matter get the careful mapping.
3. 3Write the mapping as data — a file or a table — not as a series of hand-written rules nobody can audit later.
4. 4Redirect in one hop. A chain of redirects loses something at every step and is slower for every visitor.
5. 5Keep the query strings and anchors working where they carried meaning.
6. 6Test the map against the real list before launch, not by clicking around afterwards.

Google publishes detailed guidance on moving a site with URL changes, and it is worth following rather than improvising: permanent redirects, updated internal links, and the old domain kept alive so the redirects can keep working. Leave them in place for years rather than months — external links do not get updated on your schedule.

Update your own internal links to point directly at the new URLs too. Redirecting your own navigation is a cost you pay on every page view for no reason.

Email is the part that breaks quietly

A broken page is visible. A lost email is not, and customers keep using the old address long after any announcement — some of them have it saved in a contact card and will use it for years.

So keep receiving mail at the old domain and forward it, for far longer than feels necessary. Send from the new domain from day one, and give the new domain time to establish a sending reputation: a new domain sending your entire mailing list on its first afternoon is a deliverability problem you have created for yourself.

Check the authentication records on the new domain before the first send, not after the first bounce report. And go through everything that sends automatically — receipts, resets, alerts, calendar invitations — because those are configured once and then forgotten.

Sequence the launch

Order matters more than speed here. Nothing on this list is difficult; doing them in the wrong order is what produces an afternoon of outages.

1. 1Register the new domain and get certificates issued well in advance.
2. 2Stand the new site up on the new domain, reachable but not announced.
3. 3Configure email on the new domain and verify it end to end.
4. 4Load the redirect map on the old domain and test it against the real URL list.
5. 5Update analytics and advertising destinations.
6. 6Switch, and watch the logs for the rest of the day.
7. 7Update external profiles, listings and citations over the following week.
8. 8Announce it once the machinery works, rather than as the trigger for it.

Lower DNS caching times a day or two before you switch, and put them back afterwards. It is a small thing that shortens the window in which some visitors see the old site and others the new one.

Tell people plainly, once

Say three things: what changed, what did not, and which address is now official. That third one is not optional — a domain change looks exactly like a phishing attempt from the outside, and customers are right to be suspicious of an email telling them your address is different now.

Which is why the announcement should come from the old domain as well as the new one, and why the old site should say the same thing where visitors can see it. If somebody can verify the change from the address they already trusted, the suspicion resolves itself.

Keep the story short and unapologetic. Customers care about whether their bookmarks work and whether their invoices are still valid, not about the strategic reasoning.

Update the places you do not control

Redirects handle the traffic; they do not handle the references. Work through the profiles, listings, partner pages, app-store entries, directories and documentation that name the old address, starting with the ones that send you the most visitors.

For inbound links from sites you have a relationship with, it is worth asking for an update on the highest-value ones. For the rest, the redirect is the answer — which is another reason to keep the old domain indefinitely rather than for a defined period.

Then watch, for longer than you expect

A rebrand is a transition rather than a switch. Expect a dip and a lag: search engines have to reprocess every URL, and the recovery is measured in weeks rather than days even when everything was done correctly.

What to watch, for a couple of months:

• Redirect errors and anything returning a not-found on the old domain
• Indexing progress on the new URLs
• Traffic and conversions against the pre-move baseline, not against last week
• Email delivery and bounce rates on the new domain
• Support messages mentioning the old address — the honest measure of how well the communication worked
• Anything integrating with you that stopped calling

Resist judging the move in the first fortnight. The numbers are meaningless while reprocessing is in progress, and the temptation to intervene mid-migration is how a manageable dip becomes a real one.

Keep the old domain

Renew it indefinitely, and keep the redirects and the mail forwarding running. The annual cost is trivial against what you are protecting: every old link, every printed reference, every customer with a saved address.

There is a second reason that is easy to overlook. A lapsed domain that used to be yours can be registered by anybody, and then your old links, your old email addresses and your old reputation belong to a stranger. Letting it go is the one part of this that is genuinely hard to undo.

When not to do this

Some domains that no longer fit should be kept anyway, and it is worth being honest about which.

If the only problem is that you have grown tired of the name, wait. Founders tire of a name years before customers notice it, and 'I no longer find it exciting' is not a business case for a migration.

If the name is merely descriptive rather than actively wrong, the cost of moving usually exceeds the benefit — a slightly narrow name attached to a business people already know is a smaller problem than a transition.

And if you are unsure, use the direct traffic test. The more people who reach you by typing or remembering your address, the more a move costs, and the higher the bar it has to clear. A business found entirely through links can change domains cheaply; a business built on word of mouth is moving its own front door.