Website & Domain migration: A complete survival guide

Just by mentioning the words “domain migration” or, even worst “website migration” to an SEO or marketing team, you’ll summon their worst fears: traffic loss, broken analytics, endless integrity checks, and more.

Yet domain migrations are extremely common, especially in the Startup world. You start with very little funding or bootstrapped, you get the first domain you can afford without overthinking the branding and a couple of years in you realize that you can now acquire a more appealing TLD or, even worse, completely rebrand your company.

It happened to endless companies. Segment and Close as an example started as Segment.io and Close.io and later acquired Segment.com and Close.com. Moz rebranded from their original SeoMoz name and made major changes to their site.

It’s happening to me right now with this very same blog you’re reading under the divbyzero.com domain name.

I started this website as divbyzero.io … the only domain extension I was able to find available back then. But from the get-go, I knew I wanted the .com domain (more on why I wanted it soon). So I sent an email:

Check the date … Dec 2, 2016. 5 years ago! Yes, it took me 5 years to convince Nick to sell me his beloved domain name :)

But in the end, I succeeded and now here I am, figuring out all the stuff I have to do to migrate my blog from the .io to the .com without losing too much organic traffic or screwing up my Google Analytics.

Given I’m going through this long, boring, and dangerous path, nothing better than sharing with you all the steps required to successfully migrate a website from one domain to another. I’ll focus a lot of my attention on not losing search engine traffic since it’s my first source of traffic.

As soon as I’ll have the first few months of traffic data I’ll also share how the transition went and what you can expect in terms of traffic drops and issues when migrating a site.

Is it worth changing your domain name?

Yes and no, it really depends on the reasons you’re doing it. I’ll try to focus on the startup angle.

For a startup, there are three main reasons to change the domain name and go through a site migration:

1. You can finally afford a better domain: .io, .ly, .app domains are cool. But a .com is gonna make your life easier and protect you from competitors. Whenever someone is gonna search for your startup name, they’ll either google it or search yourname.com.
2. You need to rebrand: Very often you’ll start with an idea and get traction with another. Or as you scale revenue you’ll need to expand your value proposition to be broader. Sometimes you might find out that your original brand is no longer a good fit with the new value proposition and will need to change it.
3. You have been acquired: Congrats! This is an edge scenario and a more complex one as often you won’t just migrate your website to a new domain but you’ll actually need to inject part of your website and content into the acquirer site. It’s challenging. Hopefully whoever acquires you will have an IT and SEO team big enough to handle it.

As I’ve said multiple times, I’m a big fan of owning yourname.com domain. It’s the most intuitive and will save you a lot of headaches. On a couple of domains I own, I receive an insane amount of emails, sometimes very important ones, where the real recipient is the owner of a lesser know TLD domain.

Owning your .com name will help with word of mouth, discoverability, and overall just spelling your email over the phone to someone. Just yesterday a nice lady over the phone told me in surprise: ” dot IO… is that a real thing?”.

So if you can get your hands on the .com for a reasonable amount of money… do it and do it as soon as possible. Playing with domain names is not an exact science and requires major changes across the board.

The sooner you can make the switch the better it’s gonna be, especially for a Startup. Here’s why.

The risks of a domain migration

There are three main risks connected to the domain migration of a website:

Traffic loss

This is the one I’m more concerned about for my own switch from the old domain to the new one.

When you change domain, you’ll lose all the indexing, authority, and ranking you had on Google. Usually, this is temporary, as soon as you implement a 301 redirect from the old domain to the new one, Google should understand what’s going on and start ranking your new domain.

However, this might not always go as planned.

It usually takes from few weeks to a couple of months to fully recover traffic. Sometimes this period can be longer, some websites never recover all the traffic they had.

Overall, if you are just switching domain names you should be 95% safe. If on top of the domain migration you are also changing website design and structure, things might get riskier.

Data loss

