Step-by-step guide to a successful website migration

If you migrate your site incorrectly, its Google ranking may suffer. That is why it’s important for SEO specialists to monitor your site, checking that everything goes according to plan.

I guess we’ve all seen our share of migration adventure and horror stories ... :-)[object Object]it’s good to be diligent, plan carefully, execute exactly, and monitor carefully there.
_{John Mueller (Webmaster Trends Analyst at Google)}

What is a Site Migration?

Site Migration is the process of making significant changes to the site or its structure, which can have an impact on its visibility in search engines. Let’s look at the main changes to the site, which can be qualified as migration.

Site Migration Types

Website Redesign

Website redesign is one of the popular services our company provides. As part of this process, we change the site’s current design with a radically different one.

What might cause problems?

Through redesign, we can completely change the structure of pages, the number of sections and their content, as well as navigation elements. Although the URLs may remain the same, from then on, bots and users alike will pretty much visit an entirely new website. It’s like coming to your favorite store, which is still located in the usual place, but with repainted walls, moved shelves, and new signs — you have to explore it all over again.

Keeping all the critical sections and internal links is necessary to avoid any negative impact of redesign on the site’s ranking and traffic. This is especially true for content-containing keywords, menus, and other navigation elements. You can rearrange, adjust, or move them to another spot but never completely remove those elements, as that is almost guaranteed to have an impact on the site’s ranking by Google.

Changing URLs

URLs should be simple and understandable. Changing the page address is necessary, for example, when it contains long numeric identifiers generated by a CMS. URLs can also be changed when streamlining content — you just move some pages to a separate section while adding a path designator.

Another reason for changing URLs is the migration to a new domain or protocol. We’ll look into that later on. For now, let’s discuss what might happen when a page address is modified while the domain name remains unchanged.

What might cause problems?

Each online page has its history, such as age, links, and relevant queries, and all this information is valuable for search engines. By changing a URL, we basically create a brand new page. And although the content can remain the same, the search algorithms will not instantly match and merge these pages. As a result, when searching, users may find themselves at the old address, looking at inaccessible documents. This can lead to a drop in ranking and fewer users visiting that page.

To avoid that, you should set up page-by-page redirects from the previous URLs to the new ones — 301 or 308 if a page’s address has been changed permanently, or 302, 303, or 307 if it’s a temporary transition. This serves as a pointer for search engines and users alike, letting them know that the document has changed its location and is available at a new address.

Changing the domain name

Changing the domain is usually warranted if your existing project has changed its name or you have found a more appropriate domain name that is shorter, better sounding, and more memorable. Also, this type of migration makes sense when you change the domain zone while working in a particular region. For example, you first registered "site.pl" in Poland but then decided to enter the international market and now want to remove the regional reference, changing it to "site.com".

What might cause problems?

As with URL changes, every domain on the Internet has a history. However, this case is more complex because:

1. By changing the domain, you lose this site’s history, and for Google, it will be a new domain.
2. When going for a new domain, you need to make sure that it doesn’t have a "bad" history. It’s possible the domain you’re planning to host your site at has been used before and is already sanctioned by Google.

When changing the domain, you need to check the one you’re migrating to and set up a 301 redirect. These two points are essential if you want to maintain your site’s traffic and ranking. By setting up a 301 redirect, you will let both users and bots know your new address. And by making sure the domain is clean, you eliminate the potential negative impact of the previous content found there.

Switching from HTTP to HTTPS

Most sites nowadays are hosted using HTTPS protocols, but some still stick to HTTP. If this is your case, the following information will be useful for you.

HTTPS (Hyper Text Transfer Protocol Secure) is an advanced version of the HTTP protocol for secure communication and information transfer online.

The HTTP protocol is less secure. On top of that, search engines recommend using HTTPS, which will be another advantage for a site when the algorithms evaluate it.

The procedure itself is not complicated and can usually be done by your provider, but there are certain pitfalls to take note of.

What might cause problems?

For search engines, a protocol change site will be similar to a domain change. Let’s look at a before and after example:

• http://example.com
• https://example.com

