Have you checked everything before carrying out your SEO migration?

Website migrations are risky stages in the life of a website. That is why it is crucial to manage these SEO projects with precision and to have an exhaustive checklist of the actions to carry out, so as to be sure not to lose visitors once the switch has actually taken place.

Foreword:

Swan was designed to spare webmasters, SEO consultants and website managers this kind of situation:

Example of a redirect project carried out without a checklist

The purpose of this checklist is therefore to help you make sure your traffic curve does not end up looking like the one above. Of course, if you do not have the time or the experience to follow all these steps manually, Swan will do it for you.

Save time on your website migration with Swan

The terms migration and redesign cover several concepts whose level of SEO risk can range from nil to dramatic. So let us start by detailing these different concepts. And, as you will see, contrary to a widespread belief, it is not only a question of whether or not the URLs are going to change. Of course, your case may well be a combination of several of these scenarios.

During a design overhaul, it may happen that only the colours and other properties of a stylesheet change. In that case there will be no URL change, and therefore no need for redirects.

The risk here is therefore nil!

Pro tip: Make sure the CSS does not hide certain internal linking areas, particularly on mobile (responsive design). In the long run this could affect the flow of internal PageRank and therefore affect rankings.

On the most common CMSs on the market, such as Magento, WordPress, PrestaShop, Drupal or Shopify, it can be very easy to switch themes quickly. Although this does not affect the URLs, it can quickly have undesirable side effects, including:

• A plugin or extension that generates new, useless URLs (hello spider trap...)
• A change in the flow of internal PageRank through the addition or removal of linking blocks

The risk here is therefore low

Pro tip: To make sure that the priorities of the pages in your internal linking are not altered, run a crawl of your site that calculates PageRank, so you can check that the pages most promoted by internal linking remain unchanged.

Pro tip 2: To REALLY secure things and go further, use Screaming Frog to make sure the anchors of your internal links remain identical. Depending on the theme, internal linking may remain intact in terms of the number of links, yet contextual anchors may turn into plain "click here" or "read more" buttons.

For performance reasons, or even purely contractual ones, a site may need to change hosting. In most cases this will simply be a replication of the data (databases and files from one server to the other).

The risk here is therefore low

Pro tip: Use a crawl to make sure no files are missing before switching the DNS, so as not to generate 404s.

Pro tip 2: Make sure the new server is at least as powerful as the previous one and that it is properly configured, so there is no drop in performance, whether for Googlebot or for your users.

Sites that are not yet equipped with an SSL certificate are increasingly rare, following Google's announcements insistently inviting e-merchants to make the transition to https. As a reminder, beyond Google's alarmist communication, https is only a very lightweight ranking signal. It has above all become a criterion for reassuring visitors, especially in the case of an e-commerce site.

If this switch from http to https is done in isolation, a single redirect rule (from http to https) will be enough to settle everything in one go.

The risk here is therefore low

Pro tip: Remember to crawl your site to make sure there is no mixed content (http resources called inside an https page)

Pro tip 2: Place your individual redirects before your bulk redirects. This will prevent Google from being redirected first to http and then to https. Your crawl budget will thank you!

This case is generally a version upgrade of WordPress, Magento, PrestaShop, Shopify or any other CMS. Here, as with the change of graphic theme, the main thing is to make sure there is no change in the technical components or in the internal linking. During a technical overhaul, choices may be made to remove features, which once again leads to a change in internal linking or to the removal of URLs.

The risk here is therefore low

You have bought a site and the domain name is not relevant, so you have to change it? A trademark issue forces you into a migration, or some other reason obliges you to change domain name, and you are worried? Well, think again: this case is less dramatic than it first appears. Potentially, only the root of the domain name changes here, so it is a case close to the switch from http to https. The only difference is that you will have to make sure you keep ownership of the old domain name, the related redirects and its dedicated SSL certificate where applicable.

The risk here is therefore moderate

Pro tip: to find out more, we invite you to read this article on how long to keep redirects in an SEO redesign project.

For reasons of technical complexity, a change of CMS unfortunately comes with many URL changes, whether through the addition or removal of ".html" at the end of URLs or through the addition of mandatory URL keys. For example, in Shopify all content pages start with the slug "pages" and do not accept sub-directories the way other CMSs do.

