Website migration is a complex and challenging process.
To help you out, we have created a checklist, which can be used both as a guide and an interactive blueprint for a site move of any type.
Introduction to Website Migration
If you have decided to migrate your site, you are getting yourself into a web of intricate decision-making, flexible planning, and technical challenges. But worry not! We are here to help you figure all of it out, step by step.
Let’s start at the very beginning:
What is website migration?
Website migration is a process that a website undergoes in order to change its setup or technology. We do not call simple updates a site migration, as migration implies serious changes, usually in regard to the website’s platform, structure, content, location or design.
Although migrating a website may be a problem-solving necessity, it inevitably brings with it a lot of risks – from losing your ranks on search engines to completely losing parts of your website.
Website migration is a challenging process, and you need a really good reason to take it on.
Reasons to Migrate Your Website
There are various situations that you may face as a site owner where migration is your best or even only option. Let’s go over the most common reasons.
Changing Your Site’s Structure, Navigation, or Design
Reworking your website is not something you should do on a whim. If you feel that your conversions or sales are weaker because of the look of your site or the customer journey, you should first prove it by excluding design or architecture related causes, respectively.
Moving To a New Framework or CMS
Having a website on an outdated platform can be painfully limiting for you and can be disruptive to your audience, which can result in a loss of sales. Choosing a CMS that is right for you is a different topic for another time; there is no single answer as each site requires a specific approach.
Be sure to think about whether moving to a different technology is the only option, and if there is any way you can enhance your current setup to meet your needs.
Adding a Mobile Version
In the age of mobile-first indexing and considering the immense ratio of mobile to desktop traffic, there is no way you are not thinking about optimization for mobile platforms. Still, you should first analyze your audience preferences and find an appropriate cost-to-benefit balance of creating a mobile-specific experience.
Moving from HTTP to HTTPS
Implementing the HTTPS protocol on your website is not only important from a security standpoint. If you don’t have an HTTPS site, it can negatively affect user experience as most browsers will pop up a warning for the unsecured pages.
Although, you might not need to switch your whole site to HTTPS right away; you could start with the pages that store users’ personal information.
Moving To a New Server
If you are not satisfied with your server’s performance or your hosting conditions you may want to switch to another host. Take time to research and find the right host; you don’t want to jump out of the frying pan into the fire.
Changing the Domain Name
You might want to change your domain name due to rebranding or getting your hands on a better URL. But like with any other reason for migration, changing the domain name is a big decision that you shouldn’t make lightly.
Before You Start the Migration
Our interactive checklist contains all of the steps you will need to take for a successful website migration, so feel free to use it as a guide and/or as an outline for planning.
For now, you should remember that the key to smooth transition is careful planning and testing.
These are the basic rules of website migration:
Inform your users that you will be moving your website. Even if you follow all the instructions, your website may still suffer some hiccups here and there, so it would be better to give your audience a heads-up.
Try not to migrate the entire site at once. First, create a test sample of a new site. When you are sure that everything works right, start moving your website piece by piece.
Avoid mixing multiple migration types in a single move. For example, if you want to change your domain name, and switch to a new host, and redesign your site architecture, we recommend you to do it one step at a time.
Migrate during a low-traffic time if possible; this will minimize the impact in case something goes wrong. Plus, a reduced server load will allow GoogleBot to crawl and index your new website faster.
Hope for the best, but prepare for the worst. Website migration is a serious undertaking that has a lot of potential issues and pitfalls. Use our checklist along the way to facilitate the process.
And remember, planning and testing!
- Start the checklist
Here are some stories and tips from the industry experts:
I’m going to talk to you today and give you five tips about performing website migrations, some of the things you might want to look out for. I’ve performed a number of these over the last 20 years and I can honestly say no two are the same.
So let’s have a look. Going straight in at number one, you need to get in there early, as soon as you have an idea that there may be these changes, make sure that you are there and ready to go. The earlier you can get in the better. You’re going to need all the time you can get.
Number two, you have to be prepared for these. The migrations, even the simplest migrations, have a tendency not to go very straightforward. Also don’t underestimate the scale of some of the larger projects and how they may grow, and of course watch out for scope creep.
Number three, make sure you understand the wider changes of the business. There may be other parts of the business that have elements of the website that are under their own ownership. Make sure you understand the impact of the migration on those departments, on those people within the business.
Number four, without any doubt, you need to be organised. I generally start every migration project with a full website audit. This gives you the benchmark, before the audit, that you can use, one you’ve completed, to make sure that you are on track, that your visibility is still up there, and you haven’t missed anything.
And then finally, number five, test, test, test. You need that time to run those tests because as soon as go live comes it'sits probably going to be a straight flip over and you don’t want to find out any scary stuff at that point. I hope those have been some help for you and greetings from London! Take care!
Here’s a story about how migrations can go wrong. I once was called upon a failed migration and they did all they right redirects, they did all the research and everything but still they lost an enormous amount of traffic due to lost rankings.
So the thing that happened in this case was there was an automatic redirect based on the language. It was a Belgian site and they basically either redirected to the Dutch version or to the French version or to the English version but they were all, like, question mark lang is, FR or whatever.
They forgot to redirect all of these pages and as such they’d redirect all of the pages that would come out of a crawler but they wouldn’t redirect the ones that users actually linked to. So just fixing those solved the problem, they regained their rankings within a few weeks.
So, lesson learned, always look at all the pages that get you traffic, that rank, to create your redirects. Thanks!
Here’s another one that I quite regularly bump into, is that people think they can remove redirects the moment Google has picked up on the new URLs or the new domain or whatever it is. You should never be doing that. A 301 redirect is a permanent redirect. That means it needs to stay there. Well, that’s my way of looking at it. Google never forgets, so just keep it there, make sure you redirect everything. Don’t have double hops in your redirects. So if there are old redirects now going to the HTTP version, which redirects to an HTTPS version, which does whatever, make it a single hop, and just a single 301 redirect and don’t remove them after your pages have been migrated.
Ric: So we’re here today to talk about site migrations and times where we work with clients who may not have considered SEO in the process. I once worked with a client who were looking to improve overall site conversion. They were a global client, and had lots and lots of different websites and the new site they had put together was fantastic from a conversion perspective but unfortunately they didn’t really have an SEO team in place and so didn’t consider the channel was as important, or really as part of the planning stage. As a result, when they rolled out the migration, unfortunately the SEO traffic dropped, although conversion did improve. So the net result of that was no improvement at all. Had they considered SEO in the planning stages, and, sort of, looked at how we could work together, this situation could have very, very easily been avoided so a key piece of advice is when you’re planning your migrations definitely consider SEO as part of it.
Harry: And from my perspective, I worked on a large-scale migration in which SEO was almost seen as a step-by-step process of checks towards the end of the migration, well, the different intervals of migration. The end result being there were duplicates of the site based on the technical foundations of the site as a whole. I guess my overall kind of takeaway is that only through having a better integrated team structure as well as working closely together as a team through, kind of, more regular catch ups, can migration can go as smoothly as possible. So that’s my kind of experience as a whole.
When you’re moving from HTTP to HTTPS that’s a challenging project by itself anyway, and you shouldn’t take that lightly. Especially for big websites that have hundreds of thousands of pages. If you follow this train of thought, what you’re going to do is that in the end you’re going to lose rankings, traffic, revenue, and it’s going to take you a lot of time to recover. Instead of that, create a comprehensive playbook for you and your team and for the rest of the parties involved in this kind of project. Divide it into three areas, the technical, the onsite and the post-release. For example, make sure that you’re going to implement 301 redirects, make sure you’re going to update canonical tags, the hreflangs, you update the internal linking, but you’re also going to generate new, xml site map with the old HTTP pages.
Post release, monitor and analyse your server logs, see where Google is spending more time. Monitor and analyse the deindexation of the HTTP pages and the indexation of the HTTPS through Google Search Console. Also, take a look at the organic traffic that you’re attracting, see how it is developing. Ideally, everything should be flat, meaning no negative impact from that but not much positive, at least in the beginning. If you see any kind of abnormalities try to analyse that and figure out the root cause of that.
Well, these are some of my tips and I hope they are going to help you with your migration. Good luck!
The worst situation I ever saw decimated around 90% of the website’s organic traffic (which was in itself 90% of the site’s total traffic). There were several issues here that all worked together to just destroy the site’s rankings:
- Complete change of URL structure
- Loss of all optimization on key pages
- Loss of some key content pieces and pages
- Change of forum software (which itself accounted for around 40% of organic traffic
- Change of URL (shortly after an earlier change)
- Several issues with redirects (domain variations, page level, etc.)
- The loss of a previous domain as it was believed it was no longer needed (yet it held years of equity)
This was just a perfect storm of issues. The redesign process went through two developers. There was a recent rebrand. Quickfire changes in domain names. To top it off, there was the loss of a historic domain (the first one that the site had run on for years).
Ultimately, SEO was just not a consideration until the lights went out. We were not brought in till a month or so after launch, so it was a tricky one to resolve with so many moving parts. It was a charity, so we did the work pro bono, and I believe we got them most of the way back in about 3 months. It was super painful though, and the loss of a historic domain name was something that could not be recouped.
The biggest website migration issues usually come from a switch in the content management system being used — particularly on larger sites. Often there is a completely different URL structure, with hundreds/thousands/millions of pages. Rather than any specific technical issue, I tend to find the size of the site presents the biggest issue.
It can also be problematic when there are several changes at once: new CMS, different URL structure, content changes, HTTP to HTTPS, etc. Each change introduces a new variable and something else to be managed (and potentially messed up). The charity issue above was an almost perfect example of this, and everything was changed at once: content, CMS, forum software, URLs — all of this was done with no consideration for SEO, so untangling the historical mess was nightmarish.
Something worth mentioning: At BowlerHat (my agency), we speak to a lot of small business owners who are concerned about losing site traffic during a redesign. In most cases this is unwarranted. For a typical small business site, using WordPress, and ranking for mostly local commercial terms, migration should be easy. You still have to do the basics, but any competent SEO or web developer should be able to manage this without any major hiccups.
As a golden rule, keep it as simple as possible. Try not to make multiple changes at once. Never change URLs if you can help it. Do the analysis and put clear plans in place as, ultimately, failing to plan is planning to fail.