These are two different web addresses, and we can lose the entire site’s history by simply changing the protocol. Even though the process itself is quite straightforward, cases of webmasters ending up with zero traffic are not unheard of.

If you want to change your site protocol to a more secure one and maintain traffic, be sure to set up a 301 redirect and replace internal links. Normally this will be enough. But if in doubt, contact us, and we’ll help you out.

Switching hosting providers

Usually, a migration to a new host is necessary when the current one fails to meet our needs. The site owners also migrate when they see an opportunity to save money. In this case, there is no change of address or content and, it would seem, the procedure should be simple enough. However, even in this case, there are certain challenges.

What might cause problems?

If you’re changing the host for a better one, it usually does not lead to any problems. That even often helps in promoting the site. But if you go for a cheaper and inferior host, this can result in:

• Deterioration of the site’s loading speed which will have a negative impact on Google’s ranking.
• Deterioration of the site’s accessibility as some users or even Google’s bots may be blocked by the provider. This will also affect the site’s ranking by Google.

Therefore, if you want to change your host without it negatively affecting your traffic and ranking, start by analyzing the reviews of the hosting provider. Usually, they can help you understand whether everything is okay or not. Also, try to host your site geographically close to your target audience — if your users are in the U.S., don’t buy hosting in Australia. This may impact your site’s loading speed.

Changing the CMS

Sometimes you need to completely change or install the CMS if the site is custom-made. This could be a case of your site growing when continuing to manually arrange every page is no longer possible. Or your current CMS might simply not be up to the task. It’s a complicated but necessary procedure.

What might cause problems?

As I’ve said, this is a highly complex matter. Since CMS have their own logic, the migration can lead to a change in both the structure of the URL and that of the pages in general. Also, changing the CMS often leads to technical errors, which, in turn, affect the site’s ranking.

Since this is one of the most challenging types of migration, we’ll delve into that later on when looking into the process in more detail.

Merging content

The case when you have multiple pages that meet the same user need is called cannibalization. This negatively affects the ranking of these documents because Google’s algorithms do not understand which one should be shown, so they underrate both.

What might cause problems?

Normally such pages should be merged. To make the best of the situation, you need to choose the right main page — the one of better quality and optimization. For starters, analyze which page collects the most traffic and has the best ranking. Also, you should evaluate the number of internal and external links. The document with the best indicators will be the main one.

I also recommend carrying out additional Keyword Research. You might find that you don’t need to merge the pages but instead shift the focus and optimize them for related topics. This will allow you to cover more user requests.

Merging websites

Sometimes we need to merge several sites into one. This is a complicated procedure and should be done together with someone who knows a thing or two about SEO.

What might cause problems?

In truth, there can be many problems because every situation when you need to combine several sites into one is unique. Difficulties arise when some or all the websites have traffic. If only one site has traffic, it is enough to set up a 301 redirect toward it from the other ones. But if there’s traffic on several sites with users visiting different types of pages, we need to build a clear plan to maintain it (naturally, if this is the task).

So there’s that. A seemingly ordinary migration, but see how many nuances it involves.

It’s no wonder John Mueller, an analyst at Google, said that we’ve all seen our share of horror stories related to migration. But with a solid plan, we can indeed overcome anything.

From my experience, I can say that almost every such migration is stressful for the SEO specialist, but the main thing here is avoiding panicking. I remember having to change the domain of one site three times within a span of two weeks. I’ve even migrated a site without a 301 redirect, but all this can be done if you stay calm and understand how search engine algorithms work. So get in touch if you have any questions about the site migration. I’ll try to help =)

Now that we know about the types of site migration, let’s figure out how to plan and properly conduct it.

How to Do a Website Migration

Step 1: Planning

Website migration begins with planning. The more detailed your plan is, the easier it will go.

Define your goals

First, you should determine the reason behind the website migration. Are you going to change the entire site’s design or just migrate specific pages?

Once you understand what you want to do, answer the following questions: How will these changes affect the site?

For instance, the migration from HTTP to HTTPS or a domain change will result in a new URL. Based on this information, we can start working out a plan with 301 redirects. The URLs don’t change when we’re updating the design, but that might affect the navigation and the page content. That is why it’s essential to define important areas. Changing the CMS or implementing several migration options at once will be more challenging. This might affect both the page’s and the site’s overall structure, including the URL. And all that impacts the traffic on your site.