The risk here is therefore high

Pro tip: Read this entire tutorial carefully (or use Swan!). It may seem a trivial "tip", but this is one of the two cases that require the most experience, so you need to do it as cleanly as possible and forget nothing.

Make your change of CMS easier with a simple, secure migration. Find out how with Swan.tools.

Let us end this list with what is probably the most complex case. This is the situation where you have bought a site in your sector to strengthen or extend your business. Since there is every chance that the back-end technologies are different and that your content is at least partially duplicated, you find yourself in a mix of the various situations mentioned above.

The risk here is therefore high

Pro tip: This is a very complex task to carry out by hand without forgetting anything, especially if the sites contain many pages. It is, however, one of the tasks that Swan handles automatically with great ease. The real solution, in terms of safety and time saved, is therefore to use Swan.

Interim conclusion: As you can see, there are many cases. Before embarking on a manual operation, there is still time to create an account on Swan and rely on the tool, so you do not get lost in endless Excel files.

We are now going to look at all the checkpoints to verify during a redesign or a migration, to be sure you forget nothing and do not wreck the rankings of your website's pages. And, as you will see, even though it is an important part, it is not only about gathering the URLs.

For your information, all these steps are made much easier by Swan, whether for normalising URLs, sorting out irrelevant URLs, or quite simply deduplicating them.

This is one of the most important steps! To do this you can (and must!) use as many of the tools at your disposal as possible:

• Google Search Console
• Babbar.tech
• Majestic
• Ahrefs
• Semrush
• Moz

And any other tool you usually use to manage the inbound links to your website. As Swan does, simply remember to deduplicate your lists if they are long, so you do not do the work several times over. The pages that receive links are probably the most important ones at the time of a website redesign, because they are the ones that carry the power (PageRank) passed on by the other websites linking to you. They are also the ones that will need to keep a redirect for as long as possible. To find out more: see our article on how long to keep redirects after a migration.

Warning: during a redesign, there are often pages that generate traffic without necessarily receiving links or being discovered by a standard crawl of your website. These are known as orphan pages. To be certain of not forgetting any, we recommend retrieving all the pages that have generated visits in the last 6 months in Google Analytics (or any other website tracking software) as well as in Google Search Console.

This exhaustive page discovery step comes third because it is the one that will reveal new pages that do not necessarily have an immediate SEO effect. These pages certainly play a leading role in internal linking and therefore in the related PageRank, but they have no direct role in the site's traffic. As we said in the article on redirect durations mentioned above, the redirects of these pages can therefore be kept for a shorter time.

Fewer and fewer websites rely on SEO alone. It is therefore important to check carefully that the pages linked to your Google Ads, Facebook Ads, Bing Ads and other campaigns are carried over in your migration plan. This will save you from spending advertising budget on visitors who would land on a 404 page.

Not all the pages that need redirects are necessarily available on the front end or through tools. Sometimes the only way to find them is through log analysis. Be careful, however, in this log analysis to keep only the logs coming from SEO bots (Bingbot, Googlebot, etc.). You will thus potentially obtain a list of URLs that carry credibility for Google but that were ignored by your predecessors on this project.

Never miss your SEO migration again with our advanced semantic analysis tool that guides you towards the best redirects for your site.

If the server changes, it is important to make sure it has at least the same capacity in terms of load handling. All the more so because, if you are doing a redesign, it is most likely to welcome even more users to your website, and not only from SEO.

On e-commerce websites or web projects with large databases, it is very likely that technical settings have been made at MySQL level. Remember to ask your sysadmin or your devops to check that they have been replicated on the new server.

Also be careful to carry out this check if you are only changing CMS. Imagine moving from an almost static site to a technical CMS that is functionally rich but complex in terms of infrastructure and hungry for resources: the server must remain suited to welcoming an equivalent number of visitors to your website.

These various checks can be carried out with tools such as JMeter (provided by the Apache Foundation), which allow you to run what are known as load tests or stress tests.

The TTL of a DNS record of a domain name is how long DNS servers (in particular the resolvers of internet service providers) keep it in their cache. The idea is to lower it as far as possible a few days before a migration, so that the switch is taken into account as quickly as possible.

