The redirection plan is one of the strategic stages of the overhaul. It is the main link between your old and new site. At the SEO level , these redirects allow you to return visibility and popularity. This file is therefore one of the most important crossing points in the overhaul. An error in the file, the presence of cascading redirection… And it is the visibility of the site that is impacted.
Discover the best practices and tips for building your redirection plan and thus limit the risks of losing traffic.
IDENTIFICATION & QUALIFICATION OF URLLS
First of all, we must come back to the principle of redirection. The redirect plan is a set of 301 redirects from page A to page B. If there is an error on a redirect, if the fix comes a few days later, visibility and popularity are lost. It is therefore essential to list the right URLs and to match them correctly.
WHAT ARE THE URLS TO INCLUDE?
The redirect plan should contain all pages with popularity and traffic. To have the most exhaustive listing possible, it will be necessary to go and retrieve data from different sources (Analytics, Majestic, etc.). However, depending on the size of the site, you may include between 80% to 95% of the URLs in your redirection plan.
This figure may be surprising, but on sites we systematically find pages that have not generated any visits for more than 1 year and that Google crawls infrequently. This type of URL can then pass through this qualification, but it will be necessary to analyze them to ensure not to unbalance the internal mesh. Depending on their relevance, we will define whether or not they are redirected.
Other URLs to identify, the pages you want to delete. These pages will have to be isolated in order to return a response code 410.
Then we end this step with the existing redirects. A flattening will be necessary in order to identify the 301s that we keep and that it will be necessary to update those that we will pass in 410.
The goal of the SEO redirection plan is to make sure you have all the URLs that generate visibility.
THE TOOLS TO USE TO MAKE YOUR REDIRECTION PLAN
To have the most complete listing possible, we retrieve the URLs from several sources: Site crawl, Analytics, Majestic, Log extraction, etc.
Site crawl: using a crawler such as Screaming Frog, you will retrieve the meshed URLs on the site. In the majority of redesigns, the crawl makes it possible to obtain the priority URLs and all the meshed URLs, but the listing is not exhaustive.
Analytics : This tool allows you to retrieve URLs that have visits, but they are not necessarily all meshed with the site such as Newsletters or LP marketing URLs.
Another advantage of this extraction, it will allow you to qualify the crawl URLs. The notion of visits will be useful for you to arbitrate redirects.
Majestic : The URLs obtained by this tool are important since these are pages that obtain an external link. Thus, URLs with a good backlink are to be redirected.
This file will also allow you to identify the backlinks that will be retrieved / modified after the redesign.
Search console : this Google tool is a veritable mine of information. You can, via the API or Data Studio, retrieve a large number of URLs.
In addition, the Search console adds additional data to assess the quality and relevance of the page such as the CTR or the number of impressions.
Log extraction : as an SEO, logs are essential information, especially for high volume sites. When we retrieve the logs, we know precisely the pages that are crawled and visited by the bots. Ideal for identifying orphan pages, non-meshed URLs to the site structure that Google continues to see!
After collecting all this information, all you have to do is de-duplicate the URLs and qualify them with indicators: number of visits, Trustflow / Citationflow, marketing priority, etc.
When completing this step, I strongly encourage you to include the marketing and / or Editorial team. The redesign is often an opportunity to improve URLs that perform poorly.
Each redesign is unique, from the start of the project this step must be planned, because the URL structure can evolve or be completely changed. It is therefore important to think about it beforehand to minimize the risks and simplify the matching.
To illustrate the point, here are some cases where URLs can change:
- Tree change
- CMS change
- Spelling correction or deletion of “stop words” (de, la, le…)
The objective is to identify a point of reference between the old and the new URL, very often we take the ID of the URL. CMS like Prestashop or Magento include IDs in the URLs. This number can be reused to include it in the new URL or in a field in the back office.
This method may seem trivial, but it will prevent you from doing the matching on the URLs concerned and will simplify your life!
CONFIGURATION / IMPLEMENTATION
Now that you know the number of URLs and that you have included the prerequisites for matching in your specifications, you must ask the technical team where and how you will integrate the redirection plan.
The question may seem simple, but it will allow you to determine the format and structure of the file. Thus, according to the needs and your server, the integration of the redirection plan can evolve between the installation of the redirection module, the addition on the server or the creation of a MAP.
IMPLEMENTATION ON THE SERVER
On the market, the 3 most used web servers are Apache, Nginx and IIS.
Depending on your configuration, the developer will have to adapt the writing of the redirection plan
We can integrate redirects on the server configuration file or the htaccess, knowing that the config file takes priority over htaccess.
In practice, we tend to write line by line in the htaccess. However, Apache makes it possible to optimize the management of redirects via the creation of a MAP and the use of .dbm files.
The operation is similar to Apache where redirects can be written to the “nginx.conf” configuration file via the rewrite command. The only difference will be the use of the cumulative rewrite command at return.
This server also works similar to Apache, the major difference will be on Htaccess, this file does not exist on IIS. However, you can use rewrite maps to handle redirects.
IMPLEMENTATION VIA A MODULE
With CMS like WordPress, Drupal, Prestashop or Magento , there are many modules that allow Webmasters or contributors to manage redirects without going through the modification on the server. Modules are a good alternative to gain autonomy. However, they can be a source of errors, so this solution must be used for sites with a small volume of pages.
Now you are able to identify, qualify your URLs and validate the integration mode of the redirection plan. This methodology can be applied to all sites, but you still have to be very careful, because errors in the redirection plan can quickly happen.
DO THE MATCHING & TESTS
Matching, correspondence between URLs, is a step that requires manual work. This last step of the file construction will also be one of the last actions to be carried out on the wwww, and for good reason, the matching is done at the end.
THE LAST DELIVERABLE
The redirection plan is built in 2 stages: qualification phase and the delivery phase, and the latter is done at the end of your project to limit errors on matching. Indeed, it is imperative that your URLs come from the finished wwww site. I insist on the word “finished”, because during the marketing and SEO acceptance phases, we systematically notice corrections to be made to URLs such as pattern / word spelling correction, the removal of unidentified stop word, the reformulation of ‘a directory, etc. You will be able to do the matching only after the intervention of the SEO consultant on the wwww and the integration of the fixes.
To make sure that the redirection plan will work after going live, it needs to be tested a few days before the switchover. This makes it possible to identify inconsistencies in the writing rules or errors on lines.
Moreover, even if we know how to make a redirection plan, there are external parameters that can create unexpected errors.
MISTAKES TO AVOID
To limit the risk taking when building the redirection plan, I share with you cases where the redirection plan is not as simple as it may seem.
- Redirection plan on an unfinished environment
During the redesign process, it is tempting to have the redirection plan early as early as possible. In this situation, you may want to build your file with:
- the URL structure developed at the start of the redesign: this file is used to indicate the form / writing of the final URL. We may therefore want to use this information to create the redirection plan on this “structure”.
- the wwww “almost” finished: we want to move forward on the redirection plan while waiting for the end of development. We then use the URLs which will have been crawled at an instant T on a non-fixed version of the site.
In the 2 situations mentioned, the risk of errors is high. Even if we anticipate the URL structure or crawl an unfinished wwww, there are always last minute changes. All these tiny corrections then lead to errors on many lines of your file. This is why it is imperative to make your redirection plan on a finished and frozen wwww.
- Change of scope
The simplest redirects are those from A to B, in other words a URL /XYZ.html which becomes / XYZ /. Except that during a redesign, we take the opportunity to delete or merge URLs. This situation then renders the URL A to B scheme null and void. You then enter the URL A, C, D, E configuration which will refer to B.
Consequently, the merger leads to making the matching line by line with a manual verification; when your site has several thousand lines, it takes time.
Another point to underline, a change of perimeter leads in the majority of cases to a loss of visibility.
- Redesign with HTTPS passage
This case of redesign requires rigor and attention to the integration of the redirection plan. In theory this sounds simple, but in practice the margin of error is greater, because you will have to do a controlled cascade redirection.
Let’s take the example on the URL http://www.domainname.fr/xyz.html , it will have to lead to https://www.domainname.fr/xyz/ and to achieve this, you will need to create 2 redirects. It is common during the test phases to have the following diagram: HTTP> HTTPS> HTTP URL new format> HTTPS URL new format, we then get 3 redirects instead of 2.
- Change of CMS or tree structure
This point was discussed a little above, when changing CMS or tree structure, the URL structure can be completely transformed.
It is therefore necessary to succeed in keeping an ID or identifying a common denominator to facilitate the matching of URLs. If necessary, the redirection plan will take time, because it will be necessary to carry out the matching line after line.
The construction of a redirection plan may seem simple and yet in its development and integration, there can
be many errors that can impact the visibility of the site. The methodology presented can be applied to all the sites, it is nevertheless necessary to plan in its retroplanning the time necessary for the redirection plan both on the construction and on the realization of check points before switching. Depending on the size of the site, the time allocated can be from several days to several weeks. The success of a redesign also depends on the redirection plan, it is the vector allowing to transmit the traffic and the visibility of a site / URL to another.