Rebrand without losing your SEO: the domain-migration playbook

You can move your site to a new domain without losing the rankings you’ve built — Google’s migration machinery exists precisely for this. The short version: map every old URL to its new equivalent, one to one; 301-redirect every one of them; file a Change of Address in Search Console; and keep the redirects alive for at least a year. Do it in that order and Google transfers your signals instead of resetting them. This guide is the mechanics of the move; whether to rebrand at all is a separate decision, and when and how to rename a project owns it. Come here once the answer is yes.

What should you settle before anything moves?

Three decisions, all before you touch DNS.

Change one thing at a time. Google explicitly advises against bundling a new domain with a redesign or CMS switch: “Plan your changes to your site one after the other, not everything at the same time.” Move the domain with the site otherwise unchanged, and if rankings wobble you’ll know which change did it. If the rebrand also means leaving your registrar, that’s its own multi-day process — schedule it clear of cutover week.

Time the cutover for a dip. If traffic is seasonal or sags on certain weekdays, Google suggests moving during the recurring lulls.

Move everything at once — unless you’re huge. Google recommends small and medium sites move all URLs simultaneously; only large sites have the option of moving section by section.

How do you prepare the new domain?

1. Stand up the new site completely — content, images, TLS — before any redirect goes live. Connect the new domain to your host and run the first-hour setup checklist.
2. Get email working before you announce. Outside Google’s checklist, but non-negotiable in practice: a rebrand that breaks inbound mail is a self-inflicted outage; set up email on your domain covers the MX records.
3. Write the go-live robots.txt now. If you noindexed or blocked crawling while building, have the production version ready — leftover blocks are a named item on Google’s own troubleshooting list. And leave the old domain crawlable: a Disallow there means Googlebot never fetches the page, so it never discovers the redirect sitting on it. Return 404 or 410 for content you’re deliberately leaving behind.
4. Verify both old and new properties in Search Console, every variant — www, non-www, http, https, subdomains — under the same Google account. The old property must cover the whole host, not just a path, or the Change of Address tool won’t accept it.
5. Audit the new domain’s past. If it had a previous owner, check it for leftover manual actions and URL removal requests. (Google’s site-move doc still mentions porting a crawl-rate setting — ignore that; the crawl-rate limiter was retired from Search Console in 2024, and Googlebot now throttles automatically off your server’s responses.)
6. Take a baseline. Export Search Console performance per URL, an analytics snapshot, and a full crawl of the old site. Without it you can’t prove what broke — or that nothing did. Update GA4/GTM domain and cross-domain settings for the new host while you’re there.
7. Check server capacity. Google temporarily crawls the new site harder than usual after a migration — old-site crawls redirect there on top of normal crawling.

How do you build the redirect map?

Inventory every old URL — sitemaps, server logs, analytics, Search Console’s Links report — including images, video, CSS, and JavaScript, and map each to its new destination.

One to one is the rule, not a nicety. Google warns against redirecting many old URLs to “one irrelevant single URL destination, such as the home page of the new site” — it confuses users and “might be treated as a soft 404 error.” The only sanctioned exception is genuine consolidation.

Use server-side permanent redirects — Google recommends “HTTP permanent redirects if possible, such as 301 and 308.” If you’ve read that a 301 leaks a fixed share of link equity, discard it: that figure was never Google’s, and current guidance kills it outright — “Don’t worry about link credit. 301 and other permanent redirects don’t cause a loss in PageRank.” Avoid chains; Googlebot follows up to 10 hops, but Google advises going straight to the final URL, “ideally no more than 3 and fewer than 5” if a chain is unavoidable. Confirm your host can do any of this before you build the map — several managed platforms cap redirect counts or can’t redirect off-domain at all, leaving you a small server or a CDN redirect layer in front of the old domain.

On the new site itself: give every page a self-referencing rel="canonical", update hreflang annotations if you’re multilingual, and point internal links directly at new URLs — no redirect hops inside your own site. Save two artifacts: a sitemap of the new URLs, and the list of external sites linking to your old ones.