During a domain name or server migration, it can happen that the HTTPS (SSL) certificates are forgotten, all the more so as the browser cache can hide the problem during testing. It is therefore important to prepare the certificates properly on the new server, while making sure that the certificates linked to the old domain will continue to be renewed (domain and www sub-domain). Understanding the importance of redirects is crucial for SEO migration. Learn how WWW redirects can influence your site's rankings.

Even if the old domain name will no longer have any content, it is important to keep renewing it, because it receives and relays links (backlinks) from other sites. So make sure you activate the automatic renewal of your old domain name, so you never have to think about it again.

The question that often comes up is: where to place your redirect plan? The tests we have carried out prove it: redirects should go first and foremost in the hosting configuration files, the Apache vhost, the Nginx configuration, Varnish at worst, while the .htaccess file or redirects stored in the database should only be kept as a last resort.

Optimise your website migration with semantic SEO analysis thanks to Swan.tools!

It cannot be said often enough: to limit the SEO risk of a website redesign, do not change the URLs. A well-designed redirect plan is essential to preserve your rankings but unfortunately, as mentioned above, this is often easier said than done. And when you have to embark on a redirect plan with many special cases for each page URL, that is where Swan's strength comes into play once again.

This is one of the important points for search engines: reducing the number of intermediate redirects. That is, when you detect that page A points to page B and then to page C, you need to redirect page A to page C. Paradoxically, if you gather all the pages using the method described above, you will easily be able to apply this principle. Here you will need to make sure you do not keep any intermediate redirect file.

An important point to remember is that the most specific redirects (one page to one page) must be implemented first, finishing with the most generic redirects (http to https, for example).

First of all, this is a task that can prove very long if the website contains many different pages. Searching for matching content can be very time-consuming.

Case 1: the marketing approach. It is certainly worth taking into account, redirecting pages according to the same marketing target. However, it must be weighed against what you know about SEO. If a page for the target search intent used to be a page with a lot of text and an editorial signal, there is every chance that, to avoid losing effectiveness, you will need to aim for a similar page, or even one that takes over the full text.

Case 2: the SEO approach. Here we focus on the content, because it plays a central role. This is in fact what Swan does: the tool relies on the semantic similarity of the content (and not a simple Jaccard index that would count the words in common). In the vast majority of cases, Swan's engine therefore suggests the choice the search engine expects: the semantic shift towards the closest content. You then approve or correct each suggestion. The ideal strategy is to favour a manual choice for the website URLs that receive the most links and traffic, then automate the rest.

To write to us: support@swan.tools.

Save time on your website migration with Swan

The aim here is to use the list of URLs identified earlier, replace the root of the domain name with the new one (a find and replace in Excel or in a text editor will do the job) and test all these URLs in list mode in Screaming Frog. You will then be able to check the HTTP status codes returned by these URLs. In theory you should only see the following codes in the list, depending on the decisions you have made:

• 200 (unchanged URLs)
• 301 or 302 (redirected URL, although 302 is less likely here)
• 410 (abandoned URL)

Any other code would be a sign of an error

Nothing very complex here: it is just a matter of remembering to set up Google Search Console on the new domain name (and declare the change of address there) and also to switch Google Analytics 4 to the new domain name while keeping the same property (you only need to update the URL of the data stream). It would be a shame to lose the data history, or even simply to have no visitor data for a while because of an unfortunate oversight.

The mistake often made after a migration is to focus on the desire for fast indexing of the new URLs. If this is not accompanied by the discovery of the redirects from the old URLs, you are simply extending a period of duplicate content. It is therefore important to help Google discover the redirects properly. For that, nothing beats encouraging it to recrawl these old pages, and there are two solutions for that:

Case 1: the XML sitemap

You create an XML sitemap containing only the old URLs and submit it in Search Console. At the very least, this will let you follow the progress of the deindexing of the old ones.

Case 2: the HTML sitemap

The idea here is to create an HTML sitemap-type page, request its indexing (URL inspection in Search Console) and link to it from your footer for a while. This will encourage crawling by Google. The trap here is to remember to remove this page after 2 or 3 months, once Google has processed everything (to prevent it from reindexing them)

You now have all the knowledge you need to succeed in your SEO website migration. So what will you choose: the manual method, or would you rather secure it and save time with Swan?

Save time on your website migration with Swan