A guide to site migration: explanations, mistakes and SEO tips

It is a sensitive, and in some ways even tedious, process, since net of the benefits it can produce in the long run it also has many pitfalls, which can cause deleterious consequences when mistakes are made and crucial details are overlooked: site migration, of any kind, must be managed as best as possible to avoid annoyances to Google or users after the transfer, which result in drops in rankings and organic traffic. In the words of our own Giuseppe Liguori during a ZoomDay, “if the migration is not done correctly it can only lead to one result, which is trouble,” and even Google confirms that domain and URL transfer is indeed a complex operation even for search engines, which can take up to several months to process the changes fully. So let’s delve deeper into the topic of website transfer and the migration process, trying to define the scenarios in which it is necessary or preferable to move a site, what this step means in practice, and what are the risks involved that can sink the new site.

What is site migration

Very intuitively, the temporary or definitive migration process is the transfer of a website that takes various forms, as we will see; it is a delicate aspect because, when not performed properly, it can compromise the SEO management of the site, causing damage to organic traffic and relevance gained over time on search engines, but also generating difficulties to users and their user experience, leading them to suddenly navigate to a different site and perhaps problematic on some aspects.

Why do website migration

There are many reasons why a site may need to be migrated or completely redesigned: among the most frequent are the switch to HTTPS protocol (which should be a minimum standard by now), the need for rebranding and a new corporate identity, the decision to make the site faster and mobile-friendly, or the emergence of new digital marketing goals achievable precisely with a change of strategy.

What are the types of site migration

The relocation of a site can be done independently-having the basic knowledge and skills, of course-or outsourced to an outside agency, and the various types of migration can be done individually or simultaneously. In any case, it is best to know what may be the cases that prompt the decision to carry out this migration, so as to also delve into the consequences, issues and specific criticalities of the various cases.

Preventive operations to reduce errors

Regardless of the case, among the procedures that must be performed before the site transfer is first of all the mapping of all URLs and resources of the existing site, analyzing the sitemap, identifying pages that receive internal links or external backlinks, and analyzing the server logs, including image and video files. Always before the transfer, the old addresses must be associated with the new URLs, so that the various redirects can then be set up.

Website transfer, the simplest and most common types

The simplest type of migration is domain change or rebranding (including extension transformation); graphic migration and redesign of the site layout should also not involve any particular risks (an example is the replacement of the WordPress template or its implementation), just as the process of migration from HTTP to HTTPS should be smooth by now.

Site migrations of medium difficulty

A higher level of complexity is reserved for other types of migration, such as that of URLs, content architecture or the servers hosting the site. URL relocation concerns precisely changes to the addresses, paths, and structure of internal URLs within the same site (an immediate example is switching from speaking to static URLs); content migration is necessary, for example, when reorganizing categories and then needing to move articles and products under the new hierarchies. Finally, server transfer or migration of hosting and IP address occur when, for technical, reliability or practical reasons, it is decided precisely to change one of these parameters.

CMS transfer, the most complex migration for SEO

Perhaps the most difficult case is the migration from one CMS to another CMS, for example, the transfer of the site from WordPress to Joomla or vice versa, or even from .asp to .php and so on, following evaluations on the best CMS. In this case, the most critical aspect on the technical front is the radical change of addresses that can result in a long list of 404 status codes, while on the SEO side the risks are the loss of domain authority (also) due to the disruption of backlinks received over time and the excessive and dispersive increase in Google crawl budgets.

How to perform a CMS migration safely

In the aforementioned speech at Zoomday, Giuseppe Liguori proposed his tips for performing a safe CMS transfer, identifying three key points to be observed to avoid nasty surprises and starting with an assumption, namely the need to “build a bridge between the two CMSs.” In the preventive phase, you need to back up the old product database and the old .htaccess rules, while on the practical side you should build a code script that “queries the old database; finds a common element (E.g. SKU code, product name, etc.); queries the new database; performs a 301 redirect to the new URL.” At the end of this process you must verify that everything is correctly transported to the new addresses.

This operation is particularly complex because it presupposes (at least) three minimum requirements: the presence of a programmer who knows both CMSs well; the intervention of an SEO specialist who knows how to use htaccess; and a phase of constant verification of the work to make sure that everything is being done in the right way and without hiccups. However, it represents “the only working way to recover all URLs” or nearly all URLs.

Best practices for doing site migrations

As mentioned, in principle, the other types of transfer and migration should not be as complicated, but nevertheless we provide a few pointers to perform these operations with the right care and peace of mind.

