Switching to a new domain might be one of the biggest fears for SEOs if you haven’t done it before.
In most cases it will require careful planning and multiple parties involved in order to get it right. This means bringing together developers, content managers, SEOs, product managers and others and having everyone aligned on what needs to be done and how. In my experience, the most common reason for failure is not lack of knowledge but poor communication and, thus, execution.
Note: With a site migration there most likely won’t be a clear success or failure once it’s launched. Not losing traffic is definitely a success, but it might also be that some pages gained traffic while the others lost. And, on the other hand, if you lose 50% of your traffic or more, roll-up your sleeves and get on it. Losing some traffic might not mean that things went wrong.
The domain change also brings up additional questions and an opportunity to change some other major things that were the bottlenecks or their implementation was not ideal to begin with. So you might ask yourself is it a good idea to do some of the following along the way:
- Change the frontend framework?
- Change the CMS platform (if the two are separate)?
- Major website restructuring?
The answer to all these questions will raise the typical SEO answer: “it depends”, but I’ll try to not leave it at that.
What major issues should be addressed during domain migration?
The most important factor here is the timeline. These usually come from the higher-level managers and you have to plan the migration accordingly. If you are 2-3 months away from the launch date you might not even want to do a full website redesign, but only change its branding.
Other factors to consider are the resources in relation to the timeline. You will likely need a dedicated engineer and a content manager to make sure you are able to finish the tasks on time.
When it comes to the frontend framework or CMS platform or both, the key here is whether you are building the website from scratch or you are just adjusting the old one. In case of the latter and a lack of time, you sure don’t want to add an additional major change as it may cause delays or launching a semi-finished website. I see framework change as led by two possible reasons, when the current framework and/or CMS:
- Is not ideal for building websites needed to be crawled by search engines (Client-Side Rendered with no SSR or SSG option)
- Causes development bottlenecks by being not ideal for developer workflow
Major website restructuring we can consider as two parts:
- Page-level restructuring (merging few pages, deleting old pages)
- Site-level restructuring (changing the information architecture i.e relation between the pages)
Page level restructuring is almost always a good idea with a bigger migration and reason being that it will likely force you to redirect some pages and migration is all about redirects anyways. Removing a page after the migration is done will bring a chain redirect given that that page had already been redirected from the previous domain.
With site-level restructuring, it mainly depends on the level of rebrand or site change you are introducing. It can be a good idea, but you need to pay attention to URL structures and whether those would require additional redirects.
Pre Launch Guide
Set up a staging server
Having a separate server will allow you to make all the necessary changes and then just point the new domain there on the launch date. If you use a headless CMS, you want to make sure you have a separate project set up and ideally also have it updated as you add the content to the current site. This will prevent manual work later and possibility of losing some pages due to human error.
Set up robots.txt to block bots (now, there are alternatives to this, and, depending on where you host, you might be able to put it behind a login wall, but that way you might not be able to crawl the website on staging)
Planning out the redirects
The biggest change here is the site-wide redirect from the old domain to the new domain. One thing to pay attention to here is to not create the chain redirects so any URL variation of your old. This means that all old domain variations should lead to your new domain prefered variation. Here’s an illustration for when your new domain preferred version is https, non-www with forward slash at the end.
Exceptions of the site-wide redirect
Existing redirects on the current site - unless you make an exception to a site-wide redirect, users will now have to go through two redirects until they reach a working page. To prevent that from happening, you would set up a redirect from olddomain.com/oldurl to newdomain.com/newurl.
Old site name in the URL - If you had an old site name in some urls, you might want to change these and here you will need to add redirects. Good thing to pay attention to is that you want to add redirects from the old domain and new domain.
Deleted pages - If you were to use the domain change to clean up some of the pages that you no longer need, you’ll need to add the redirects for those as well. Again, the rule is the same, you add a redirect to from olddomain.com/oldurl to the newdomain.com/newurl in case of a redirect, but if you don’t have any external URLs pointing to that URLs no need to add an exception redirect at all (it would go under a site-wide redirect).
Final note with the redirects is that we don’t add any redirects on the new domain. Reason being, if a page didn’t exist on the new domain, there is no need to redirect it.
Update hard-coded internal links
Depending on the platform you are using to serve your website there might be some hard-coded internal links to be changed. These would either be added by devs or within content if you don’t use relative links. You can check these by crawling either a local version of your site with Screaming Frog or the staging server and looking at those that point to your current domain.
Update naming
Updating naming sounds quite an obvious one, but it’s worth mentioning places where those would occur just in case you need a checklist:
- On site-wide places (such as navigation, footer, sidebars and more)
- In-content
- Meta titles
- Meta descriptions
- Alt text
When mentioning alt text, if you have any visuals with the brand name, you might want to replace those as well.
Post Launch Guide
Run a crawl
The fastest way to identify any issues is to run a crawl and preferably a tool that will give you a report without you having to dig through the data yourself. My go-to tool is Ahrefs, but you can use anything of your liking. The first thing you want to see is whether the crawl runs at all, but having that solved, you want to check in particular for the following:
- Links to broken pages - either some redirects don’t work, or you haven’t change an internal link to a deleted page
- Links to redirects - some pages may contain links to the old domain
- Issues with canonical links - may be a dev problem that canonical links were hard-coded or some other issue came up
- Issues with your sitemap - sitemap issues may help you discover some other problems that pages have
Add domain to Search Console
Adding the site to the search console will help you keep tracking of how Google is indexing your pages and whether there are any issues with that.
In addition, if you verify your website ownership to Ahrefs through GSC you’ll be able to crawl it faster and identify issues faster as well.
Verifying the redirects
Once things are live you want to make sure everything is redirected as you imagined. So if you have a list, you can use the Redirectinator to verify those quickly.
Email outreach
Outreach can run for a long period of time after launching your new domain, but can be a great way to change the links to your old domain to the new one, but also to add to some brand awareness of your new name.
Brand mentions with link
You want to outreach to all the blog posts mentioning your old name and linking to the old domain and in-particular those that are listicles with say ‘best x’.
Brand mentions without a link
This is just to improve the brand awareness and also perhaps use this to get a couple of new links.
You may also want to change external links to blog posts, but that might be an overkill depending on the size of your website.
Conclusion
As mentioned at the beginning of the post, having everyone aligned around the site migration is likely the most important element in finishing successfully. Everything else can be solved one way or the other. One important note I want to leave for the end is that old domain will stay in Google’s index for quite some time. If you do a search in Google with site:hundred5.com you’ll get the URLs from that domain, while the site was moved in February 2020 to toggl.com/hire or toggl.com/blog depending on the page.