Most of us are aware that changes to your site pose a risk to your rankings – and a site migration is the single biggest thing you can do to risk it all in one go.
The term ‘migration’ is thrown around quite a lot, but I tend to define it as: “any significant change that would require a reassessment of a site by search engines.”
This can include everything from content and design changes through to alterations of URL structure, switching to HTTPS, or moving domain completely.
I advise against changing any more than two of the above at any one time, otherwise the risk increases significantly. You will be required to have a range of fall-backs in place, which will increase the required preparation time and the number of developers you need on hand in the weeks following the migration.
Over the last 18 months, I have been involved in dozens of site migrations at various different points, and the most challenging ones to fix usually have one (or more) of these issues:
1. Adding a 301 redirect to your historic robots.txt file
You’re migrating your site and your SEO says you need to redirect everything, right? Wrong!
Search engines that are typically used to encountering a robots.txt file on your site will avoid crawling your site if they find that it now redirects. This is bad because it means all the redirects you have put so much thought into will not be followed by search engines because they aren’t visiting those pages, out of fear of crawling something they shouldn’t be.
Over time, the redirects will eventually be followed. But I have seen instances where this takes three to four months and the visibility of the site never reaches the height it would have if the redirect on the robots.txt was not there in the first place.
2. Lack of understanding of the existing value within the site
Knowing what you stand to lose and what you can afford to lose is hugely valuable. Not all pages are created equal, and knowing what’s important means you won’t be leaving behind any equity that was helping your current site to perform.
Make sure you understand:
- What drives the revenue for your site
- Where search engines see value
- What pages have links
- Which content engages users the most
This way, you will know what sections and pages are worth your time when it comes to redirecting or recreating.
It can also help generate buy-in when you ask for more development time or request the deployment to be delayed by a week so you can get everything sorted because you (the SEO) wasn’t brought into discussions earlier enough (more on that later).
3. No awareness of historic domains redirecting into your existing one
I have seen several variations of this over the years, with businesses that owned multiple domains and unknowingly pointed one with a manual action at their main site (yes, that really happened).
The resulting fallout was significant, and removal of the manual action on the redirecting domain was only half the issue, as the main site was caught by Penguin as a result.
As recently as March 2018, I have seen businesses fail to check what they are redirecting into their site and visibility has gone backwards rather than achieving the hoped-for improvements.
This point and point 2 on this list are always caused by the next point.
4. Bringing an SEO into discussions too late
Businesses have gotten in touch with us after the damage is done, meaning we need to take action to reverse the issues. This isn’t always the case – I’ve also been involved in discussions from day one.
The latter is (obviously) preferable. While it’s highly likely that the SEO won’t have the most to say in those early meetings, over the course of several meetings you’ll likely notice that your SEO can steer other teams around potential issues (such as points 2 and 3), which otherwise would have been missed had they not been in the room.
It also helps to have someone to rein in those who want to change every detail, from URL structure to on page content and meta data, without considering the organic impact.
5. Forgetting about Search Console access consolidating Disavow files
This isn’t necessarily something that is going to make your migration a success or a failure, but rather a word of caution. Just because your old site no longer exists, it doesn’t mean your old Search Console profile is redundant.
Not only will it have historic data that may come in handy for comparisons in the new site’s first year, but I have seen instances of Google communicating with webmasters through the original GSC profile and not the new one. This is more common when the site has moved from HTTP to HTTPS.
I have also seen sites with manual actions for spammy structured mark up or security issues where messages will persist within Search Console’s “manual actions” section in the HTTPS version of the site, despite having a separate message confirming removal of the manual action.
Only when the reconsideration request or request for a review was submitted through the HTTP profile were the messages completely removed. Pedantic? Yes, but your client or boss will be thankful you removed any messages in the site’s Search Console that are bringing bad news from Google.
Finally, something that should be par for the course – move the disavow file over from your old domain to your new one, because that can prevent the depressing visibility graphs you will see if you make the mistakes in point 3.