How to perform site URL migration

Changing addresses within the same site may become necessary when you discover that you have made mistakes in structuring, or when you are trying to improve navigation and the overall user experience. Common cases are the presence of dates on pages that then become obsolete, pointing out unnecessary elements, moving entire directories, and so on; in such situations, the migration is done through rewriting rules, trying to respect the “less is better” philosophy (and thus the suggestion to have a light and compact url as opposed to more extensive ones).

From an SEO point of view, Google reassures about the “credit” the site has after redirect links to new URLs: in fact, the Search Console Guide states that “301 or 302 redirects do not result in any worsening of PageRank ranking.”

Site server relocation

Server migration can also be a risky process, because it can generate two types of problematic situations: the new server turns out to be worse than the previous one or some incompatibilities are found, and therefore it does not respond perfectly to requests and causes errors; the technical time of DNS switchover and IP change can cause even serious disruptions to users and the search engine.

How to perform a server migration safely

Again, Giuseppe Liguori has provided broad guidelines, best practices for moving a site from one hosting to another without having disruptions. If neglected, the following aspects could result in very long downtimes, exceeding 24 hours, and thus the famous troubles mentioned earlier:

1. Make an initial copy of the complete website from the old hosting to the new hosting, using one of the many plugins to do website backup & restore, especially in WordPress environment.
2. Test the website well on the new hosting and launch a stress test to the site with the new IP address, taking advantage of the computer’s “hosts” file; then we can see perfectly how the site will work when the migration is completed.
3. Do a full scan of the site to check for any errors that previously did not exist.
4. Having completed the initial steps, if it has been too long you need to re-copy the website or at least the recently uploaded database and images.
5. Move the website IP from the DNS manager’s panel; do not disable the old hosting as it may take several hours to update to the new IP.

Tips for migrating from HTTP to HTTPS

It has been three years now that Google has been pushing for all sites to migrate to the HTTPS protocol, either by including this as a ranking factor or by marking all sites in HTTP as “Not Secure” on the Chrome browser. In fact, as far as security is concerned, it should be specified that the major protection concerns the traffic between the site and the end user, and therefore there is no protection against hacker attacks and the like, and that in general this migration serves to ensure the security of data transport, raise the level of privacy and increase the level of trust towards the user.

How to perform the transfer to HTTPS

The first step is to purchase the certificate, which then needs to be activated manually or following the provider’s installation. This transfer is quite simple and you just need to follow a few steps to complete it effectively; for example, to migrate WordPress to HTTPS (or to transfer Prestahop, Magento, Joomla and the other CMSs) you just need to change the data in the settings panel, but there are also specific plugins that perform the process automatically. Then you need to launch 301 redirects with htaccess and spot-check that the redirects were effective.

HTTPS SEO migration tips

It is important to note that after the migration is complete, you need to create a new property in Google Search Console for the domain in HTTPS, as if it were a new site, because GSC handles HTTP and HTTPS separately. Also, it is advisable to keep the old property in HTTP for possible future problems or to evaluate historical data.

Why perform a domain change and rebranding

Another critical situation you may find yourself in involves rebranding, which is the need or requirement to change site and domain names as a result of certain factors, such as copyright or reputation issues, moving a multilingual tier to a country-based domain, site or brand name meaning something bad or obscene in other languages, or more simply for other marketing choices.

How to perform the site transfer safely

Regardless of the reason for rebranding one must use the usual SEO-side tricks of redirection, with the change of addresses in CMS described earlier and other redirection rules for URLs. Before the new site goes online one must scan and verify that the process has been effective, either with specific tools or manual comparisons, keeping in mind that all status codes other than 301 or 200 generate problems for Google (and thus potentially for the site and the business).

In any case, to avoid dissipating the work done one must approach this delicate step by also taking care of the SEO aspect of the migration, and thus be careful to preserve the organic visibility of pages and content and to ensure that the keywords that generate the most traffic (and their URLs) are transferred without errors.

SEO site migration, quick tips to avoid trouble

The guidelines described here are a quick vademecum for dealing preemptively with the site migration phase safely, trying to avoid inconveniencing Google or users in a delicate transfer process. However, it should not be overlooked that any migration, even when done in the best possible way, may have positive or negative consequences on the site, so the goal is to minimize risks and try to limit any damage. In addition, the time factor cannot be overlooked: such a massive and substantial change also takes time in search engine scans, so it is normal in the early stages after migration to register fluctuations in visibility and rankings, which will then regularize in later periods.

