Handled improperly, traffic and rankings could tank more or less overnight, with the obvious knock-on effect on business revenue.
But, handled properly, risk can be minimised and the experience can be made relatively painless.

Why would you change domain name?

Firstly, it’s worth mentioning that it’s always better to avoid changing domain name if at all possible. Even when things are done right, migrations can still lead to fluctuations or a drop in traffic which might last for months.
I came across this post in Google’s support forums after an SEO professional (and the commenters on the thread) were perplexed as to why a migration seemingly done correctly had led to a loss in rankings and traffic that was showing no sign of recovery after several months.
All that is to say, avoid a domain name switch if you can.
But, there are of course some instances when it’s unavoidable and makes sense to do so:

Business needs

There might be wider business pressures forcing the switch. Maybe the company was bought out by another, or has changed direction. The company might have expanded from the narrowly-focused domain name originally chosen.
You might have started out with hatsforhamsters.co.uk, but have since branched out into hats for other kinds of pets. In this case a move to hatsforpets.co.uk would make sense. No one steal my next business venture, by the way.

Internationalisation

Moving from a country code top-level domain (CCTLD) such as .co.uk or .fr would be advisable if you want to grow organic search in countries outside of the CCTLD.
It would be worth moving to a generic top-level domain (GTLD) such as .com if you want to grow international traffic and revenue.
So, if hatsforpets.co.uk is absolutely booming and there’s a massive appetite for hats for pets in other countries, a switch to hatsforpets.com would be sensible, to allow better targeting in international territories.
Check out our guide to all things international SEO for more information.

Merging several domains into one

Especially in larger organisations, it’s not too uncommon to see multiple domains, whether that’s separate domains for individual countries, or perhaps microsites built for specific products.
Migrating multiple properties into the main domain can make sense in cases like this as despite the relatively short term risk involved, the long term benefit in terms of consolidating authority and resource in one domain is worthwhile.

Moving from http to https

I’d hope that most sites did this years ago, but you never know. Way back in 2018, Google started marking all HTTP sites as non-secure, and HTTPS has been a small ranking factor since 2014. So, on the off chance you haven’t done so already, get your site on HTTPS. Google treats this as a site move with URL changes.

When NOT to change domain name

Don’t change your domain name because you’ve bought a domain name with your primary keyword in it and you think it’d be good for SEO to change.
It won’t be worth the fuss: although some ranking factor studies suggest a small benefit to having your keyword in the domain name, Google has said it’s not a factor.
Assuming you’re currently ranking for some terms, whatever small benefit you may or may not get from having a keyword domain name wouldn’t be worth the ranking and traffic fluctuations inherent to a migration.

How to change domain name without losing traffic

Traffic is certainly likely to fluctuate in the short term, but following these steps will help:

1) Keep as much as possible the same

Switching domains is complex enough, so keep as much else as you can the same. Keep
URL structures the same to help Google understand the relationship between the old and new pages and ease the transition.
Keep the CMS the same.
Keep the website design and on-page content the same.

Although basic and obvious technical errors such as broken internal links or redirect chains could be fixed during the migration, I tend to like to keep any significant bits of work, like revamping the content or design, or auditing and improving all blog content, outside of the scope of the domain name change.
This isn’t just to reduce complexity, but also to enable better identification of where things have gone well, or badly. If you’ve accompanied the domain name switch with new copy on every page and a change to the layout of your page templates, it’s difficult to pinpoint what has caused the success or issue.

2) Crawl and understand the current site

Run a Screaming Frog crawl of your existing domain to get a list of every URL on the site. Include the XML sitemaps in the crawl to help ensure nothing is missed. Match these URLs up with traffic and backlink data using the API connections with Google Analytics, Google Search Console and Ahrefs.

This stage highlights the top-priority pages on your expired domain that must be 301-redirected. Additionally, this data will be a handy benchmark when comparing performance post-migration.
Verify the new domain name in Search Console and if you haven’t done so already, make sure your old domain name is verified too. If doing this at the domain level, you won’t need to add www. and non-www. versions.

3) Check the health of the new domain

Once the new Search Console is verified and up and running, you’ll be able to see if that domain has been the subject of any manual actions. If so, you’re in a bit of trouble, but check out Google’s guide on what to do, and how to file a reconsideration request.
Using Ahrefs, check the backlink data for the new domain. Google is rather good these days at identifying when incoming links are obviously spammy or toxic, and will automatically discount them. But, if the domain has been hit with a link-based manual action or you have spammy links on a wide scale, get all the manipulative, spammy and toxic links in a disavow file and upload it to the newly created Search Console.
Take a look at the new domain on ​​https://web.archive.org/ for any suspicious or spammy looking content it had on there in the past that may have raised some red flags with Google.