Losing data can be really bad. And it’s a concrete risk during a domain and website migration.

Many tools won’t let you switch domains and you’ll have to create new projects. Unluckily this means that you’ll lose all the historical data related to your old website or domain.

There are additional risks. If you have custom code integrating with third-party services like segment you’ll need to verify all of them to make sure that the new website will keep sending data correctly.

There’s no checklist here. You’ll need to reach out to customer support of each data tool you’re using and check with them what’s their migration best practice.

The Domain Migration Checklist

Now that you know the pros and cons and the risks of switching from one domain to another, let’s get started with your checklist.

I’ll go through each step I’ve taken to migrate this blog, my focus will be mainly on the marketing side of things and the public website.

If you have complex setups like web apps and APIs running under that domain, active directory, and so on, things will be more complex and both the IT team and the dev team will need to be more involved in their areas of interest.

Make an assessment of everything that needs to be migrated

This is one of the most critical steps, especially if you don’t have a rock-solid memory like me.

The first step is to note down dependency to your domain name:

• Do you have active email addresses?
• What are the marketing tools you use that might be impacted?
• What tracking tools do you have installed on your website (GA, Facebook pixel, Hubspot, etc.) ?
• Do you have tools like Zendesk or others that might live on subdomains of the domain name you’re migrating from (ie. support.yourdomain.com)

Hopefully, you’ll be able to remember most of them, but here are a few tactics to surface hidden threats:

Google Search: Search for “url:*.domain.com” to see any subdomain crawled by google. It’s not 100% reliable but it’s a good start. Here’s a quick link to this search. Replace domain.com with your old domain.

Subdomain finders: There are a bunch of tools that can help you discover all the subdomains configured for your domain. Pentest tools is one of them and it works quite well even in the free version. Enter the domain name and you’ll see all the subdomains found.

Technology Trackers: These tools analyze your website and uncover a lot of the tools being used. You might discover an old affiliate program tracking tool you had forgotten or other important stuff that is worth double-checking. BuiltWith is probably the best tool and it’s 100% free for this use case.

As you discover subdomains and tools installed on your site, you’ll get a better picture of what will need your attention. Write them down in a Google Doc.

Core Services Migration

Before thinking about the website, the first step is to start setting up the core services: dns, hosting, email.

DNS is the core technology of the Internet. They convert a domain name into a series of numbers called IP address which is used by the browser to contact your web server or find your email provider.

I use AWS so the first step has been to create the new domain name in the AWS console, it will start with an empty template. That’s ok for now, the next step is to go in your domain registrar, Namecheap in my case, and point the domain’s name servers to the AWS ones.

Next, it’s time to set up emails. Here I’m not creating brand new emails but I’ll just create an alias to my existing ones. This means nothing will really change for me, I’ll use the same Google account created for my old domain but any mail@old-domain.com will also accept mail on mail@new-domain.com.

This is pretty straightforward. Enter your GSuite admin panel, select manage domains.

Next click “add domain” and select you want to use it as an alias. You could also set it up as a secondary domain if you want to create distinct email addresses for the new domain. That’s not my case.

Now it’s time to go back to your DNS settings and configure Google’s provided Mail servers there.

To improve deliverability you might also want to enable DKIM, a security standard that certifies as valid emails coming from your mail server. I usually do it. From Google, admin go under Apps -> Google Workspace -> Gmail and click on Authenticate emails.

Now pick the new domain and Generate new record. Back to the DNS settings you’ll have to insert a new line with the code provided by Google. Once you’re done click Start authenticating in Google Workspace admin.

Congrats, one of the most tedious parts of a domain migration is completed!

At this stage, I’m ready to receive and send emails with the new domain. Luckily I’m keeping the previous domain too so I won’t need to go through changing the contact email in hundreds of different services.

It’s now time to think about my site. Actually, as I was starting to think about the domain migration, I started working with the great boutique agency Sailcode and they proposed a brand new look for this site.