Migrations and URL changes: the process is difficult even according to Google

But migration is not a hostile topic only for webmasters, specialists et similia, because search engines also find it difficult to handle this operation, going so far as to take up to several months to fully process the changes.
Although “at first glance it may seem like a small change within a website, changing the structure of URLs is not so simple for search engines”: an #AskGooglebot video opens with precisely this reflection, in which John Mueller responds to a user’s request asking about precisely the topic of migration and, in particular, the possible risks associated with the operation.

The Search Advocate then immediately warns about the delicacy of the process, which even when done correctly takes a long time for the search engines themselves to process, and thus can lead to critical situations, such as dreaded drops in traffic.

The difficulties with site migration

Changing all the URLs of a site to move them to a new domain, and thus a complete migration, is perhaps one of the most intimidating SEO interventions one can make, because it affects precisely the entire site as a whole.

There are a variety of reasons for taking this step (e.g., domain change after corporate mergers or brand changes), but in general whether we are “completely rebuilding a Web site or simply removing a slash from the end of URLs” we are still performing a site migration, which also requires time and attention from search engines to process the changes.

As Mueller explains, this is due to the very characteristics of search engines such as Google, which “store their index on a per-page basis: therefore, by changing the address or URL of a page, its data must be forwarded somehow, otherwise it is lost” . That is, all signals, all links, all information that Google has in relation to that URL must be forwarded to the new URL.

Google’s recommendations on site migration

To try to reduce the risks and not make mistakes in the migration, the Search Advocate offers a quick guide to the process with basic directions to follow.

1. Evaluate options and potential effects

These changes to the site can cause disruptions to the SEO and ranking gained, and so it is important to plan the intervention and carefully evaluate the options, risks, and possible consequences in terms of ranking and timing – to decide what is the best timing to expose the site to a potential drop in traffic.

2. Mapping old and new URLs

Before performing the migration, it is a good idea to keep track of all URLs from the old site and the new one, to “control changes later.”

In this way, we can study in advance which resources are to be migrated with a 301 redirect, which ones are to be deleted, etc.: when the process is finished, then we will go to verify that all useful URLs have been transferred and are actually online, and that there are no unexpected responses with pages in 404 status code (resource not found).

3. Launching the migration

Now is the time to launch the migration.

Google reminds you to properly implement 301 redirects from the old URLs to the new ones and not to leave out all “internal mentions” of the site, such as links, forms, structured data, sitemaps and robots.txt files.

4. Monitor the outcomes of the migration

The last step is the most important one for the SEO fate of the site: that is, we need to check that all pages have been redirected correctly, using Google Search Console tools.

The time it takes to complete the migration

Mueller’s (short) video also gives us a rough indication of the time it takes Google to complete processing a site migration: in fact, the search engine can take up to several months to finish the modification process on all URLs, although it will prioritize those that are important to the site.

In fact, in Search Console you can see that the most important pages will be analyzed and modified faster, while the others are subject to slower processing to give Google’s systems a chance to reprocess all the changes.

Also for this reason, Google reminds that redirects should be kept active for at least a year after migration.

A complex process that can work well

Migrations are really difficult, as SEOs, site owners, publishers and webmasters who have already experienced these URL and domain shifts know. Yet, Google wants to “reassure” us that, with the right amount of preparation, study, research and attention it is possible to complete this task successfully and reduce stress, taking advantage of all the tools to detect errors early and monitor the progress of the transfer.

Changing hosting, Google’s official guide

Still talking about Google, in mid-February 2023 the Search team modified its support documentation page dedicated to SEO migrations, focusing its advice specifically on hosting changes and techniques to minimize the impact of changing the site’s hosting infrastructure on the site’s performance in Google Search.

Even more specifically, the guidance only covers migrations that do not affect the user-visible URL.

As Google reminds us, changing the hosting infrastructure means changing host providers or moving to a content delivery network (CDN), and the ideal process consists of four steps:

1. Prepare the new hosting infrastructure, either by uploading content to the new servers or by configuring the CDN network and the source servers, with the appropriate functional tests.
2. Begin the site move by changing the domain name DNS settings so that they redirect to the new hosting infrastructure. This step represents the actual moving of the site and begins the process of directing traffic to the new infrastructure.
3. Monitor traffic, both from the new hosting and the previous hosting.
4. Close the previous hosting infrastructure when we are certain that all users, including Googlebot, are properly receiving content from the new infrastructure and that no one is using the previous one.

Tips for changing hosting correctly

