A website migration is one of the most complex tasks you’ll come across in the world of SEO.
After spending 5 years running a service dedicated to migrations, I found that the same 12 issues plagued the majority of migrations to different degrees. These problems led to decreased rankings and severe traffic loss—the last thing you want when you’ve been planning a migration for months.
The good news is that a lot of this risk can be mitigated through diligent planning. Let’s dive into tips for avoiding common problems and how to make adjustments that will protect your traffic and ensure a successful migration.
12 Common Website Migration Pitfalls (and How to Avoid Them)
Migrations come with a fair amount of risk and can cause unexpected problems if you are not well prepared for the task.
Here are the 12 most common migration problems to avoid:
1. Changing Content
When undergoing a migration, Google needs to process a lot of information. If you’re also changing a significant amount of content at the same time—whether by removing it fully, trimming it or editing it in other ways—you provide yet another factor that Google needs to account for. Even when you’re not doing a migration, content changes can have dramatic effects, but making these changes during a migration is a near guarantee that disaster will follow.
We recommend holding off on content changes until after a migration is completed in order to separate the events. This makes it much easier to diagnose why traffic may have dropped (if it does). If you can’t stop content from changing, keep copies of all of your content so that you can restore it if needed.
A Note on Changing Titles/H1s
Page titles and H1s can have a big impact on rankings, so it’s best to leave these alone (barring minor changes) to make sure they don’t contribute to rank loss.
My Experience With This
During one of the migrations I handled, content was changed during launch, even though we were told it would not be changing. Rankings dropped immediately. Once we found backups of the content and had it brought back, rankings were restored and traffic quickly recovered.
2. Changing Menu Navigation
Links included in the menu navigation tell Google which pages you consider most important. When you change your menu navigation, you’re telling Google that some links are no longer important, and when you add new links, you’re telling Google you have additional, newly-important pages. With a migration, it’s best to change your top navigation as little as possible. It is another major change that could cause traffic loss.
Technical Tip
Another aspect to be aware of is how you change your menu linking from a technical standpoint. You want to have hard <a href> links at all times, preferably in the source code of the page or at least prerendered. If you rely on JavaScript rendering to build out navigation and it doesn’t get rendered by Google (a rare occurrence), you’ve essentially stripped out your menu navigation entirely. Additionally, converting links to JavaScript onClick links, or links that only show on user interaction will also suffer as Google can not crawl or see those links.
My Experience With This
During one migration, a mobile site was redirected to the main responsive site in order to clean up the old m.dot links. During the migration, the menu was changed to utilize user interactions to show all mega menu links. While the links remained the same, Google no longer saw them in the menu. Traffic dropped by about 30%. The menu was never fixed and was in place years later. The site’s traffic did not recover.
3. Significantly Changing Internal Linking
Changing your internal links can change how internal link equity flows throughout the site, meaning those pages that lose internal links may rank lower on the search results page. This often occurs when you start pruning pages, adding new categories, and changing old categories. We recommend that you stick to a similar link structure if possible. This will usually be one of the more difficult parts of a site to maintain, but it is worth it.
4. Changing to a Heavy JavaScript Framework
The majority of sites are already on or are moving to JavaScript frameworks. While JavaScript offers a lot of flexibility, it does come with its own set of potential problems you need to factor in.
Technical Tip
The primary issue with a JavaScript framework and a migration comes down to content rendering. If you are moving from server-side rendering (the server generates all of the content and sends it to the client) to client-side rendering (the browser runs JavaScript itself and pulls in the content), then you want to have some form of rendering solution in place, such as prerendering, static rendering or hydration. (Read a full explanation of these methods.). This will help ensure that Googlebot is able to get the full content of the page without relying on its own rendering services. While Google does a good job of rendering JavaScript, typically within minutes of crawling, it can get things wrong and it’s important to offer up your own version of the correct page.
My Experience With This
During one migration, a site was moved over to a JavaScript framework and entirely converted to client-side rendering. While pre-rendering was advised, it was not put in place. Google rendered the <body> content but never rendered the menu. While there were other issues at play with this migration, including moving to a subdomain on a new CMS, traffic still took a dive by around 25%. While these days Google renders content seemingly immediately, it’s still something you want to take control of if possible.
5. Incorrect Redirects
Incorrect redirects occur when pages are redirected to a page that is not a relevant match. This most often occurs when pages are redirected to the homepage. When this happens, Google often discounts the page and the link equity does not pass through.
When redirecting, it’s best to always find the closest match. If you cannot find a close match, redirect up a level. For instance, a subcategory should be redirected to the parent category.
6. Phased Migrations
Google has said that phased migrations are not an issue, but I’ve rarely seen them work. I don’t think it has anything to do with Google, but it does have a lot to do with the complexity of adding a second framework or CMS.
The main issue I’ve seen during a phased migration was things slipping through the cracks. Dev teams have to manage two systems, which makes it difficult to stay on top of every detail.
My Experience With This
In one instance, a Canadian site was moved into the US site with a new subfolder structure, but the US site (which was to be converted to the new URL structure in the next phase) did not have its href lang tags updated to account for the changes. This led to the US site replacing the Canada pages in the SERPs and led to traffic loss.
7. Incomplete Staging Sites
All too often, staging sites are not a good representation of the final site. Content is not fully added, code is not fully deployed, some of the URLs haven’t been moved over, etc.
This makes it very difficult to fully determine what’s at risk and what isn’t. As time goes on, a staging site should begin to mirror the live site more and more accurately, which makes it much easier to determine if there are wide-scale issues or if something is just a staging issue.
8. Staging Leftovers
Unfortunately, it’s common to experience ‘leftovers’ from a staging site. This happens when a site gets pushed live from staging, but elements of the staging site remain present on the live site, such as canonical tags pointing towards a staging site url or when internal links on the live site end up pointing towards the URLs on the staging site. Luckily these hiccups can be caught pretty quickly, but it’s not a great way to start a migration.
My Experience With This
It was months after a bumpy migration that had finally recovered when a former client reached out over sudden traffic loss. Someone had accidentally pushed staging to the live site and updated all of the links to point toward staging. These links were blocked by robots.txt, and the site’s traffic plummeted. Even after a migration is considered ‘done,’ it’s important to be aware of changes that occur in the months afterward. If possible, you should let your traffic settle down for a period of time before any major changes are made just to make sure we can accurately identify the cause of any drops or improvements.
9. Unnecessary URL Structure Changes
URL structure changes are the core of a migration. Sure, a redesign or a CMS change is also a migration, but if the URLs stay exactly the same, it doesn’t need the same type of effort that goes into properly redirecting a high volume of URLs.
That said, one thing that happens on occasion is unnecessary URL structure changes, such as switching from non-www to www, adding en-US to the slug, or even just removing a subfolder because someone no longer liked it. All of these changes result in unnecessary redirects. While some of these may have a good reason behind them, you should not change URLs unless you absolutely need to.
10. Rollbacks
This problem is rare, but it’s worth mentioning. Depending on when you do a rollback, you might end up losing out on redirects or other fixes.
The problem with rollbacks occurs when fixes that were made after the site was initially launched get removed because a rollback occurs. When this happens, those fixes need to be applied to the site again. While this does make sense and the rollback is functioning as it should, it also means that some fixes or actions may slip through the cracks.
Don’t forget to check other aspects of the site that may not come to mind immediately just to make sure everything is working as it should. To give a real-life example, on one occasion a rollback needed to be performed a few hours after the launch had happened. However, when the rollback was performed, all of the redirects were missing from the site, which would have resulted in significant traffic and rank loss if it had not been caught.
11. Old Robots.txt
This isn’t as big of an issue when you’re moving to a CMS that has an established robots.txt that preemptively blocks URLs that Google doesn’t need to access. However, if you’re using a CMS with a fairly basic setup, or you’re essentially creating your own CMS, you need to be thinking of the types of URLs that should be blocked. Ask yourself:
- Are you going to carry over some of the same URL structures to the new platform?
- Are you using the same parameter tags?
- Did you create new parameters that aren’t blocked in robots.txt yet?
My Experience With This
I’ve seen cases where hundreds of thousands of pages were crawlable due to faceted navigation that shouldn’t have been crawlable, or websites that have 10,000 URLs showing 10 million+ URLs to Google because a robots.txt file was never set to block certain URLs. These sorts of issues can quickly cause problems for a website and it’s much easier to handle before you launch than after the site is already live.
12. Untested New Features
Beware of adding new features or scripts that have not been tested into the live rollout of the migration. While it’s rare, on occasion I have seen developers deploy scripts that were not part of the staging site or the original live site and could not be tested. On launch day, the scripts injected noindex tags and Google grabbed them, resulting in some important URLs being dropped from the index until the code was removed.
While you can sometimes quickly identify the culprit, that isn’t always the case. Always make sure to test your scripts and features beforehand so that any issues can be resolved quickly. If you can’t test it before, it’s best to wait a bit after the migration has launched in order to make sure an issue doesn’t get lost amidst the other aspects of a migration launch. And if you must launch something new on the day of the migration, alert your SEO team ahead of time so they can account for it and check to make sure no issues have arisen as a result.
Saving Grace: Google’s Grace Periods
After covering all of these pitfalls, one thing to highlight is Google’s grace period. On occasion, one of the issues above would happen. Usually, it was some sort of leftover issue from staging, mostly around canonical tags, maybe a few noindex tags, etc. What I typically saw was that the site would not drop like a rock in rankings (though some changes did cause those results). It might have taken a couple of days to fix the issue, but I didn’t see a significant downturn. I’ve talked with other SEOs who have seen similar results as well.
I mention this only to help calm any migration nerves. If you see an issue, try and get it fixed quickly, but know that not every issue is going to cause an immediate downturn. A good SEO should also help you properly prioritize issues so you know what needs to be fixed now, and what can wait.
By watching out for these migration pitfalls, you’ll help remove a lot of the issues that would normally cause a lot of damage, and you’ll help safeguard the traffic and rankings you’ve fought hard for.