~$~/nine/index.tsx
LIVEv0.9 · mainEST. 2003

The Nines/SEO/Rebranding without tanking your SEO: a domain-change playbook.2025_10_06

Rebranding without tanking your SEO: a domain-change playbook.

author

Brian Aldrich

tag

seo

filed

2025.10.06

read_time

8 min

---

section summary

tone direct

---

A new name, a new look, a new domain. Done wrong, the rebrand resets your search equity to zero. Done right, it barely registers as a blip.

We've shepherded brands through enough domain migrations to know which ones survive intact and which ones lose six months of organic traffic. The difference is almost always the plan written before launch — not the heroics on launch day.

Rebrands are emotional. The leadership team is excited. Marketing is exhausted. Design has been polishing the same logo for three months. By the time anyone thinks about SEO, the launch date is already locked.

The good news is that domain changes are a solved problem when you treat them as engineering, not theater. The bad news is that almost nobody treats them that way until the traffic graph nosedives in week two.

What you actually risk

  • Organic traffic — links, rankings, and crawl history are tied to URLs, not brands. A sloppy migration loses all three.
  • Branded search — the queries with your old name don't disappear overnight, and the new domain has to capture them.
  • Direct conversions — bookmarks, internal links, partner referrals all still point to the old domain on day one.
  • Trust signals — review sites, citations, business directories, and AI knowledge graphs all need to be updated, often manually.

The pre-launch plan

1. Crawl everything

Before a single redirect is written, run a complete crawl of the old site. Every URL. Every redirect that's already in place. Every status code. Export it. This becomes the source of truth for the migration map.

2. Build a 1:1 redirect map

Every old URL needs an exact destination on the new domain. Not a redirect to the homepage — that's the migration equivalent of throwing out the file cabinet. Map page-to-page. If a page genuinely no longer exists on the new site, decide intentionally whether to redirect it to the closest topical equivalent or return a 410.

3. Preserve URL structure where you can

If the new site uses different slug conventions, the redirect map gets uglier. If you can preserve the path structure under the new domain, the migration is dramatically cleaner. "Same path, new domain" is the safest mode.

4. Inventory off-site signals

Backlinks worth chasing manually. GMB, business directories, review sites, partner references, podcast notes, press archives. Build the list now. You'll work it for months.

Launch day

  1. Implement 301 redirects from every old URL to its new destination. Verify with a fresh crawl that every old URL resolves to a 200 on the new domain via a single 301 hop.
  2. Update the canonical tags, the XML sitemap, the robots.txt, and the hreflang on the new domain. Submit the new sitemap in Search Console.
  3. Verify the new domain in Search Console and keep the old property verified — you'll need both for months to monitor migration health.
  4. Update internal links in the codebase. Don't rely on redirects to fix internal links forever; they slow crawl and dilute equity.
  5. Update social profiles, email signatures, and any hard-coded references in support content.

The first 90 days

Expect a small dip. A 5–15% drop in organic traffic for the first two to four weeks is normal even on clean migrations. Anything beyond that, or anything that doesn't recover by week eight, is a signal that something in the redirect map or the new site's technical foundation is wrong.

Watch the indexation graph more than the traffic graph. As Google reprocesses URLs, you'll see the old domain's indexed pages drop and the new domain's climb. If the new doesn't replace the old roughly in volume, there are pages stuck — and you need to find them.

A domain change is judged on the indexation graph, not the launch deck.

Where AI changes the migration playbook

Two places. First, the work itself: agents can build redirect maps from a crawl of the old site against a sitemap of the new one in minutes. They can flag mismatches, missing destinations, redirect chains, and pages that don't have a sensible target. The audit that used to take a week takes an afternoon.

Second, AI knowledge graphs. ChatGPT, Perplexity, and Gemini all carry an internal model of who your brand is, what you do, and what your URL is. Those models update slowly. Plan for a long tail of AI-engine confusion where users ask about your old name and get directed to your old domain. Update Wikipedia, Crunchbase, your About page, your schema, and your press footprint as aggressively as you update DNS.

Mistakes we keep watching teams make

  • Redirecting all old URLs to the homepage of the new site. The single most damaging migration error. Don't.
  • Letting old internal links rot through redirect chains for six months. Update the source.
  • Killing the old domain too early. Keep it alive and redirected for at least a year.
  • Forgetting hreflang on multi-region sites. Migrations destroy regional targeting if you don't carry it across.
  • Treating the rebrand and the migration as the same project. They aren't. The migration is engineering with deadlines. The rebrand is design with feelings. Run them on separate tracks.

What "good" looks like

A clean migration produces a small, brief dip and a full recovery inside a quarter. Branded search transitions from the old name to the new without a meaningful loss in click-through. AI engines start citing the new domain within a few months. Your team stops dreading the analytics check.

If you're staring down a rebrand, treat the migration like a software release. Plan it, stage it, ship it, monitor it. The rest is just paint.

Ready to put us to work?

next_step

~$nine init --audit

Start with an Insight Genesis audit. Six weeks. Fixed scope. A written diagnosis of where your marketing actually stands — plus a working agent prototype tailored to your business.