The trickiest part of this operation is probably managing all the steps we need to take before we start the actual infrastructure move.

According to Google, we should start by uploading to the new host provider a copy of the site, intended either as actual HTML files to be replicated to the new hosting platform or as a database to be imported to the new location, and by scrupulously testing that the site is working as intended, verifying that there are no problems of any kind in aspects of user interaction.

A viable solution for testing all functionality prior to the actual publication of the site might be to create a test environment, perhaps with limited access to specific IPs, and the testing process should include oversight of all elements of the site that are open in a Web browser–and thus pages, images, forms, and downloads (e.g., PDF files).

Next, it may be to allow public testing with a temporary host name (such as beta.example.com) for the new infrastructure to test accessibility by browsers, so as to check whether or not Googlebot can reach the site – to prevent the test site from being accidentally indexed, we will add the noindex robots rule to the HTML or HTTP headers of the pages. To control Googlebot’s behavior (and Google’s access and traffic) to the new hosting infrastructure, we can access the Search Console, create a new one for your site and possibly also for the temporary property. Aspects to consider include checking the firewall configuration or protection against denial of service (DoS) attacks to prevent them from preventing Googlebot from reaching the host provider’s DNS system or servers.

In addition, Google suggests reducing the TTL value (e.g., a few hours) for DNS records as early as a week before the move to speed up the site move: in this way, we allow faster propagation to ISPs of the new settings.

The last step brings us back to Search Console and, specifically, checking that the site verification in Search Console is still valid after the hosting move and also updating the verification methods chosen in the new site. For example, if we use the verification method via HTML file we must include the current verification file in the new copy of the site, just as verification via meta tags or Google Analytics in CMS templates requires inclusion in the new CMS copy as well.

False SEO myths, what to know about site migration

In short, site migration is definitely a difficult task, but it is certainly not impossible, even though we often read the opposite (or at least exaggerate the magnitude of the task).Just to clarify these concepts, the SEO Mythbusting series on YouTube dedicated an episode to debunk myths about site migration, offering an overview also of domain name changes, site mergers, partial migrations and more.

False myths about site migration

Given the breadth of the topic, it is not surprising that this episode is also the longest ever in the series, running over 20 minutes; the guest is Glenn Gabe (Digital Marketing Consultant, G-Squared Interactive), who opens the episode by recounting an old consulting experience he had, which is helpful in introducing the topic.

Once, he says, “I helped a large-scale e-commerce site that had not made a redirected 301 to images, which therefore had not been transferred (we also cited it as a frequent error in our insight); so, The advice is to never forget to redirect even to images and visual content and then check if the process was successful”. For example, checking the log servers of the old domain to see if traffic has dropped, and when we notice that the crawling activity has dropped say goodbye to the site.

A topic that can be scary

It is still Gabe to point out that many site owners have a real fear to start the migration process, because they do not know sure what can happen; others instead perform the operations too quickly and without having prepared everything properly, as evidence of the complexity of the topic and the strength of the main “false myth”.

According to the SEO metropolitan legends, in fact, there will always be a drop in traffic after a change of domain name or the migration of the site, but in reality it is not so.

What really is the site migration

Martin Splitt then takes the floor and debunks this myth, explaining that first of all what is a site migration, meaning – literally – the complete transfer from one domain to another, copying practically the entire structure of the URL and the entire content, so that at the end of the process you will have a perfect copy of the old site on another domain.

This process does not always imply a decrease in traffic: to be precise, traffic begins to decrease on the old domain to resume on the new one. Overall, this does not mean that we are losing traffic, and generally doing this operation cleanly allows us to complete the work smoothly without losing anything. More critical is only a partial transfer of the site, which could lead to traffic anomalies.

The analogy with the restaurant or the food truck

To better explain the concept, Splitt launches into a colorful analogy: in his opinion, the migration of the site can be compared to the change of location of a restaurant or a food truck.

When we go to a restaurant, we look for answers to a series of questions, such as “do I feel welcome? Is the staff friendly? Is the quality of the food good? Is the price right?” , and we store the answers in our mental folder for that place – just like Google does with its signals and ranking factors for each Web page.

If a friend asks us for advice on a restaurant to try, we will probably use the signals we collected to give him the right information and recommendations – “it’s perfect if you like Asian cuisine, it’s a really very nice place, but rather expensive” and so on.

If the restaurant moves to another area and another place, we will probably have to re-evaluate some of the answers, to find out if the characteristics have remained the same or if there was some variation – to determine if it is the same restaurant or food truck that has only changed area, for example keeping the same quality cuisine and the same prices, or if something has changed.

