Written by Fani Sánchez
The process of website migration does not end the moment we have published the new site. On the contrary. At that moment, a race against the clock begins to make sure that everything is in place and to correct small errors that we were 100% sure had escaped us. In a previous post on how to perform a migration, we saw some of the steps that we could not forget when preparing the migration of a domain. However, making sure that everything runs smoothly in the hours and days that follow is equally vital to ensure a successful migration process for a web project.
The web migration process involves three stages: 1) preliminary study and preparations 2) launch 3) follow-up, corrective and accelerating actions
In this article we are going to discuss some of the steps we will need to take in order to successfully complete the migration of our website immediately after it goes live.
Indexing aid
Sometimes, the indexing of the new version of our website is not as fast as we would like it to be. It may be due to the size of the site or to specific problems that are preventing its rapid entry into Google’s index but, in any case, there are always measures that can be taken to detect possible problems or help speed up indexing.
Different profiles in Google Search Console
To keep a close track of everything that happens in your migration process, especially in the case of sites of considerable size,we recommend that you create a property for each of the main directories of the site in Google Search Console (GSC onwards). This not only applies to the different country or language directories you have, where we do consider it essential to have your own profiles, it also applies to your main sections or those in which you have special interest (it is not necessary to register each directory of the site).
For example, my e-commerce is also translated into English and French, and I have three main categories and product sheets, all separated into their corresponding directories. Therefore, I will create 16 different properties:
- www.midominio.com
- www.midominio.com/es/
- www.midominio.com/es/categoria-1/
- www.midominio.com/es/categoria-2/
- www.midominio.com/es/categoria-3/
- www.midominio.com/es/productos/
- www.midominio.com/fr/
- www.midominio.com/fr/categoria-1/
- www.midominio.com/fr/categoria-2/
- www.midominio.com/fr/categoria-3/
- www.midominio.com/fr/productos/
- www.midominio.com/en/
- www.midominio.com/en/categoria-1/
- www.midominio.com/en/categoria-2/
- www.midominio.com/en/categoria-3/
- www.midominio.com/en/productos/
- www.midominio.com/es/
A good level of detail is always appreciated in web analytics. With an overview, we can see the overall evolution of the site, but if we have this breakdown, we can locate potential problems more quickly. For example, in the Google Index menu > Indexing status of the global property we see that the indexing is not going as fast as we would like, but where is the problem? If we have our domain broken down by properties, we will be able to locate in which directory or directories of which country language the problems are being registered. The same is true for error logging, saturation, search queries and many other indicators.
Registering different properties for the different directories of your site will help you to locate indexing and crawling problems more quickly.
Sitemaps in Google Search Console
It is advisable to have your sitemaps ready before the migration, but if not, don’t worry: you still have time because there is no point in submitting a sitemap to Google before it is operational, but preparing them beforehand will save you time. Although there is less and less confidence in the frequency or seriousness of Google consulting these files to help in the indexing of a site, it is never too much to take the more measures the better. Sitemaps are files that can help site crawling, especially in the following cases:
- New websites.
- Websites migrated (they are “practically new” depending on the amount of changes they present with respect to their previous version).
- Especially large websites.
- Websites with a poor interlinking strategy.
Remember that sitemaps should not exceed 50,000 URLs, so if your site is particularly large, you will need to have several sitemaps and a sitemap index that names them all. For example, if your portal has 800,000 relevant pages, try to divide them into several sitemaps in a coherent way. The goal is to break them down enough so that Google can “digest” them as quickly as possible.Some suggestions:
- Grouped by the different directories by country or language.
- Grouped by the different sections.
- Grouped by the different page templates.
When you have them ready, send them through the GSC Tracking section > Sitemaps. If your portal has different directories focused on different countries, you will also have different properties registered in GSC therefore, create the sitemaps from the root directory containing the language and send them in the area Tracking > Sitemaps corresponding to each view.
For those of you who are not familiar with the subject, these links on sitemaps may be helpful:
Scan as Google and submit to index
If your portal is having problems being indexed, a good option is to go to the Crawl menu > Explore as Google from GSC. In this way you are “forcing”, in a way, Google to go through your site. This point may run smoothly or the robot may not be able to access your site partially or completely. This can be due, among many other causes, to the fact that you are blocking certain parts or files through robots.txt or that you are executing redirects that, at the moment, are inconvenient. Try to solve these problems and run this menu until the results are favorable.
Check if there are redirections on the different subhomes
On multi-country or multi-language sites, often, for usability reasons, we choose to implement redirects so that a visit to the .com site is directly relocated to the directory that hosts the most appropriate content for the origin of that visit. For example, if my site has a French directory /fr/ and a user from France accesses misitio.com he will be automatically redirected to misitio.com/fr/. This can sometimes, in my experience, be a problem in the early stages of indexing a site. Disable this option while the portal finishes indexing.
Error checking
As you know, in a migration with a high rate of URLs that change their syntax, it is VITAL to create a foolproof and bomb-proof 301 redirect logic. The pages that are not well redirected and return a 404 will be throwing away not only traffic that will leave in panic from a website that “is broken” (if you do not have a good and suggestive error page), but you will ruin the possible popularity that you had on the original page, which will not be transmitted to this new URL.
However, the reality is that it is not always possible to generate all the relevant redirects (due to server issues, programming language…) or more often than desired, content is forgotten in the inkwell. Let’s take a look at some of the most effective ways to check what bugs are popping up on our new website.
Checking with Sitemap + Screaming Frog
In this step, we will send a list containing a sample of relevant URLs from the old portal that should contain a redirect to the homologous content in the new portal (as a general rule, although they can also redirect to categories or the home page in other very specific cases).
The list can be obtained in several ways
- Have the sitemap of the previous site or have the client provide you with a list.
- Go to Analytics.
- Have the list of relevant URLs to redirect from the previous site. If the site is not going to be fully migrated, the SEO in charge of the project should have prepared this list.
- To have a sample of relevant URLs from the current site and to know the criteria for changing their syntax. For example, if your product cards had the following syntax “mydomain.com/catalog/catalog/category/productname.html” and now all these types of URLs have deleted the “/catalog/” directory, you will just have to take the new URLs and apply a substitution rule in Excel to get their counterpart URL in the old domain. This way we get the list of URLs of the old domain.
It is advisable to carry out this check during pre-production, i.e. before launching the site. These redirects should already be operational in this test domain (such is their importance).
Other errors with Google Search Console
In the Tracking section > Tracking errors > Not found, you can find the main 404 errors on which you can establish patterns.
You can start by analyzing the errors by priority or by a weighted priority – template. For example, one way to proceed with the latter methodology is to identify the page templates that appear most often on the first page of the listing (these will be the highest priority errors). I detect that I have several product pages and blog tag pages. I will enter four or five of each type and examine where they are linked from. Surely the error will follow a pattern. By identifying and fixing this we can mark a large number of bugs as fixed. ” Marking bugs as fixed will help you to keep track of them. If in a few days this type of error appears again, it means that we have not found the right solution.
Check desktop but also smartphone errors. Once you have identified and solved the problems that generate them, mark them as solved for more effective follow-up.
Checking of linking elements
Another thing you should check is that the link elements such as canonical, hreflang or alternate are still in place. Do not work the same with relative links, since a small oversight can generate tremendous chaos. Always stipulate the elements absolutely.
A great tool highly recommended to check these aspects will be ScreamingFrog, with which you can check, among many other resources, the “directives” of each of the pages of a site.
If you have a complete listing of the site I recommend uploading the file as a list but, if not, it is not a bad idea to enter the domain and let our spider crawl it, as it may find things you had not taken into account.
Web analytics
Web analytics is, again, a vital part. For a migration process, we must take into account at least these two aspects:
Profile views in Analytics
As we have already recommended above, it is always preferable to break down the data collected so that its analysis is much simpler and more accurate. In this regard, if we have new directories by country or language, it is time to create new views for each of them.
We will create a new view for each country and/or language directory.
The data of the new profiles created are not retroactive (i.e. they start to be displayed from the day they are created), so to track the flow of traffic on the portal during the migration, we will use the advanced segments.
Create advanced segments in Analytics
This point is of vital importance. If you want to keep a close track of how traffic flows after migration, it is imperative that you create some advanced segments. These should collect the traffic flow to certain sections before and after the migration.
Let’s take a practical example. My portal had a news section whose URL syntax had this construction: mydomain.com/c/news/. Currently, we have migrated all news to mydomain.com/blog/news/. When we launch the portal, all traffic to the old news section should stop dead in its tracks (if we’ve done things right) and start registering traffic to the new section. But measuring traffic separately for each section? This would not allow me to have a complete view of how the traffic that previously visited the old section is flowing to the new section. Therefore, we will create an advanced segment as follows:
Create a generic segment with these characteristics and analyze the overall traffic flow and for each of the channels (by going to Acquisition > Channels > Channel determined with the segment activated). To check some other metrics it will be advisable that you also create a segment that records only the organic traffic to each of the sections.
If things have gone as they should, it is logical that you will find a stable graph or even a graph with a slight drop that gradually recovers. I know that many of you will want to ask what percentage of traffic is estimated to be lost and for how long, but I will tell you in advance that it will depend largely on the magnitude of the migration and the average traffic received.
It is advisable to analyze the total organic traffic flow to the portal, and the organic traffic flow per template, because very different results may be coexisting. For example, why is it that directory X has been doing so well while directory Y is not doing so well? Start by pulling the thread over here.
Analyze the traffic flow after the migration on the whole site and on the most important sections and analyze it by channels
Other tools
It is also a good idea to check how the traffic curves, link elements, visibility or keywords behave according to the different tools you use in the day-to-day running of your projects. For example: SEMRush, Sistrix, ScreamingFrog or Advanced Webraking. Although the data from many of these tools are public and accessible to anyone (you should take them with a certain relativity), it is true that a large number of them are not available to the public.n common trend or significant changes in several of them is not open to discussion.They can’t all be wrong at the same time, nor to that extent, so they can’t be too far off the mark.
Check visibility indicators or the evolution of keywords in tools that you were using in the campaign or not, but that can give you a historical trend of the portal.
Pay special attention to the keyword analysis: both in the listings for which we are positioned and in the sample of words on which we focus the campaign.
In short, do not rest on your laurels: the success of a migration depends entirely on it!
