SEO Domain Change

Changing your domain name is like moving house. You do not just change the address on your driver's licence — you forward every piece of mail, tell the bank, and make sure the new place has the same floor plan so you do not stub your toe. For SEO, the equivalent is a 301 redirect from every old URL to its exact new counterpart. I have helped clients move domains three times, and the best result I saw was a 40 % traffic drop that took three weeks to recover. The worst was a client who redirected everything to the homepage and lost 80 % of his organic traffic permanently. The decision rule is simple: if you must change domains, treat each page as a separate asset. Use a crawler like Screaming Frog to build a complete list of every URL that has backlinks, rankings, or traffic. Map each one to the most relevant new URL. Do not send product pages to the blog. Do not send blog posts to the contact page. Then set the redirects and keep the old hosting plan live for at least three months so Google can follow the old paths. The [301 redirect](/301-redirect/) is your single most important tool here; a 302 will not pass equity. Also submit a new [sitemap](/sitemap/) for the new domain immediately after launch. I also recommend keeping the old property in Search Console as a verification that the redirects work, and only removing it after you see the new domain indexing steadily.

A domain change matters in four situations and one non-situation. The four: rebranding (your company name changes), acquisition or merger (you consolidate multiple sites under one roof), moving from a subdomain to a root domain (blog.example.com to example.com/blog), and switching from HTTP to HTTPS — yes, that is technically a protocol shift, but every SEO practitioner I know treats it with the same rigor because it involves redirects and Search Console re-verification. The non-situation: a site redesign that does not change the domain. Plenty of people trigger a domain change by accident when they install a new CMS and point it to a new URL. Do not do that. If you are redesigning, keep the domain and only change the design. I once saw a company lose six months of ranking history because they moved from their old .com to a .co.uk during a redesign. They had no reason to change the TLD. The redirects were fine, but they forgot to update internal links — every link on the new site still pointed to the old domain. That meant Google saw hundreds of redirect chains. The fix cost them two weeks of crawling. So the real rule is: only change the domain when the brand or business structure demands it. For everything else, keep the domain and update the [canonical tag](/canonical-tag/) if you must. Also, be aware that changing a domain resets some signals. Backlinks pointing to the old domain start passing equity only after the redirect is in place and Google recrawls them, which can take weeks. That is normal. Plan for it. If you have an e-commerce site with 10,000 products, the [Technical SEO](/technical-seo/) overhead of a domain change is significant; I would budget a full-time week for pre-launch auditing and redirect mapping.

I have made three mistakes on domain changes that I will not repeat. First, I used a 302 redirect instead of a 301 on my own portfolio site because I was not sure the new domain would stick. A 302 tells Google the move is temporary, so the old URL stays in the index and no link equity transfers. I lost two months of referral traffic from a backlink that pointed to an old article. Second, I redirected every old URL to the new homepage. That was lazy and it destroyed the SEO value of individual pages. Users who clicked a link expecting a specific article landed on a generic homepage and bounced. Google also saw the mismatch and treated the redirects as soft 404s. After three months, only 30 % of the old pages had been replaced in the index. Third, I forgot to update internal links. After the redirects were live, every internal link on the new site still pointed to the old domain. That created redirect chains — Google had to follow a redirect for every internal navigation click. It slowed crawling and wasted crawl budget. I now run a find-and-replace on the entire database and check it with a crawler before launch. I also learned to keep the old [robots.txt](/robots.txt/) file accessible for a few weeks after the move because Google sometimes requests it on the old domain. And I check the new domain for [hreflang tags](/hreflang-tags/) if the site is multilingual — forgetting those can cause the wrong language version to inherit the redirect.