Then, before you flip anything, crawl the destination column of your map against the live new site and confirm every URL returns 200. A redirect into a 404 is worse than no redirect at all, and at scale you won’t notice until Search Console’s “Not Found” report catches up days later.

What does the Change of Address tool actually do?

Flip the redirects on first — the tool requires a 301 from your old homepage and recommends them on your canonical pages before it accepts the request. File the Change of Address on the old property in Search Console, then repeat for every subdomain — protocols move with the source property, subdomains don’t: “the tool does not move any subdomains below the specified domain (including www).”

In Google’s words, it “tells Google to emphasize crawling and indexing your new site over crawling your old site,” forwards signals from old to new, and prefers the new site for canonical decisions — and “these actions continue for 180 days after you start migration in Search Console.” It’s an accelerator, not a teleport — the old site isn’t erased from the index, and the move isn’t instant.

It’s also reversible, but only for a while: within those 180 days you can remove the old→new redirects, put reverse redirects in place, and click Cancel Move. After that window there’s no undo, only a fresh migration.

Know its limits — Google is explicit. Don’t use it for HTTP→HTTPS moves, for www/non-www changes on the same domain, for moving pages to new paths within the same site, or for hosting/CDN changes where URLs don’t change at all. It exists for one job: moving a site from one domain or subdomain to another — including into a subfolder of a different domain. And don’t chain moves — after filing A→B, you can’t immediately file B→C.

Submit the new sitemap alongside the old one; the old one’s indexed count should decay toward zero as the new one climbs. Ignore the warnings about those URLs redirecting — Google says that’s normal — and retire it once the handover is done.

Why does Google say both “180 days” and “at least 1 year”?

Because they answer different questions — and conflating them is the most common error in rebrand advice.

180 days is the Change of Address tool’s window. Signal forwarding runs for 180 days from filing; after that, “Google does not recognize any relationship between the old and new sites, and treats the old site as an unrelated site, if still present and crawlable.” Its own page sets the floor accordingly: keep redirects “at least 180 days — longer if you still see any traffic to them from Google Search.”

At least one year is the general redirect-retention guidance. The site-move documentation says: “Keep the redirects for as long as possible, generally at least 1 year” — long enough for the web’s remaining links to old URLs to be recrawled and reassigned — and “from users’ perspective, consider keeping redirects indefinitely.”

So: 180 days is when the tool stops helping; a year or more is how long the redirects must live. Plan around the longer number.

Hence the step almost everyone forgets: redirects only exist while the old domain still resolves and something still serves them. That’s three live things for a year or more — the registration, DNS pointing at a server or redirect service you control, and the rule set itself. Let the registration lapse, cancel the old hosting, or repoint the old domain’s nameservers at the new site, and the 1:1 map dies with it: best case everything collapses into a homepage redirect, which is the soft-404 pattern Google warned about above. Google recommends “continuing to pay for the old domain for at least a year” to keep it out of malicious hands; in practice, budget to renew it indefinitely. It belongs on the short list of domains worth holding without using.

What do you watch after go-live?

Remove noindex rules and robots.txt blocks that only protected the unlaunched site, then test the redirects at scale — the URL Inspection tool plus a crawler — and watch Search Console for “Not Found” spikes that reveal redirects pointing at wrong URLs. Expect DNS turbulence in the first hours — why isn’t my domain working separates propagation delay from real breakage.

Then the genuinely missed step: re-upload your disavow file. It doesn’t transfer — Google’s wording is “we recommend that you re-upload it again using the Search Console account of the new site.” Do the outreach: Google recommends contacting the sites linking to your old URLs, prioritized by inbound traffic, and repointing social profiles and ad campaigns.

On timelines, trust only what Google actually publishes: visibility “may fluctuate temporarily during the move,” rankings “settle down over time,” and a small-to-medium site “can take a few weeks for most pages to move” in the index, larger sites longer. No official traffic-dip percentage or recovery date exists — be suspicious of anyone quoting one.

A rebrand also hands you the naming problem again. If the new name isn’t settled yet, Domain Yoga turns one prompt into roughly 250 availability-checked, brandability-ranked ideas per search — $2–$5 a search, no subscription, credits never expire — so the domain you migrate to is one you actually own.