How often have you heard webmasters say they want to migrate their site from WordPress to another CMS or even move their entire blog over to a new host? The problem is that many times these migrations don’t go smoothly and result in lost traffic and revenue.
Migrating websites isn’t always easy. There are several reasons why migrating sites can be challenging. One reason is because migration requires a lot of time and effort. Another reason is that some platforms require specific skill sets to perform well.
There are three main types of migrations: moving from one platform to another, moving from one hosting provider to another, and moving from one domain name to another. Each type has its own unique challenges and pitfalls.
The following includes some of the most common website migration mistakes we have run into while examining other website migrations.
You Fail to Prevent Robots from Crawling While in Development
Robots.txt files are used to control how webcrawlers access a website. A robots.txt file tells the webcrawler which parts of a website it can and cannot index. This prevents spiders from accessing sensitive information such as login credentials, payment data, etc. However, many developers fail to properly set up their robots.txt file, allowing webcrawlers to access their production website while still in development.
If you’re hosting your website on GitHub Pages, you might think that your robots.txt file controls everything. But, in fact, GitHub Pages does not support robots.txt files, and therefore, allows webcrawlers to freely access your website.
Even though you’ve taken measures to protect your website during development, it’s possible that webcrawlers could find ways around your security measures once your website goes live. In addition, bots can sometimes bypass robots.txt files altogether.
To avoid having your website crawled by webcrawlers, you must block access to the entire website via robots.txt. When you do this, webcrawlers won’t be able to access your website at all.
Otherwise, you might run into the issue of webcrawlers indexing the wrong files from the wrong type of site.
You Fail to Allow Robots Access After Site Goes Live
The fact that you’re launching a new website doesn’t mean that you’ll be able to start getting traffic immediately. In fact, there are plenty of things you need to do before even thinking about how people will find you. One of those things is updating your robots.txt file. If you don’t allow access to your site, no one will be able to index it. This is especially important if you’ve been working on a new project for months, and now you want to make sure it gets found.
If you’ve been building a new website, you probably haven’t updated your robots.txt file yet. And if you have, you might have forgotten to make sure that indexing has been turned on. If you haven’t, this is not a big deal to fix. Just make sure the following line is included in robots.txt: “Disallow: ” with a space and without the quotes. If you include the line “Disallow: /” with the slash, you just told Google to deindex your entire website from the root folder on down.
You Remove Existing Disallow Rules too Fast
Of course, the new website doesn’t get indexed (oops!) because you forgot to update your robots.txt file. If you don’t allow access to your site via robots.txt, you’ll lose traffic. Your visitors are likely to find something else to do while waiting for your site to load. And what if the new website gets hacked? Visitors could see malicious code on your site that might infect their computers.
You wouldn’t be the first person to forget to update your robots.txt file when a site launches. In fact, we’ve seen plenty of examples where people didn’t realize that their sites were inaccessible until months later. So why did it happen? Well, there are lots of reasons:
- Launch day is always hectic.
- There’s no way to predict how long it takes to build a new site.
- Launching a new site is exciting.
- You’re excited about the new site.
- You’re working on another project.
- You’re distracted by other projects.
- You’re busy with life.
- You’re tired.
- You’re stressed out.
- You’re overwhelmed.
- You’re running late.
- You’re afraid someone else will beat you to it.
- You’re too busy to worry about it right now.
- You’re lazy.
- You’re not interested in SEO anymore.
- You’re not interested enough to care.
- You’re not interested at all.
- You’re not paying attention.
- You’re not concerned.
- You’re not worried.
We get it. Things happen. But, as soon as something like this is discovered, it’s paramount to make sure that you fix it as quickly as humanly possible, before catastrophic errors occur.
You Fail to Take Existing Redirects Into Consideration
We know we should do as much page-to-page redirection as possible during a migration, but what is and should be the main focus? And what about the importance of existing redirections? Should we prioritize redirecting from the current site to the new one, over redirecting from the old site to the new one? Or vice versa?
Redirecting from the old site is usually done to avoid breaking any links pointing to those pages, while redirecting from the new site is usually done to prevent users being redirected away from the new site. However, there are some exceptions. For example, you might want to redirect from the old site to a specific page on the new site. In this case, it makes sense to redirect from both sites to the same URL.
In addition, redirects from the old site to another domain name are often done to prevent users being directed to the wrong place. This happens because sometimes domains change hands, and the new owner does not want to link to the old site anymore.
But what about redirects from the old to the new site? Do they matter? Yes, they do. They are used to consolidate internal links and make sure that no broken links exist. You must take care of these redirects, otherwise you could end up creating redirect chains – something that is very hard to undo later on.
If you don’t keep track of these redirects, you risk having old pages pointing to outdated URLs, which leads to 404s (or even worse, HTTP 500 server error pages) when someone tries to access them.
You Didn’t Back Up Your Current Site
Ensure that you are backing up the current site and database regularly. This will be helpful in the event of a disaster, so that in case anything unexpected happens, you still have all the original files and content, and don’t lose access to your data.
If you don’t have a backup, and something goes wrong, it could cause significant delays and issues with repairing the problem.
You don’t want to inadvertently cause hiccups in a project because of the lack of a backup of your site.
This is why it’s always important to take care of backups because they can mean the difference between the success or failure of your project.
You Did Not Double Check All URLs
Migrating a website isn’t always easy. There are many moving parts involved, including changing URLs, updating meta data, and making sure everything is set up correctly. If you don’t take care of those small things, there could be some major issues down the road.
We see this scenario often in our work. One of our recent projects included a WordPress migration for one of our clients. We had been working for months on getting older URLs to redirect to the new ones. But, something went wrong during the final push to migrate the site.
As part of the project, the developer flipped the switch to make the new site live, and the site landed on a new domain name. This caused problems for the SEO team because they weren’t prepared for the change.
The SEO team scrambled to fix all of the little things that needed fixing, such as updating the meta descriptions, adding rel=”canonical”, and setting up the canonical tags. These are all important steps to ensure that the SEO is set up correctly. However, when the client asked the development firm (who did the actual coding) to flip the switch and move the site over, they didn’t communicate this information properly. As a result, the SEO team was left scrambling to find out how to handle the situation.
There are plenty of reasons why migrating a website can cause headaches. You want to make sure that you’re doing everything possible to avoid these types of situations. Here are three tips for avoiding migrations gone awry:
1. Double Check All URLs
This seems like common sense, but it’s amazing how many times we see companies who have migrated their sites without double checking all of the URLs. It’s really important to verify that your URLs match what you expect them to be before you flip the switch. Otherwise, you might end up with broken links or duplicate content.
If you’re using a third party tool to do the migration, make sure that you’re not accidentally flipping the switch while you’re trying to test the URLs.
2. Make Sure Your Website Migration Application Is Up To Date
If you’ve got a lot of plugins installed on your site, then you need to make sure that your migrator is up to date. The last thing you want to do is run into any compatibility issues after you’ve already made the switch.
3. Test Everything Before You Flip The Switch
It’s tempting to just flip the switch and hope for the best. But, if you’re going to go through the trouble of migrating a site, you should definitely test everything first. That way, you won’t waste time later on figuring out that there were some errors along the way.
You Did Not Seriously Consider Keeping Your Domain Name
If you have built equity in a domain name, it might make sense to hold onto it rather than switch platforms and lose everything. This is especially true if you are planning to build out a site or launch a product. You don’t want to start over and lose what you already have invested in your brand.
But if you do decide to move domains, here are some things to think about:
- Make sure you know exactly how much traffic you lost. There is no way to recover lost traffic once it has been converted to another URL.
- If you plan to change URLs, make sure you contact an SEO agency ahead of time. They can help you determine whether or not you need to change anything else besides the URLs.
- Don’t forget about the keywords you used to rank for in the old URL. Search engines like Google and Bing still use those terms to index your content.
- Finally, if you want to rebuild your rankings quickly, focus on creating high quality content. Content marketing is one of the best ways to gain traction again.
Migration isn’t always easy, but it doesn’t have to be complicated either. By following these simple steps, you can ensure that you don’t get stuck with a botched migration through the simple act of neglecting your domain.
You Accidentally Created a Bunch of Duplicate Content
Duplicating content is never a good idea, especially if it happens during a migration. If you migrate your site from one platform to another, there are many things that can go wrong. One of the most common issues is duplication. When moving your data from one system to another, sometimes the process itself creates extra content that needs to be manually deleted. This isn’t necessarily a problem—it just means that you need to make sure that you don’t end up with duplicate content.
You might think that you’re doing nothing wrong when you move your content from one site to another, but Google doesn’t see it like that. They assume that anything copied from one source to another is plagiarism. So, even though you didn’t copy the content yourself, if you do something similar to what someone else did, you run the risk of being penalized.
The best way to avoid this situation is to make sure that you aren’t copying content from one place to another. You can use tools such as Copyscape to ensure that no one else has taken credit for your hard work.
You Did Not Vet Your Professionals
We were recently asked about our best advice for people looking to move their businesses online. There are a few key points we think are important to consider when choosing the right platform and professional to assist with your migration.
1. Do Your Research
The old adage “you get what you pay for” holds true here. You want to ensure that you’re paying enough to receive the level of support that you desire. This starts with doing your research. Find out what platforms your potential partners work with and how many clients they’ve migrated successfully. Ask questions about their experience and expertise. What do they offer that no one else does? How long have they been providing migrations? Is there a guarantee that they’ll complete your migration within a certain timeframe? These are just a few things to ask yourself.
2. Choose a Certified Partner
If you don’t know anyone who works with the platform you’re considering migrating to, look to see if it’s part of the Certified Partners program. Most major platforms have a set of prerequisites that must be met before being accepted into the program. In addition to meeting those requirements, the vendor must provide documentation showing that they are able to handle migrations of similar size and complexity. They also must agree to abide by the standards and guidelines set forth by the Certified Partners Program.
3. Make Sure They Have Experience With Your Industry
This ties directly into the first point above. A good way to gauge whether or not a provider has the right skillset is to check their portfolio. Look for companies that specialize in migrating specific industries. Are they familiar with your industry? Do they have experience with the same type of software you’re planning to use? If not, how well do they communicate with each other? Can they explain why something might be difficult to implement during a migration?
4. Get References
It’s always smart to get references from previous customers. It will give you an indication of how satisfied they were with the service provided. But, more importantly, it will help you determine if the company is trustworthy. The last thing you want to happen is for them to take advantage of you after you’ve paid them thousands of dollars.
5. Don’t Be Afraid To Negotiate
There may come a time where you feel like you need to negotiate a better price. While it’s never fun to haggle over money, it’s worth it to save some cash. However, keep in mind that you should only negotiate if you truly believe the price is too high. Otherwise, you could end up losing business because you didn’t go through with the deal
You Did Not Cushion Your Timeline
Setting a timeline is always tricky. You want to set one up that allows enough time to do everything you need to do without being too ambitious. But it’s important to allow some wiggle room, too, just in case something unexpected pops up along the way. Creating a timeline can help you keep track of what needs to happen next, and give you a sense of where you are in the process. And having a timeline helps you see whether you’re moving quickly or slowly toward completion.
First, make a checklist of things to be done. To start, list out every project you need to accomplish, including any necessary approvals, training, etc. Next, estimate the timeline for the items on the checklist. Start with the shortest tasks; the ones that take the least amount of time to complete. Add padding—a couple of extra days per task—to account for unforeseen delays. For example, if you know you’ll need to train someone on a certain function, add a day or two to your timeline to account for that.
Once you have a rough idea of how long each task might take, break down the timeline into smaller chunks. If you have three months to finish a project, for instance, you could divide that into four parts: six weeks for the initial design phase, 12 weeks for development, eight weeks for testing, and four weeks for deployment. This gives you plenty of time to work on multiple projects simultaneously, while still allowing you to meet deadlines.
Keep in Mind the More You Change on a Site, The Harder it is to Diagnose a Traffic Drop
If you’re trying to figure out why some traffic dropped off after a major change, you might want to take a step back and look at how much work went into getting there in the first place. A lot of times, people try to diagnose what caused a drop without taking into account the amount of effort required to get to that state. Sometimes, it takes months or even years to put together a site, and once you’ve done that, it’s hard to tell whether something changed overnight or whether you just got lucky.
To help illustrate this concept, we pulled data from three sites that experienced drops after making a big change. Each of those sites had been working steadily for several years prior to the decline. Then, one day, everything changed. Here are the steps we took to determine what happened:
Step One: Identify When Traffic Dropped Off
We looked at our web server logs to see when traffic began dropping off. In each case, the traffic declined over a period of days. We also checked our analytics data to confirm that the traffic drop coincided with the date the site went down.
Step Two: Figure Out How Much Work Was Required to Get There
Once we knew the exact dates of the traffic declines, we set about examining how long it took us to build those sites. For example, let’s say we wanted to compare the number of visitors coming from a particular source before and after a redesign. To do so, we’d pull data from Google Analytics and use it to calculate the average daily visits per visitor.
Using the graphs from Google Analytics, it’s possible to identify where the drop occurred. But keep in mind that if you change a hundred things on a site at once, it could become much harder to diagnose that drop.
Be Sure to Push Back and Delay a Launch if Critical Issues Are Present
Migrations are bumpy. They often take longer than expected — sometimes much longer than expected. And when you add multiple factors into the equation, like technical glitches, security vulnerabilities, and legal concerns, it makes things even more complicated. But there’s no reason why you shouldn’t push back and delay the launch of a migration if critical issues are present.
If a site is going to go live despite the problems, make sure to let your clients know about the potential fallout. You don’t want to find yourself scrambling to fix everything while simultaneously trying to explain to your client how the issues could affect his or her business.
The migration process can be a stressful one. But it doesn’t have to be. There are ways to mitigate some of the risks involved. One way to do this is to plan ahead. Not only does planning help you avoid problems during the actual migration, but it gives you time to address those problems before launching.
A good example of this is one migration we did when we migrated a client who had an e-commerce store from Magento to Shopify. Our team had already begun working on the migration, but things weren’t progressing smoothly. We knew there were several critical issues that needed addressing prior to launching. So we pushed back the launch date twice, giving us plenty of time to fix the bugs and iron out the kinks. In fact, we even moved the launch forward again because we wanted to ensure that everything was ready to go.
Nothing is ever set in stone, and having a fluid and adaptive mindset will help you prepare for any issues that may come up along the way.
In addition to planning ahead, another thing you should consider doing is testing the migration as early as possible. If you’re using an automated tool for the migration, you’ll need to test it first. Otherwise, you may end up having to manually migrate your entire database. The earlier you start testing, the less risk you run.
Finally, remember that migrations aren’t just about moving databases around. They also involve making changes to code and other aspects of the website. Make sure you’re aware of all of these steps. It will help you avoid any surprises later down the road.
Do Not Launch During a Google Update
Google’s algorithm changes are often accompanied with traffic changes and losses (even though you may not have ever changed anything on a website). This makes diagnosing issues harder, especially since there’s no way to know exactly what the change will do until it happens. When Google pushes out a large update, such as a core update, it typically takes several weeks for everything to stabilize. During that time, many businesses are still trying to figure out whether they’re affected.
If you launch a migration during a Google update, this will make it even harder to understand exactly what caused a drop, and you won’t be able to identify such issues successfully. As a result, you could lose traffic while you are working to identify what caused the drop in the first place. The best scenario is to make sure that you launch a few weeks before a suspected Google Update, so that you can have enough time for the site to be live, and then you can ensure that you will experience the effects of that update.
You can also monitor your site’s traffic patterns to help you understand why certain queries are taking longer than others. For example, if you notice a spike in traffic around the same time that you start noticing delays, you know something is wrong.
Finally, you can push back the launch date for your site if needed, so that you can time the launch properly. Of course, if you’re already launching, the sooner you can resolve the issue, the better.
A Site Migration is Never Easy
Site migrations are full of pitfalls that can happen. And, there usually isn’t a fully error-free site migration. Those are tough to attain.
But, if you work on going through your checklist with a qualified company, a site migration can be even better than it usually would.
This is because, in addition to having yourself, you have the qualified eyes of someone else keeping an eye on your own site migration.
This can be worth a lot of money in the long run.
By making sure that your site migration is taken care of, you reduce the risk of committing many of the mistakes shown here.
When is your next website migration?