What started as a simple domain migration, actually became a full website migration too! This will make things a bit riskier with search engines.

Let’s see how I’m planning to migrate my WordPress site to the new domain and new design!

The website migration

Website migrations can be easy-peasy or a real nightmare.

In my case it’s gonna be pretty easy for a couple of reasons:

1. I’m not changing the structure of the site, most changes will only be on the design side. Content will remain the same and URL structure will remain the same. This is a great advantage and whenever you’re migrating a website I recommend keeping the same URL structure as much as possible. It drastically reduces the risk of losing organic traffic.
2. My WordPress experts at Sailcode will take care of 90% of the work. It’ll save me a lot of time and headaches.

Preparing the new website environment

The first step of the website migration is creating a new environment for my divbyzero.com domain.

This step has been pretty straightforward, Kinsta, my great WordPress hosting provider, has an option to create a new website starting from an existing one. To be sure not to lose any content or change the URL structure, I’ve just cloned the old divbyzero.io site to a new site with the new domain.

After 5 minutes I was ready to go.

Preventing Search Engines from discovering the new website

Immediately after, and this is a critical step, I’ve accessed the WordPress admin of the new website and under Settings -> Reading I’ve checked the box to disable search engine crawling.

This new instance of the site is actually a 100% duplicate of the old website. I don’t want Google to discover it and consider it as duplicate content. By checking that box, Google will just ignore my new divbyzero.com domain for now.

Once this was done, we started working on the new design and rebranding. It took around a month to get the new website ready.

Final checks before going live with the new website and domain

Once everything looked good on the new domain, I performed a final check to make sure every page was where it was under the old domain website and all the SEO settings were preserved.

To do this I’ve used Screaming Frog, a very powerful SEO crawler that you can run on your desktop. It’s free for up to 100 pages, but it requires a paid license for a site with more than 100 pages.

Having both sites live I’ve performed a full crawl of both websites and then exported the results in two csv files. There’s a ton of information in these files and even more can be added by integrating it with tools such as ahref, Moz, Google Page Speed and Google Search Console.

For now I’m interested in only three columns: the url, the response code, and the indexability.

Response code and indexability are useful to double-check that the new domain is actually set to no-index to prevent search engines from spidering it. The response code is useful to look for anything different than 200.

Response code 200 means that the page was correctly delivered.

404 means the page was not found.

301 means that the page redirects to another page

50x means that the server had a problem

If you have any of these codes on your new website, that could be a potential issue. As an example, I’ve spotted a couple of links to internal pages no longer existing. Not a big deal but it’s better to fix them before going live.

Finally, I’ve sorted the excel sheets from both websites alphabetically on the URL column and put side by side the old urls with the new ones. This is useful to spot any missing page or extra page in the new website.

In my scenario, this is pretty unlikely because I’m using the same site content on the new URL. If you decide to rebuild the new website from scratch or you’re changing the content management system, this could be a lifesaver to identify major content discrepancies.

After fixing these few errors I’m good to go and take care of the SEO side of my site migration.

If you want to do an extra check, it’s also worth taking a look at your XML sitemap. It contains all the pages Google should spider and you want it to be as close as possible to the old site.

Taking care of the new website’s SEO

This is the area that I care about the most.

I want to use my new fancy divbyzero.com domain and I want to go live with my new redesigned website… but most of all I don’t want to lose traffic post launch, especially on my top pages.

Lucky I’m doing this fairly early on and my old site, while growing aggressively, doesn’t have a ton of traffic yet.

Imagine doing a site and domain migration as a SaaS marketer on a high-traffic site generating thousands of dollars every day. The risk is way higher.

It’s also worth noting that once you pull the trigger, there’s no way back. Sure you could put the new website offline and switch back to the old one on the old domain, but such an operation could make things even worst.

Again for my domain migration, I’m not expecting major issues.

Here’s what I’ve done:

Taking care of all the SEO tools

There are four major SEO tools that I use weekly: ahrefs, Surfer SEO, Google Search Console and Rankmath.

First of all, I’ve checked with the ahrefs support if it was possible to change the domain name while keeping the project with all its data. The answer unluckily has been no.

I could change the domain but it would reset all my stats. So I created a new project for my new domain. Not much else was left to do at this point, I exported in CSV my tracked keywords for the old domain and re-imported them on the new project.

Ahrefs was ready to go at this point.

For Google Search Console, I created a new project with the new domain, authenticated the domain… and waited. There’s one final step to be done here but we’ll get to it later.

SeoSurfer and RankMath really just required a couple of clicks to finalize the project.

Fixing Internal Links

The next step on my to-do list was fixing internal links. I had to make sure that all the links within the new website were pointing to the new domain and not the old one.

This is a quite frequent problem with site migrations. Back to screaming frog, I’ve performed another full crawl of the new website. Now under the External tab, you’ll be able to see all the external links found. You can also filter by your old domain to immediately find those you want to get rid of.

This is a critical step of the migration process. While through redirects, these links will still work, they’ll add extra work for the browser and the search engines’ crawlers. You don’t want that. All links should point to the correct page on the new domain without redirect chains.

Depending on how many links pointing to the old domain you’ll find, you can manually edit them or use a tool to search and replace them within your content management system’s database.

For WordPress, you can also use a plugin called Better Search and Replace.

Now the internal linking problem should be fixed.

Checking Core Vitals

Core Vitals were recently introduced by Google and are a meaningful ranking factor. I won’t enter in too many details, check this guide from Backlinko to learn more.

TL;DR: You want your new site to be as fast as possible, especially on mobile.

While building the website on the new location, I’ve constantly monitored its speed with Google PageSpeed Insights.

Once we were ready to go live I’ve integrated this wonderful tool with Screaming Frog. This way I’m able to export in Google Sheets the speed of all the pages.

Don’t over obsess with speed, it’s one of many factors, but still, it’s a good practice to check all your top pages and make sure they’re on average faster than the old urls.

Being faster than other websites is for sure an advantage, not only for SEO but also for User experience and conversion rates.

External Links

There’s usually not much you can do about external links pointing to your old domain.

Personally, I’ve changed all my social links to point to the new site and edited links I had on other websites I own or I’m an editor for.

That’s likely less than 1%. All the others will likely keep pointing at my old domain.

It’s not a big deal, once, in the final step of the website migration, I’ll enable redirects from my old site to the new target domain, the link juice should be passed to the new site. I’ll be monitoring this through ahrefs.

301 redirects will also ensure that all the referral traffic is preserved.

Migrating Google Analytics

This was the step that concerned me the most. As you might know from my revenue marketing post, I’m a big fan of tracking all the important metrics and measuring not just how much traffic I’m getting but also what content is generating more conversions and revenue.

So I didn’t want to lose my carefully configured Google Analytics and, most of all, I didn’t want to lose all my historical data. It happened to me when we migrated blog.adespresso.com under the main website adespresso.com/blog. It was a pity.

Thank God, in this scenario, with a simple domain migration, switching Google Analytics to start tracking the new domain is actually quite easy.

From GA click Admin and then in the middle column, Property, click Property Settings.

Here you just need to change the default URL setting and this step of the migration process is over.

No loss of data, no need to update the tracking code on the new site, no need to re-enable access to all users. All the new urls will be tracked as usual.

Finalizing the migration process and going live

For a simple website and domain migration, we should have now completed almost all the steps of the process.

It’s time to go live, there are just a few steps missing.

Connecting Google Analytics and Google Search Console

Now that you’ve created a new property on GSC, let’s reconnect it to Google Analytics.

From Search Console, select the new property you’ve just created, go under Settings -> Associations and connect your Google Analytics account.