4) Map redirects

This is absolutely the most important step when it comes to changing domain name without losing rankings and traffic.
Using your list of URLs compiled in the step above, add a new column for the new URL and map out your 301 redirects.
These should be used to redirect an old page to a new page with equivalent content. Do note that if all that’s changing is the domain name or a move from http to https, with all URL slugs remaining the same, mapping individual redirects wouldn’t be necessary and this could be handled with a wildcard redirect.

Whilst you can redirect many old URLs to a single new URL, this should only be done if the new URL is relevant. Avoid redirecting tons of old URLs to a less relevant page such as the homepage, as there’s a chance this could be seen as soft 404s.
This is detailed in Google’s Webmaster Guidelines for moving a site with URL changes, which is definitely worth a read.
A few other key points on 301 redirects worth considering when changing domain:

  • Avoid redirect chains where possible.
  • 301 redirects do not cause any loss in PageRank (apparently, but in my experience it’s best to avoid changing URLs wherever possible). In this vein, it’s worth asking external publishers linking to your site if they could update their link to your new URL.
  • Only redirect a URL if it’s valuable or if you have an equal page to redirect it to on the new domain. If there’s no equivalent new URL, or the old one wasn’t ranking, driving traffic or didn’t have any backlinks, let the page 404. There is nothing wrong with a 404 if that page had no value and doesn’t need to be on your site anymore.

5) Ensure technical elements are correct

There are several technical areas to check on the new domain, which can often be missed:
Every URL on the new domain should have a self-referencing canonical tag. Double-check that the canonical on the new domain contains the new domain name, and is referencing HTTPS and not HTTP! Once or twice I’ve seen a recently-migrated domain that still has canonicals referencing the old domain name, which certainly won’t do your rankings and traffic any favours.
Likewise, ensure a new xml sitemap is created and correctly references the new URLs. Additionally, ensure the robots.txt sitemap reference is updated to the new domain.
Update internal links on the new domain so that internal redirects aren’t required.

6) What to check after migrating to a new domain

Most importantly, test the 301 redirects. You can do this by putting your list of URLs in Screaming Frog’s list mode.
If you don’t have access to Screaming Frog, use a site like https://httpstatus.io/ to check the status of your old URLs and confirm they’re redirecting as expected. At this stage it’s useful to manually check your old priority pages are redirecting correctly, and test what happens when you click a few Google search results too.

Check that whatever rule you had in place blocking the new domain from being accessed by Google is removed, whether that was a robots.txt exclusion or password protection. Also confirm that redirect rules are in place for www or non-www. versions of URLs, as well as trailing slash and non-trailing slash URLs.
Don’t forget to change links from social or business profiles like LinkedIn, Google My Business and Facebook, too. It can also be useful and generally less confusing all round if you get a list of your important citations and change those, as well as updating email signatures and shouting about the domain name change on social media.

7) Google Search Console tasks after switching domains

There are a few steps to take on Search Console when a new site goes live too:
Use Google Search Console’s change of address tool to tell Google about the change – although this isn’t necessary if you’re simply moving from http to https.
Submit the new sitemap to the new domain’s Google Search Console property and request indexing of the homepage.
Ensure any settings you had in your old Search Console are carried across to the new Search Console. For example, any parameter exclusions or disavow files that remain relevant would need to be replaced in the new property.

8) Monitoring the success of a migration

After you’ve changed domain name, use Search Console to monitor the progress of indexing and traffic.

In the old domain’s property, you should expect to see indexed URLs, impressions and clicks decrease over time, and in the new domain’s property you should expect to see those increasing, along with the list of queries in the Search Results report.

Final thoughts

So there you have it. To summarise:

  • Try to avoid changing domain name if possible, but there are definitely valid reasons to do so.
  • Don’t change anything else: keep elements like the design, content and URL structure the same if you can.
  • Crawl your current domain and gather data on the performance of its URLs.
    Ensure Search Console is set up for the old and new domains.
  • Check the health of the new domain name by assessing the backlinks, looking at https://web.archive.org/ and checking for manual actions in Search Console.
  • Ensure every valuable old URL 301 redirects to a like for like equivalent on the new domain. There’s nothing wrong with 404’ing an old URL if it was useless or there’s no equivalent content on the new domain.
  • Confirm that elements such as canonicals, the xml sitemap, internal links and robots.txt are updated to reflect the domain name switch.
  • Carry out the required tasks in Search Console to help Google understand the switch, and monitor the progress of the migration.

If you have any questions, don’t hesitate to get in touch with us.