Top 10 Site Migration Mistakes

A thousand calculations, disclaimers and warnings, a brief consideration of alternative careers. This is what runs through my head every time a client mentions to me their desire to migrate their website. On the face of, a website migration is an exciting time. It's a chance at a new 'look and feel', the result of a business merger or simply a rebrand. It's right to get excited. It's also right to worry just a little bit.

Small tweaks to a website can have a significant or little effect on it. So imagine what something as massive as a restructure or domain change can do to your chances of ranking well. The search engines have to get to grips with what's changed and understand how these affect the site's relevancy to search terms. Your website's rankings will fluctuate, there will be a period of uncertainty. Panic will threaten to take over. However, it doesn't have to be so fraught with danger.

Below, I've listed ten issues with website migrations that can be avoided, and as such, increase your chances of a smooth migration. Even if you are not managing a migration currently it's worth taking heed, you never know when you might hear those fateful words, 'we're thinking of redesigning our website'.

1. Not Realising You're Migrating a Site

Probably the greatest risk to the organic traffic during a website migration is the parties involved not even realising it is a website migration. The project might be design-led, a 'reskin' of the site. It might simply be the change of a few URLs. It is easy to see why this could slip the attention of the person in charge of the organic search success of the site.

If we look to a definition of a website migration it might clarify what changes on a site warrant this level of caution. I would be so bold as to say a website migration is any change to parts or all of a website's structure, content or code that impacts the search engines' understanding of the site and its relevance to search queries. This can mean simply redesigning the look of your product pages could fall into a 'site migration' category. In fact, I recently had a client mention in passing that they are changing the look of their top-level category pages and the calculations, disclaimers and warnings started running through my head. A redesign of a page can in practice mean the stripping out of copy, changing of internal links and the addition of code that slows down the load speed.

Changing the URLs of some pages should only be done if absolutely necessary. Google's John Mueller recently responded to a Reddit question about country-specific targeting with this comment:

So, redesigning the look of a page, changing the URLs (even with redirects) and internal linking of a site can all have an adverse effect on a website if not properly considered. This brings me on to mistake number two.

2. Not Weighing the Risks

Website migrations are usually brought about because of a business decision made high up in the company by someone a step or two removed from the day-to-day running of the digital assets. Therefore, the implications of website migration are sometimes not fully realised or weighed. It's long been held that 'a website migration will result in a loss of traffic', I have been guilty of saying that to clients in the past. Although it's not at all guaranteed that traffic will be lost during the precarious time, it is a risk. It's something that everyone in the decision-making process should be made aware of. Mistake number two is not weighing the risks against the potential gain.

Sometimes a website migration is unavoidable. If a brand name is changing then a domain name may have to reflect that, similarly if two companies are becoming one then their websites might have to merge also. Other times it could be postponed or made a lot simpler. Which takes me seamlessly to mistake number three.

3. Not Deciding on a Migration Plan

With the risks apparent it is crucial that everyone involved in the migration is singing from the same task list. There are many people and processes involved in moving a website, whether just a redesign of a few pages or a whole site moving to HTTPS. Consequently, there needs to be a person running the show. This usually falls to the project manager if a website is being entirely rebuilt but smaller budgets for smaller projects can result in no one person being put in charge. It is therefore crucial that someone is appointed the designated 'getter of things done' so there is easy communication between the parties involved, deadlines are met and any issues raised are dealt with.

It is also essential for an SEO specialist to be involved right from the beginning. It is our job to point out any problems with initial designs or plans that could result in a loss of search engine visibility for the site. If the SEO is given sight of the project too late, or is only involved at the stage where redirects are being mapped, then the migration is on track to be a failure.

There is a lot of pre-planning that needs to go into a successful migration. I have personally learned it is better to be annoyingly involved at the beginning of migration than frantically scrabbling to save a botched one that has already happened.