This also applies to search engines, which have to re-evaluate what they see and find on the new domain.

New domain name and traffic anomalies

Gabe then asks to focus attention on a specific topic, the change of domain name: sometimes the process went smoothly and the site takes strength over time, but in other cases there may be anomalies, such as “a site that, three days later, fills up completely by 70%”. The expert asks if this different behavior can be based on the history of the domain, especially in cases of acquired domains and subsequent migrations.

According to Splitt, these cases are unrelated to the history of the domain, which plays a role mainly in the situations – defined as “complicated” – of sites basically used for spam purposes and then purchased and switched immediately. The advice is to take all the precautions to avoid getting into weird issues, using all the monitoring tools also in Google Search Console to check that everything has been set up properly before making the switch.

Anomalies may occur even if we make other changes during the migration, a “risky thing” because it puts Googlebot in front of difficulties of understanding and differences between two versions of the site. And this, in turn, can translate into the need for the bot to run new scans to better understand, also negatively affecting the crawl budget, especially for large sites.

Situations with acquired domains

So these particular situations may depend on various factors, but according to the Googler in principle switch to a domain that we are sure does not have pending past loads should be fine. And even if we move to a domain with a negative history, Google is aware “that domain content changes” and the Manual Action Report has a tool dedicated to the request for reconsideration of newly acquired domains. However, we need to know that depending on how the domain was previously, Google may not immediately consider the action as a migration, and this will therefore require you to do a re-crawl and a reworking of the content, and therefore more time.

In this regard, Gabe cites another example from his consulting work: there was a customer, an e-commerce site, which had a very long domain name and wanted to reduce the name to the four letters that represented the company; after finally acquiring the new domain and making the transfer, they realize that there is something wrong. They had not done the right checks and they bought the old domain of a “kind of rock band of the past” that was full of “crazy spammy links and all kinds of things”: so, in the immediate had a crash of traffic, which then settled over time.

This confirms that content can change and Google’s consideration can also change – even in cases where the domain has a spam history or has been hacked – so it only takes a little time to fix it.

How to correctly start with an acquired domain

Splitt’s advice is to be sure to clean up everything that could be problematic in advance, so as to give Google time to understand that “things have changed” and there has been a clean slate of the past.

In more detail, when you detect a domain (not only to transfer our old site) it is crucial to measure what happens through tools like Search Console and learn about the health of the domain, possibly considering the possibility of removing the content, waiting for Google to understand this intervention, eliminate negative signals and make things normalize. Only at this point should we start the domain transfer in a progressive way, so that – while Google discovers the moved pages – it begins to evaluate the contents as a new beginning for the domain.

The false myth on site fusions

The video then goes on to face another myth to debunk, related to the fusion between two sites: many, says Gabe, think simplistically that putting “one plus one gives as a result two”, but it’s not always so.

Also because – adds Splitt – combining two sites together is no longer a migration, but creating a new site from an amalgamated version of the previous: this means that Google must understand the new content, understand how they moved from the starting domains, but also whether it is in front of a completely different domain or not, because maybe only the structure of the Urls changed in the passage, or there was the transfer of some content.

Anyway, nothing in this process is as simple as a migration and Googlebot has to scan a lot of pages again. Depending on the size of the site, this could mean that it takes a long time for the search engine to have a clear view of the site, its structure and its current content, and of course much depends also on what concretely unites in this fusion and on the attention dedicated to the process.

Migrated sites, how Google recognize the new domain

Later Gabe moves the focus on another topic, that is what happens to Google when the change of domain name is properly completed and recognized, that is when a site moves from one domain to another and all redirects are active.

As a first step, Google first checks the similarities between the old and the new site, to be sure that the new site is exactly a perfect copy of the one on the old domain – which, Splitt reiterates, is the real migration of the site. When it ascertains that this is what has happened, Google will begin to forward all signals from the old domain to the new one, but the speed of this process is completed varies from site to site (going from a few days to a few weeks).

Initially you might notice an increase in the activity of crawling on the new domain, which gradually decreases when Google understands that it is a copy of the site on another space. At the same time, if everything is normal, the crawling and the signals will disappear from the old domain to move to the new one.

More clarity with the Change of address tool

Webmasters engaged in the migration process can use the Change of Address Tool to give Google additional and clearer signals about what is happening and simplify the understanding by the search engine.