To cover more details, I will talk about the more challenging option of website migration. =)

Form a team

Consult with your crew when preparing substantial changes to the site, such as redesigning or using a different CMS. This could be:

• A designer. They will suggest how to make the site prettier and more convenient, which is currently really trendy. That way, the users will memorize your site.
• A sales manager. They can offer you insight into conversions, warning you about the underlying risks associated with the planned changes.
• A developer. They can tell you how everything will be implemented when it comes to code, as well as what programming changes the site will expect if the plan is to be realized.
• An SEO expert. They will share their thoughts regarding the suggested choices when it comes to maintaining the traffic.

If more people are involved with the site, you can ask them as well. The specialists can share their ideas, but most importantly, they will point out which problems might occur during the changes in their respective processes.

In cases where you need to change the site’s structure or URL and keep the traffic, it’s essential to consult with an SEO specialist — their recommendations can be decisive here.

Step 2: Pre-migration Preparation

Analyze the current context on your site

More often than not, the analysis will involve the site’s traffic, as well as its ranking and structure. You need to collect the following:

• Traffic data. Get the pages that helped generate organic traffic at least for the past year. You can do this either through Google Analytics or Google Search Console. There are two reasons to do this: 1) so you don’t lose them during migration, 2) so you can keep track of traffic changes and have an understanding of what to work on if it slows down.
• Data regarding the website ranking. Before migrating, it’s important to pinpoint the ranking of the site for the main key queries. This will allow you to compare the results and find potential issues after the migration. To do that, you can use services such as Seranking, Serpstat, Ahrefs, or any other you prefer.
• Pages in Google’s index. You can collect them through Google Search Console in the Coverage report. If, after migration, there will be problems with the indexing of some pages, we will be able to compare the data and see whether such issues have been happening in the past.
• The site’s structure based on all the available documents and their content. For that, you’ll have to parse your site or perform an audit. The primary goal here is to obtain the site’s structure with all the URLs, metadata, and content. This is necessary to analyze whether the new structure is correct and whether the primary content was preserved during the migration. You can parse your site using Netpeak Spider or Screaming Frog.

Back-up your site

The backup is the copy of all the site’s data, which can be used for its restoration. If something goes wrong and some of the data is lost during the migration, the current backup will help you restore it quickly.

Determine a deadline

To prevent the migration from dragging on for years and becoming a waking nightmare, you must clearly understand when the work should be finished. Divide the processes among the specialists you involve and set strict deadlines for each of them.

From my experience, I recommend planning the migration at the beginning of the seasonal decline. Many sites have a period lasting a couple of months when the traffic goes down. The best option is to prepare before the beginning of this decline and carry out the migration as soon as the number of users begins to decrease. In that case, you will have time to recheck everything and, if necessary, to adjust or even roll back to the previous version without losing a high season. The main idea here is to finish all the work before the new seasonal growth.

Create a test version of the site

This may be an obvious idea, but inexperienced developers often disregard it. All work on the new version should be done on the test server and the test version of the site.

Important! The test version must be unavailable for indexing by the search engines. You can do it in two ways:

• through robots.txt — although for Google bots, this is merely a recommendation, not a rule, and sometimes they ignore it;
• through meta robots — this is a more reliable option. In this case, you need to specify

<meta name="robots" content="noindex, nofollow"/>

• for all the site’s pages.

Step 3: Pre-launch Testing

So, you have developed a new version of the site, now make sure to test it before release.

At this stage, we need to review the following:

1. Redirects — whether all of them work correctly and lead to the required documents.
2. URL structure — check whether all the URLs are correct and compare them with the list you made at the preparatory stage.
3. Titles, meta descriptions, and headings — whether all of them are correctly specified and not empty.
4. Body content — the main thing here is to make sure there are no empty pages. Most likely, you will move the content correctly, but there are cases where some CMS create new blank pages, and we need to find them.
5. Internal link structure — whether all internal links are working and placed as planned.
6. Canonical URLs — whether they are all specified as intended.
7. Robots directives — whether there are no directives that can negatively affect the crawling and indexing of the site.
8. Structured data — whether they work correctly.
9. Correct status codes — whether there is a correct server response for all the pages.
10. Broken links — whether there are dead links (and how that happened) and whether the required pages were included in that list.
11. Hreflang — whether the hreflang were migrated correctly if your site is international.
12. Pagination — whether the pagination is set up correctly.
13. Page speed — whether there are no problems with the loading speed.
14. XML sitemap — whether there is a properly written sitemap.xml file.
15. Robots.txt — whether the file is correctly written without any remaining directives prohibiting the scanning.

We can collect and check all this data manually or by using Netpeak Spider or Screaming Frog parsers. Once collected, we need to analyze and compare it to the data taken before the migration.

You should understand that this is an example of what needs to be checked usually. Always keep in mind that every situation is unique, and in your case, this list may need expanding.

Step 4: Launch Day Activities

So, now it’s the time for release. I recommend doing it at the beginning of the workweek, i.e., on Monday. This is to avoid situations when something goes wrong and your developer is on holiday =)

At this stage, the developers bear the brunt of the responsibility. You just need to ensure the site’s new version is open for indexing and that the bot has access to every important page. To do this, check the robots.txt file and/or change the meta robots to

<meta name="robots" content="index, follow" />

The easiest way to check whether the pages are indexed is to use search engine services, but you can also use third-party services.

Step 5: Post-migration Review

Immediately after the release, we start testing the new version of the site. You should not skip this step, even if it seems that everything is going according to plan and there are no problems. There are mistakes that are unnoticeable at first glance, but if not corrected immediately, they can lead to a long-term negative effect.

Basically, at this stage, we do the same things as during Step 3: Pre-launch Testing, only now it’s not the test but the live version of the site. Our goal is to make sure that everything went as planned — all redirects are working, URLs are correct, and there are no broken links.

We should also make sure that Google Analytics and Google Search Console are working correctly on the site.

Step 6: Post-migration Follow-up and Monitoring

I recommend monitoring the ranking of the site and analyzing its traffic for two to three weeks. You will be able to see whether everything is going according to plan and quickly correct any mistakes.

To be sure that everything is fine, you will need a list of URLs with traffic and ranking that you’ve collected in Step 2: Pre-migration Preparation. It’s necessary to compare whether there is traffic on the main traffic-generating pages and whether you’ve managed to maintain your ranking. A negative outcome regarding these two points after the migration would mean that something went wrong and you need to look for the problem. Then you will be able to correct and coordinate your work on the site.

When migrating the site to a new domain or changing its URL, it is important to properly set up the 301 redirects. If that’s done, Google will be successfully handling the new pages in one to three months.

Why do Website Migrations fail?

Now that we know how to perform the migration let’s figure out why some things can go wrong.

1. Insufficient experience of those involved in the process. An inexperienced specialist may not know how to properly conduct the process or what data to keep an eye out for. This can lead to improper planning and failure of the preparatory phase. Moreover, if an unpredictable situation arises, such a specialist may not know how to solve it, possibly aggravating it further.
2. Unforeseen circumstances. The situations may be different. One of them is the migration coinciding with the Google Core Update. Usually, it happens 2–3 times a year and without notice. It is best not to carry out the site migrations while the search system is updating. Why is that? Both events can affect traffic and ranking, but you won’t be able to figure out the exact reason. So, if you saw the update announcement, wait until it is completed. Usually, it takes two to three weeks. Only after that can you collect the website data and go ahead with the migration. If you have already commenced the migration and Google Core Update has started, do not panic. Stick to the plan and then analyze the situation on the site in more detail.
3. No back-up. It happens that the site works correctly in test mode, but when moved to production, everything falls apart. In this case, it is important to have a full copy of the site in order to roll back the changes made.

Conclusion

Website migration is a difficult and, in some cases, intimidating process. However, you can avoid many mistakes by creating a proper plan and then sticking to it. The main thing is not to panic, even if you see that something went wrong. If that’s the case, contact us, and we will try to correct the situation together.

If you have been planning the migration for a long time and still can’t make a decision, get in touch, and we will help you.