Be proactive in setting a migration plan and make sure it is achievable by all concerned. Every step needs to be fully understood by, and communicated to, all parties. That way there is less chance of crucial steps being missed and every person involved gets the opportunity to lay out their best way of achieving the result. Ah yes, the most important part of deciding on a migration plan, what is the desired result? A successful migration is an obvious answer but what does that look like to each party? For an SEO it will be the changes occurring with no loss of traffic or visibility but that might need to be broken down into components for all to be on board with reaching that goal.

4. Migrating at the Weekend

I understand why, I really do. Migrating your website at the weekend sounds like a great idea. Especially if you are in the business to business industry and that is when you have your fewest visitors to the site during a week. But think about it, what actually happens on launch day? Is it as simple as the pressing of a button which a developer can do in their pyjamas from home? Sadly not.

By now you will have realised from setting your migration plan that launch day is actually a very critical time to the success of the migration. Although it makes sense to launch on a day when you see your lowest traffic levels in case something goes wrong and the site goes off-line for a small period. But that is the exact issue – if something does go wrong and the website is offline for a small period of time, who is around to fix it?

For my part, as an SEO, there are a lot of checks that I want to go through before I sign-off on the website migration. Many of those have to be conducted just prior to launch lest a last-minute code or URL update renders my previous checks obsolete. I, therefore, want to be fully present and focused on launch day, not finding out about an issue two days later when I'm back in the office after the weekend.

It is never a good idea to migrate a website at the weekend or at the end of the day, unless you have a dedicated staff working 24/7 (which I advise against for their health and sanity!). It is much better to launch near the beginning or middle of the working week and early in the morning. This gives everyone the opportunity to carry out their own checks and sufficient time is left over before close of business for the post-launch checks to be conducted.

5. Not Liaising with the Development Team

One problem I have seen happen too many times in a website migration is silos forming between the teams involved. Everyone needs to be communicating and on-task for a website migration to be a success.

Critically to the SEO success of migration is the organic search team and the development teams working together to ensure the structure, code and functionality of the site is well set-up to encourage SEO growth and not a failure. This isn't always easy if the SEO and development teams sit in different agencies or are very separate within the company. That's another reason why appointing a project manager and setting a migration plan are crucial. They should aid in ensuring these two teams are able to work successfully in tandem.

6. Updating References in the Code

A common issue that can go undetected, especially when URLs are changing, references to resources within the code not being updated. This can prove particularly problematic with canonical tags. If your website has changed domain or URL structure, then canonical tags within the site need to be updated too.

If Page A is redirected to Page B during a site migration but the code on the new Page B still references Page A in the canonical tag the signals to the search engines are conflicting. Which is the primary page that needs to be indexed? So whenever a site is about to launch you should crawl it to look for any references to the old URLs. Sometimes there might be internal links to the old pages that are now 301-redirecting to the new URLs that can be updated to point straight to the new URL, or there might be a link that has been added whilst the site is in build that points to the staging site. These are all issues that can be picked up and rectified quickly but the checks need to form part of your migration plan.

Update references in your code such as canonical tags to the new URL address.

Don't forget that a change in your website's code could result in your Google Tag Manager container being removed from the site, or worse still, Google Analytics tracking being deleted. That is going to cause a long-term issue with monitoring the success of your digital campaigns but will also cause problems in diagnosing the health of the migration. Make sure your tracking codes survive the move.

Hack. To make a quick check of tracking codes implementation you can use scraping function in Netpeak Spider. Select a regular expression search and add the following values:

• (GTM-\w+) – to track the availability of GTM code.
• (US-\w+) – to track the availability of GA code.

After crawling, you'll see spotted GTM and GA tracking codes on crawled pages.

7. Not Redirecting All the URLs

You might be nodding your head knowingly at this point. Redirects are usually top of your to-do list when planning a website migration and you may already be searching for 'site:[yourdomain]' in Google and Bing to see what pages they have indexed. You may even be looking over the past 12 months of organic search data in Google Analytics to see which pages received traffic. How about a crawl of your website mimicking more than one search-bot – already on your list? Well done.