It is, according to Splitt, a useful tool to give explicit indications to Google that the site has moved permanently and therefore is not a temporary change, that could then speed up the completion of the process because it gives way to Google to skip some steps, having the certainty that the transfer was voluntary and intentional.

Migration and content quality: new evaluations after the transition?

Another “myth” that Gabe had the opportunity to meet and listen to in his work is the reassessment of quality ratings by Google after a migration. In fact, Splitt explains that Google constantly re-evaluates the quality of content, regardless of whether the site has been moved, and reiterates that “if your content is now considered high quality, it does not mean that it will always be”.

This also holds true on the contrary: low-quality content or spammy could, in theory, be considered high-quality if improvements are made.

However, as far as migration is concerned, in principle if there were high-quality content on the old site that is moved identically to the new domain, then the signals will also follow.

Issue with the transfer, it is better not to go back

Another advice coming from Martin Splitt is how to deal with any problems that arise after completing the migration: a common feeling, especially when traffic drops occur and you do not recover the previous positions, leads to consider reversing the process to restore the initial status.

For Google, this is a step to never perform except as an extreme ratio, when there are no other options and all checks performed on the new site have not given outcome or explanation to the collapse.

In most cases, in fact, just check that there are no technical issues that can interfere and cause the negative effect: for example, Google may not have recognized the redirects, or the old site was crawled with little frequency and therefore takes more time to allow the bot to pick up the redirects. Other situations could be algorithmic changes occurred in the meantime, or even spammy content reporting or manual actions and so on.

If we are sure that we have done all the steps correctly and, after a month, the traffic has not improved and returned to the levels of the old site, it may be the case to ask for external help to find out the cause of the situation.

However, it is always important to compare the traffic between old and new domain: if the old site continues to have all the historical traffic, this is a sign that there has been some error in the migration process. Only in this sense, says Splitt, could it make sense to “reverse the process for a while, go back, understand what happened and then regroup”.

Migration and robots file, tips to make no mistakes

Another technical aspect discussed during the episode concerns the management of URLs blocked in the robots.txt file: Gabe asks if it makes sense to unlock resources in the transition to the new site, but Splitt is rather clear in stating that it is “not needed”.

According to the Googler, there is a reason that the site does not want those Urls scanned, so there is no reason why the crawler should analyze them by migrating to the new site.

The most common issue with site migration

The last theme analyzed concerns the most common problems that Google finds on sites just transferred: the list includes many technical variables, such as robots.txt that completely blocks the pages of the new domain, a noindex meta tag on all new content or failure to pass the Google Search Console settings on the new domain.

Yet, according to Splitt, the most frequent error is making too many changes and changes at the same time during the migration, adding “too many variables” which also make it difficult to understand the effects of work. In these cases, in fact, it becomes difficult to identify with certainty the cause of a problem, which could derive from the new structure of Urls, from the different technology used, from the new content, from the migration, from algorithmic changes of Google, from penalties and so on.

Google’s final advice is to take it one step at a time: first focus on domain transfer, then change text decks, then possibly intervene with other things. “Whatever you’re doing, do it step by step,” Splitt says, waiting for Google to do a new crawling and process the site before you put your hands on it again.

Site migration, five frequent mistakes in the transfer

What has been written should have helped us to better understand what website migration is and why it is a delicate process for the SEO of our projects, but also to dispel some negative myths surrounding the topic. Yet, we said, some negative effects can always occur, especially in the early stages after the work is completed, and most importantly there is the possibility of running into migration mistakes that turn into trouble.

The critical issues with the process of relocating a site

In general, we can say that failure in website migration occurs when certain components come into play, such as an underestimation of the risks involved in the transfer process, poor prior planning of the various steps, the absence of a checklist of the operations to be performed (or the failure to comply with its points), and, last but not least, the lack of necessary technical skills on the part of those performing the migration.

1. Forgetting to transfer images One of the most frequent mistakes made during migration, especially when transferring from CMS to CMS, is forgetting or neglecting images. These media assets are a part of the SEO strategy especially for eCommerce, which also benefit and traffic from Google Images searches. Therefore, losing rankings for image searches can also mean loss of conversions.
   It is Giuseppe Liguori again who explains that – in his experience – there is no easy way to migrate images from CMS to CMS. To perform this operation in the best possible way, he advises to “keep the old folders still there for a long enough period, and then wait for Google to figure out that the page has changed,” premising, however, that it is “not the optimal solution because 301s would have to be handled there as well, but it is not always feasible.”
