Rebranding? Here's the Domain Migration Checklist That Actually Prevents Traffic Loss
Changing domains during a rebrand is one of the riskiest technical moves a business can make. A step-by-step checklist for doing it without losing your search rankings.
A domain migration is one of the few technical projects that can quietly undo years of SEO work if it's rushed. Done carefully, most sites recover fully and often land in a stronger position than before. Done carelessly, it's one of the most common causes of a sudden, unexplained traffic collapse. The difference is almost entirely in the preparation.
Before you touch anything
- Audit every indexed URL on the old domain. You need a complete list of what search engines currently know about, not just your main navigation pages — old blog posts, old landing pages, and orphaned pages all count.
- Audit your backlink profile. Know which external sites link to you and which specific pages they point to, so you can prioritize getting those redirects exactly right.
- Map old URLs to new URLs one-to-one wherever possible. A redirect from an old blog post straight to your new homepage preserves almost none of that page's accumulated value — map it to its actual new equivalent.
- Pick your migration date deliberately. Avoid your highest-traffic season if you have one, and avoid Fridays — you want your team available to monitor and fix issues in the days immediately after.
The migration itself
- Set up 301 (permanent) redirects for every mapped URL, not 302s — a 302 tells search engines the move might be temporary, which means they'll hesitate to transfer ranking signals to the new URL.
- Update your canonical tags on the new domain to point to themselves, not back to the old domain.
- Update your XML sitemap to list the new URLs, and submit it fresh in Search Console (and any other webmaster tools you use) the same day you go live.
- Update internal links throughout your own site to point directly to the new URLs — don't rely on redirect chains internally even though they'll technically still work; every hop adds latency and dilutes signal slightly.
- Update every external profile you control: social media bios, directory listings, Google Business Profile, email signatures, ad campaigns — anywhere your old domain is the destination.
- Keep the old domain registered and pointed at the redirects for at least a year, ideally longer. Letting it lapse kills every redirect at once and strands any traffic or links that haven't updated yet.
What to monitor in the weeks after
- Search Console coverage reports on both properties — watch for a smooth transfer of indexed pages from old to new, not a sudden drop with no corresponding rise.
- Organic traffic, week over week, not day over day. Some dip during re-crawling and re-indexing is normal; a sustained decline past 4–6 weeks means something in the redirect mapping needs fixing.
- Server logs for 404s. These reveal redirect mapping gaps you missed in the audit — a URL that existed on the old domain but has nowhere clean to land on the new one.
- Backlink reports, watching for links that still point at old URLs returning errors instead of successfully redirecting.
A migration is not a one-day event. The DNS change happens in a day; the re-crawling, re-indexing, and signal transfer plays out over weeks to a couple of months. Judge success on that timeline, not the first 48 hours.
The mistake that causes the most damage
By far the most common cause of serious, sometimes permanent traffic loss in a domain migration is redirecting everything to the homepage instead of mapping pages individually. It's faster to set up, and it feels like it "covers" every old URL — but search engines read a homepage-catch-all redirect as a much weaker signal than a specific old-page-to-new-page match, and you lose most of the accumulated value each of those individual pages had built up. The audit step at the start exists specifically to prevent this shortcut from feeling necessary.
The bottom line
A domain migration succeeds or fails based on the mapping spreadsheet you build before you change a single DNS record, not on anything clever you do on migration day itself. Rushed migrations skip the audit; careful ones treat it as the majority of the actual work.