However, a set of redirects that often get forgotten are the existing ones. Remember that URL from last year that you changed? No? Well, the risk is that you may have a whole history of redirects in place one of which resulted in Page A being redirected to Page B and then to Page C and now you are planning on redirecting it to Page D. That's forming quite a chain for the search engines to keep up with. What if, by some coincidence, Page D's new URL structure is the same as Page A's was? You'll end up with a redirect loop.

I consider it a mistake to ignore your previous redirects. If you can get hold of a list of the redirects already in place you can update them to remove any chains or prevent possible redirect loops.

Check existing redirects on your website using our website spider software to make sure you don't cause any redirect chains or loops.

Hack. The crawler can make your life easier when it comes to finding redirect issues. Using Netpeak Spider you can find such issues as broken redirects, endless redirects, max number of redirections, redirects blocked by robots.txt, redirects with ad URL format and redirect chains. Also, you can export issue reports to quickly fix redirect issues.

To export various reports, you need to subscribe to the Netpeak Spider Standard plan, where you can also check for 100+ SEO issues, scrape websites, segment and filter data, save projects, and much more. If you are not familiar with our tools yet, after signup, you’ll have the opportunity to give a try to all paid features immediately.

Check out the plans, subscribe to the most suitable for you, and get inspiring insights!

Compare Plans and Pick the One for Yourself

8. Doing Too Much All at Once

It might be tempting, given the risks of a website migration, to make all of the changes you can think of in one hit. I can understand the logic, and in fact, there are many SEOs who would argue that this makes lot of sense. However, I prefer a more cautious approach.

If you are planning on redesigning your homepage, merging another website into your primary site and changing over to HTTPS all in one go then you might be setting yourself up for a hard time debugging any drops in traffic. For instance, if you are making several big alterations to the structure, design, and protocol of your website how can you tell if it is the migration from HTTP to HTTPS that has lost you traffic, or if it's the change in a copy on the site? I believe it's a better idea to make changes in stages, monitor the result, and when you are happy the migration has been a success make your next set of changes.

9. Not Checking the Success After Launch

Key to ensuring a successful migration is monitoring as many data points as you can. Well, you probably don't need to be reporting on how many cups of tea your team drank before and after the migration, although alcoholic drinks might give you a good indication of its success.

Not setting some form of key performance indicators before the migration is a mistake. Whether you choose organic search traffic to certain pages on the site, a variety of metrics from Google Search Console or your keyword rankings you need to be measuring something, and preferably, a lot of things. It is through this early benchmarking and continual monitoring that problems will be spotted. How can you identify if pages on your website have lost visibility in the search results due to the migration if you haven't ascertained their visibility before the migration? It is very tempting to sit back and relax once the launch day is over but in reality that's only half of the SEO's job completed. Constant monitoring of the site is needed for at least a month after the launch or until you feel comfortable that the organic search traffic is at a level similar (or better) than before the migration.

Mark your Google Analytics or other analytics software with the website migration date so you can refer back over time to see how it has been affected.

10. Forgetting Off-Site

The final mistake I want to touch on is forgetting that your website does not function within a vacuum. Throughout the migration process your eyes are likely firmly fixed on the changes happening on your website but it is important to remember that changes may need to occur off-site too once the migration is completed.

For instance, if you are changing a domain name as part of your migration you will want to ensure that references to the website address are updated elsewhere on the internet, like your Google My Business listing for one.

Update external references to your website where possible, including your Google My Business listing.

It is also prudent to choose some of your more powerful backlinks and get in touch with the website managers to see if they will update the link to point to your new address. This doesn't need to be completed for all your backlinks but selecting a key few to update will hopefully speed up the search engines' discovery of your change of address.

Conclusion

A website migration might strike fear into your heart as someone who is proactively trying to grow organic search traffic to the site but it doesn't need to. Try to avoid these common mistakes and you will be leaps further forward in your quest for a successful website migration as well as saving yourself a sleepless night or two.