2. Not performing redirects correctly The second category of mistakes concerns the mismanagement of redirects, which are the most important tool for avoiding inefficiencies and limiting problems. In this case, the mistakes to avoid are temporary redirects (301 redirects should be permanent or at least remain active as long as possible, so as not to result in other types and error statuses) or “one-to-many” type redirects to the new home, which Google interprets as “soft 404s.”A more effective strategy involves, in case an old page does not have an exact match with one on the new site, redirecting the resource to a category page or a page that is related in terms of content covered.
3. Do not set a custom page for 404 error Let’s move on to a “concept” error, so to speak: a good strategy for limiting risks and disruptions cannot fail to include the possibility of something going wrong. Therefore, with a view to still providing a focus on the user and their experience on the site, it is always preferable during the migration phase to make sure to design custom pages for the 404 error, the most dreaded status for sites.By reading the information provided on this “page not found,” perhaps peppered with a humorous message or tips for landing on other useful resources, the reader will not find himself disoriented but may be provided with pointers to continue navigating within the new website
4. Robots.txt file not configured correctly Far more serious are the consequences of errors related to failure to configure or misconfiguration of the robots.txt file at the end of the site transfer process: in the regular procedure, it is necessary to update the file and avoid the possibility that resources or sections of the site that should instead be opened may be blocked.Another frequent critical issue is the use of the disallow directive in the robots.txt on folders that contain CSS and Javascript files that are needed by browsers to properly draw the page and by spiders such as Googlebot to properly scan and index the contained elements.
5. Not checking backlinks
   
   The last mistake we add to this quick list of problems related to migrating a site concerns a sensitive topic for SEO, namely backlinks, which, as we frequently repeat, are among the most important ranking signals on Google.Therefore, in order to avoid jolts to the ranking achieved after much work and effort, it is necessary to proceed with special criterion and care at each stage of the migration and strictly verify the settings of redirects on pages that had received backlinks over time.

Verify backlinks even after redirects

In addition to the standard changes, such as changes to social profile links in case of domain transfer or rebranding, the general advice is to proceed with updating the referring URLs of incoming links to the migrated site, possibly contacting the individual webmasters of these sites (starting with those who manage the most important and highest-trust domains) to report the migration and thus request the consequent change to the links.

The most effective way of doing this starts in the early stages of the migration process, when one can download the list of resources pointing to the divested site thanks to the classic backlink analysis tools, then checking after the transfer is complete that the redirects are working and if there is the possibility of linking directly to the new resources, thus also simplifying the path that Google has to follow to reach the correct destination.

Migrations and site traffic drops, 11 possible causes

Despite the caution, however, we can still run into some mistake, forgetfulness or carelessness that risks compromising the result and causes a drop in the site’s organic traffic: if, in fact, it is natural to experience fluctuations in visit volumes and in rankings in the early stages following the process, the situation can become critical in the presence of errors such as wrong redirects, broken internal links, blockages in robots.txt files or in the sitemap that can cause the site’s performance to plummet.

Finding out any problem with a technical analysis

The first step to solving the issue is to have “a complete list of the problems that afflict your site, so you can verify and correct any problems that might arise”, as Ludwig Makhyan says on Search Engine Journal.

We can use tools like Screamingfrog or the SEOZoom spider to scan the site and find all the page specific problems, such as

• Redirects
• Broken links
• Duplicate content
• Metadata problems
• Blocked URL txt.

Another tip is to launch a main scan and back up your data before any migration or redesign of an important website, so you have data for later comparison and see what has changed. At the same time, you need to save a copy of the HTML and site layout before redesigning it, so you can review and revisit it if necessary.

 

The 11 most common causes of traffic drops following a migration

Based on his experience, Makhyan then lists what are the 11 most common reasons why you may experience traffic drops after a migration, technical errors related to the complexity of the process that may lead to the failure of the operation in terms of site profitability.

Still worth the advice given by Google on migration: better not to go back, but try to solve all the problems and insist with the new site, unless you find yourself without other solutions, because all the checks carried out on the new domain did not result in or any explanation for the collapse.

1. Changes to canonical tags
   

We look for pages on the site that have lost traffic or rankings, analyzing canonical tags to see if they have been modified in a way that may have affected traffic.

Some of the common problems with these tags are:

• Indication of not relevant pages.
• Programming problems (example: missing final bar).
• Indication of old Urls that no longer exist.

2. Non indexable txts and/or Contents

The second step is to check the robots.txt file or pages that have lost traffic to see if they are still indexable, because the drop could result from a problem with indexing. Google provides a robot.txt file verification tool (robots.txt file tester) that can help us identify and fix any problems we may encounter with the file.