Nothing else to be seen here. As soon as search engines will start ranking the new website, search data will be passed to Analytics.

Redirecting the old site to the new one

This process will change based on your hosting provider and there are different tools you could use to achieve our goal.

What we want here, assuming you’re keeping the same URL path is to redirect any visit to the old website to the same URL on the new domain.

Visitors to https://divbyzero.com/blog/b2b-saas-marketing/ should be redirected to https://divbyzero.com/blog/b2b-saas-marketing/

This is critical to avoid losing traffic. Search engines will keep sending a significant amount of traffic to the old URL for a while. You don’t want to lose those visitors.

Moreover, implementing this redirect will ensure you that all the backlinks you had built for the old domain will be passed to the new one.

Kinsta, my hosting provider, has a specific page to manage redirects. Here’s how I’ve set it up to send traffic to the exact same URL under the new domain.

You should be able to do something similar with your hosting provider, otherwise, you can contact their support and have them configure it for you at the webserver level.

Opening the new website to Search Engines

This is a critical step of the migration process, don’t screw it up.

Go back to the new WordPress website admin, Settings -> Reading, and unflag the checkbox that prevents search engines from indexing the website.

One last step and we’re ready to go!

Letting Google know about the domain migration

Now that you have migrated and redirected everything, the website migration is nearly over. There’s just one step left to make it even more clear for Google that you’ve switched domain names.

Get back in Google Search Console, select the old site, go in Settings and click “Change of Address”.

On this page, select the new property you’ve created in the previous steps and click Validate and Update.

This is gonna take some time, I’m 3 days in now and still most of the indexed URLs in Google point to the old domain.

Now… let’s cross our fingers

By now, we’ve completed all the steps in the to-do list and we’re finally live with our new website under the new domain.

What’s gonna happen next is really up to Google. I expect a meaningful traffic drop for a couple of weeks to a month but hope to regain most of the traffic by then.

I’ll keep updating this post with statistics so you’ll know what to expect going through a domain migration.

Finally, have I forgot something important? Did you go through a Website migration? If so, what was your experience? Let me know in the comments below!

Site Migration Progresses and Updates

Here I’ll keep you posted on the progress post-migration. Stay tuned because I’ll keep updating it with in-depth statistics.

September 21st Migration Update

It’s been 2 weeks now since I’ve pulled the trigger and switched domains. I have to say, they’ve been a couple of very stressful weeks looking at statistics every day.

All leading indicators are moving in the right direction but in terms of overall website traffic, I had a meaningful loss:

As you can see on September 7th I started losing nearly 50% of the traffic. In the last week, there were some signs of recovery, but for sure this is not over yet.

What happened from an SEO perspective is that the old domain started losing Domain Rank (that was totally expected) while the new website on the new domain started gaining it.

Actually, as of today, the new domain has a Domain Rank of 50, 1 point higher than the old one at its peak.

From a ranking perspective, a lot of keywords are still ranking on the old domain. That’s cool, they’re redirected anyway so no traffic loss.

Others, including a lot of high volume keywords related to my comparison of the best book summary apps, lost their ranking on the old domain and after a couple of days appeared again in the SERP on the new one… but in position >50. They were ranking in position 1 to 3 before the migration.

Here’s a snapshot from today of the ahrefs dashboard:

I think I’ll need to hold tight for another month before things starts to pick up again. I’ll keep y’all posted!!

December 1st Website migration update

This update comes slightly late, I could have likely declared victory back in November, anyway here we go:

The old domain seems to be completely deindexed from Google now and its only purpose is to redirect to the new domain to preserve old links from external websites that I’m not able to change.

Overall I’m very glad I’ve done this domain migration. I’m now on a better domain name with a better website and traffic-wise I had to suffer for a couple of months but in the end, everything got back where it was or better.

I guess this is my last update to this post, but if you have any questions on how to migrate your domain or website feel free to ask in the comments below!