3. Loss of metadata
   

The migration could cause the disappearance of website metadata during the process, because in the transfer of the database you may lose columns related to title tags or meta descriptions.

Scanning with crawling tools and spiders allows us to verify that the titles and description are still accurate and intact; otherwise, you will need to re-enter these important metadata, finding the previous ones thanks to the backup created before the migration or doing a quick search on Google site using the “site: URL.com” command to read those in the engine memory.

4. Loss of page speed
   

In case of complete migration of the website or change of servers, in the process you may risk losing a bit of page speed, and therefore it is useful to check the technical performance of pages with decreasing traffic to monitor the situation.

In cases of actual speed loss, you may need to:

• Verify that the CDN is included in the migration and works properly.
• Verify that the cache storage system is installed and works properly.
• Check out Pagespeed Insights to find easy solutions that can increase site speed.

We should not forget that even the server problems could affect the site and not allow it to load quickly enough.

5. Checking internal links

Internal links are a great natural way to keep people on the site and also help search engines move from one page to another of the site. After a migration it is essential to check that the internal links in blog posts and pages are actually pointing to the new current site and do not refer to the old one.

6. Content accessibility issues
   

Google Search Console lists all the indexed pages of the site in the Coverage Status Report, which reports pages with error, valid with notice, valid or excluded. At the end of the transfer process, therefore, it is advisable to monitor this report to find out if any accessibility issues have arisen.

7. Broken redirects

Site redirects are an integral part of any migration, Makhyan points out, and “if you don’t have a redirect plan 301 during site migration, you will have many problems later,” the expert explains.

The risk is to lose traffic because “search engines are not told where your site has been migrated to”, but even visitors may be disoriented in the process.

We must go in search of any loops or redirect chains that present problems, trying to:

• Clean all the redirection loops.
• Follow the redirect chains to verify that the redirection is accurate.
• Check that the old Urls are redirected correctly to the new Urls, updating links to pages with 301 by connecting to the new page instead.
• Check that the start URL and the destination URL are accurate.
• Also check the final status and status code

Another tip is to use redirects from old pages with redirect 301 and not redirect 302, which are not permanent.

8. Lost external links
   

External links remain a powerful signal for search engines, and it can simply be said that an excellent site with many organic links will often have a high positioning.

After a migration, it might be useful to contact the owners of sites that hosted backlinks to our old domain to ask them to update their links to the new site or to redirect links to similar pages on the new project.

Otherwise, the presence of broken links or pointing to pages of the old site not redirected to the new can cause problems with search rankings.

9. Platform / hosting issues
   

In case of moving of platform or server you have to pay attention to some small problems that could reduce the traffic of the site:

• Firewalls blocking search engine bots.
• Platforms that use JavaScript, which is harder to run for bots.
• Low speed and poor performance.
• Restrictions of the country.

In such cases, it is useful to carefully examine all pages that have had traffic drop, first trying to make a test drive of the platform or server again “before going all in and migrating your site”which may provide the information necessary to avoid subsequent problems.

10. Images

Another possible cause of reduced organic traffic are errors with image URLs, frequent when the site receives a lot of traffic from these resources. To avoid bad surprises, we need to be sure to link to the right images and the new correct domain.

When using a CDN network, it should be easy to make a quick change to transfer all images to the new site. If we use a CNAME to create image Urls, it is essential to verify that the CNAME is pointing to the new site and/or server.

11. Google updates
    

If in the previous cases the responsibility for the problems was at our expense (or at least for those who cured the migration), sometimes even the fate can put a hand in it: it is the case of transfers that arrive at the time of an update of the Google algorithm, which can therefore completely change the SERPs.

In such situation, therefore, the loss of ranking and traffic is not closely related to the migration, but depends precisely on the updates of the search engine.

How to solve problems and recover traffic

The collection and benchmarking of data before website migration takes place is crucial, says Ludwig Makhyan, who therefore recommends as a priority element to keep track of all changes before and after this delicate process.

The correction of all the problems of the site requires time and patience, “but the SEO always requires a long-term approach”: in concrete, it is necessary to examine the site, verify the presence of these problems and make the necessary corrections. When we are satisfied with the changes, then, we still have to wait a few days or weeks to see if the traffic returns to pre-migration levels.

If, after this period, the traffic will still be drastically lower than before the migration, you may need to ask for specialized support to find any annoying problems that we cannot identify.