Le plan de redirection est une des étapes stratégiques de la refonte. Il est la principale liaison entre votre ancien et nouveau site. Au niveau SEO, ces redirections permettent de renvoyer la visibilité et la popularité. Ce fichier est donc un des points de passage les plus importants de la refonte. Une erreur dans le fichier, la présence de redirection en cascade… Et c’est la visibilité du site qui est impactée.
Découvrez les bonnes pratiques et astuces pour construire son plan de redirection et ainsi limiter les risques de perdre du trafic.
Identification & Qualification des URLls
Avant toute chose, il faut revenir sur le principe de redirection. Le plan de redirection est un ensemble de redirections en 301 d’une page A vers une page B. En cas d’erreur sur une redirection, si le correctif intervient quelques jours plus tard, la visibilité et la popularité sont perdues. Il est donc essentiel de répertorier les bonnes URLs et de faire le bon matching.
Quelles sont les urls à inclure ?
Le plan de redirection doit contenir toutes les pages ayant de la popularité et du trafic. Pour avoir le listing le plus exhaustif possible, il va falloir aller récupérer des données de sources différentes (Analytics, Majestic,…). Néanmoins, selon la volumétrie du site, vous pourrez inclure entre 80% à 95% des URLs dans votre plan de redirection.
Ce chiffre peut surprendre, mais sur des sites on retrouve systématiquement des pages ne générant aucune visite depuis plus 1 an et que Google crawle peu souvent. Ce type d’URLs peut alors passer au travers de cette qualification, mais il faudra les analyser pour s’assurer de ne pas déséquilibrer le maillage interne. Selon leur pertinence, on définira si oui ou non elles sont redirigées.
Autres URLs à identifier, les pages que l’on veut supprimer. Ces pages seront à isoler afin de renvoyer un code de réponse 410.
Puis on termine cette étape avec les redirections existantes. Une mise à plat sera nécessaire afin d’identifier les 301 que l’on conserve et qu’il faudra mettre à jour de celles que l’on passera en 410.
L’objectif du plan de redirection en SEO est de s’assurer d’avoir toutes les URLs générant de la visibilité.
Les outils à utiliser pour faire son plan de redirection
Pour avoir un listing le plus complet possible, on récupère les URLs depuis plusieurs sources : Crawl du site, Analytics, Majestic, Extraction des logs…
Crawl du site : à l’aide de crawler tel que Screaming Frog, vous récupérerez les URLs maillées sur le site. Dans la majorité des refontes, le crawl permet d’obtenir les URLs prioritaires et toutes les URLs maillées, mais le listing n’est pas exhaustif.
Analytics : Cet outil vous permet de récupérer des URLs qui ont des visites, mais elles ne sont pas nécessairement toutes maillées au site tel que les URLs de Newsletters ou LP marketing.
Autre avantage de cette extraction, elle va vous permettre de qualifier les URLs du crawl. La notion de visites vous sera utile pour arbitrer les redirections.
Majestic : Les URLs obtenues par cet outil sont importantes étant donné qu’il s’agit de pages obtenant un lien externe. Ainsi, les URLs ayant un bon backlink sont à rediriger.
Ce fichier vous permettra également d’identifier les backlinks qui seront à récupérer/modifier après la refonte.
Search console : cet outil de Google est une véritable mine d’informations. On peut, via l’API ou Data Studio, récupérer un nombre important d’URLs.
Par ailleurs, la Search console ajoute des données complémentaires permettant d’apprécier la qualité et la pertinence de la page telles que le CTR ou le nombre d’impression.
Extraction des logs : en tant que SEO les logs sont une information essentielle, surtout pour les sites à forte volumétrie. Quand on récupère les logs, on sait avec précision les pages qui sont crawlées et visitées par les bots. Idéal pour identifier les pages orphelines, URLs non maillées à la structure du site que Google continue de voir !
Après collecte de toutes ces informations, il ne vous reste plus qu’à dé-doublonner les URLs et les qualifier avec des indicateurs : nombre de visites, Trustflow / Citationflow, priorité marketing, etc.
Au moment de la réalisation de cette étape, je vous incite fortement à inclure l’équipe marketing et/ou Edito. La refonte est souvent l’occasion d’améliorer des URLs qui performent peu.
Chaque refonte est unique, dès le démarrage du projet il faut prévoir cette étape, car la structure d’URL peut évoluer ou être totalement changée. Il est donc important d’y réfléchir avant pour minimiser les risques et simplifier le matching.
Pourquoi ?
Pour vous illustrer le propos, voici des cas de figure où les URLs peuvent évoluer :
- Changement d’arborescence
- Changement de CMS
- Correction orthographique ou suppression de « stop words » (de, la, le…)
L’objectif est d’identifier un point de repère entre l’ancienne et la nouvelle URL, bien souvent on reprend l’ID de l’URL. Des CMS comme Prestashop ou Magento incluent dans les URLs des ID. Ce chiffre peut être réutilisé afin de l’inclure dans la nouvelle URL ou dans un champ dans le back-office.
Cette méthode peut paraître anodine, mais cela vous évitera de faire le matching sur les URLs concernées et vous simplifiera la vie !
Configuration / implémentation
Maintenant que vous connaissez le nombre d’URLs et que vous avez inclus dans votre cahier des charges les prérequis au matching, il faut demander à l’équipe technique où et comment vous allez intégrer le plan de redirection.
La question peut paraître simple, mais cela vous permettra de déterminer le format et la structure du fichier. Ainsi, selon les besoins et votre serveur, l’intégration du plan de redirection peut évoluer entre l’installation de module de redirection, l’ajout sur le serveur ou la création d’une MAP.
Implémentation sur le serveur
Sur le marché, les 3 serveurs Web les plus utilisés sont Apache, Nginx et IIS.
Selon votre configuration, le développeur devra adapter l’écriture du plan de redirection
- Apache
On peut intégrer des redirections sur le fichier de configuration serveur ou le htaccess, sachant que le fichier config est prioritaire au htaccess.
Dans la pratique, on a tendance à écrire ligne par ligne dans le htaccess. Pourtant, Apache permet d’optimiser la gestion des redirections via la création d’une MAP et l’utilisation de fichiers en .dbm.
- NGINX
Le fonctionnement est similaire à Apache où les redirections peuvent être inscrites sur le fichier de configuration « nginx.conf » via la commande rewrite. La seule différence se fera l’usage de la commande rewrite cumulée à return.
- IIS
Ce serveur a également un fonctionnement proche d’Apache, la différence majeure sera sur l’Htaccess, ce fichier n’existe pas sur IIS. Toutefois, on peut utiliser des rewrite maps pour gérer les redirections.
Implémentation via un module
Avec des CMS comme WordPress, Drupal, Prestashop ou encore Magento, il existe de nombreux modules qui permettent aux Webmasters ou contributeurs de gérer les redirections sans passer par la modification sur le serveur. Les modules sont une bonne alternative pour gagner en autonomie. Néanmoins ils peuvent être source d’erreurs, cette solution doit donc être utilisée pour des sites ayant une petite volumétrie de pages.
Désormais vous êtes en capacité d’identifier, qualifier vos URLs et de valider le mode d’intégration du plan de redirection. Cette méthodologie peut s’appliquer à tous les sites, il faut quand même rester très attentif, car des erreurs sur le plan de redirection peuvent vite arriver.
Faire le matching & tests
Le matching, correspondance entre les URLs, est une étape qui nécessite un travail manuel. Cette dernière étape de la construction de fichier sera également l’une des dernières actions à réaliser sur la wwww, et pour cause, le matching se fait à la fin.
Le dernier livrable
Le plan de redirection se construit en 2 temps : phase de qualification et la phase de livraison, et cette dernière se fait à la fin de votre projet pour limiter les erreurs sur le matching. En effet, il est impératif que vos URLs proviennent du site en wwww terminé. J’insiste sur le mot « terminé », car lors des phases de recettage marketing et SEO, on remarque systématiquement des correctifs à apporter aux URLs comme de la correction orthographique de pattern/mot, la suppression de stop word non identifiée, la reformulation d’un répertoire, etc. Vous pourrez faire le matching qu’après l’intervention du consultant SEO sur la wwww et l’intégration des correctifs.
Pour s’assurer que le plan de redirection fonctionnera après la mise en production, il faut le tester quelques jours avant la bascule. Cela permet d’identifier des incohérences sur les règles d’écritures ou des erreurs sur des lignes.
Par ailleurs, même si on sait comment il faut faire un plan de redirection, il existe des paramètres extérieurs pouvant créer des erreurs inattendues.
Les erreurs à éviter
Pour limiter la prise de risque lors de la construction du plan de redirection, je vous partage des cas de figure où le plan de redirection n’est pas aussi simple que cela puisse paraître.
- Plan de redirection sur un environnement non terminé
Lors du process de refonte, il est tentant d’avoir le plan de redirection tôt le plus tôt possible. Dans cette situation, on peut vouloir construire son fichier avec :
- la structure d’URLs élaborée en début de refonte : ce fichier permet d’indiquer la forme/écriture de l’URL définitive. On peut donc avoir envie d’utiliser cette information pour créer le plan de redirection sur cette « structure ».
- la wwww « presque » terminée : on veut avancer sur le plan de redirection en attendant la fin de développement. On utilise alors les URLs qui auront été crawlées à un instant T sur une version de site non figée.
Dans les 2 situations évoquées, le risque d’erreurs est important. Même si on anticipe sur la structure d’URLs ou que l’on crawle une wwww non terminée, il y a toujours des modifications de dernière minute. Toutes ces infimes corrections entraînent alors des erreurs sur de nombreuses lignes de votre fichier. C’est pourquoi il est impératif de faire son plan de redirection sur une wwww terminée et figée.
- Changement de périmètre
Les redirections les plus simples sont celles de A vers B, autrement dit une URL /XYZ.html qui devient /XYZ/. Sauf que lors d’une refonte, on en profite pour supprimer ou fusionner des URLs. Cette situation rend alors caduc le schéma URL A vers B. Vous rentrez alors dans la configuration URL A, C, D, E qui vont renvoyer vers B.
Par conséquent, la fusion amène à faire le matching ligne par ligne avec une vérification manuelle ; quand votre site fait plusieurs milliers de lignes, cela prend du temps.
Autre point à souligner, un changement de périmètre entraîne dans la majorité des cas une baisse de visibilité.
- Refonte avec passage HTTPS
Ce cas de refonte nécessite de la rigueur et de l’attention sur l’intégration du plan de redirection. En théorie cela paraît simple, mais en pratique la marge d’erreur est plus forte, car vous allez devoir faire une redirection en cascade maîtrisée.
Prenons l’exemple sur l’URL http://www.nomdomaine.fr/xyz.html, elle va devoir aboutir à https://www.nomdomaine.fr/xyz/ et pour y parvenir, vous allez avoir besoin de créer 2 redirections. Il est fréquent lors des phases de tests d’avoir le schéma suivant : HTTP > HTTPS > HTTP URL nouveau format > HTTPS URL nouveau format, nous obtenons alors 3 redirections au lieu de 2.
- Changement de CMS ou d’arborescence
Ce point a été abordé un peu plus haut, lors d’un Changement de CMS ou d’arborescence, la structure d’URL peut être totalement transformée.
Il faut donc réussir à conserver un ID ou identifier un dénominateur commun pour faciliter le matching des URLs. Le cas échéant, le plan de redirection va nécessiter du temps, car il faudra réaliser le matching ligne après ligne.
La construction d’un plan de redirection peut paraître simple et pourtant dans son élaboration et son intégration, il peut y
avoir de nombreuses erreurs pouvant impacter la visibilité du site. La méthodologie présentée peut s’appliquer à tous les sites, il faut tout de même prévoir dans son retroplanning le temps nécessaire au plan de redirection tant sur la construction que sur la réalisation de points de contrôle avant bascule. En fonction de la volumétrie du site, le temps alloué peut être de plusieurs jours à plusieurs semaines. La réussite d’une refonte passe aussi par le plan de redirection, il est le vecteur permettant de transmettre le trafic et la visibilité d’un site/URL à un autre.
Mettre de nombreuses redirections 1:1 dans le fichier .htaccess ne dégrade pas le TTFB !
L’ajout d’un grand nombre de redirections aurait un impact sur le Time To First Byte, ou TTFB.
Le TTFB est le temps qu’un serveur met pour rassembler ses données et envoyer quelque chose au navigateur d’un internaute. Cela inclut la vérification du fichier .htaccess pour voir s’il existe des règles qui s’appliquent à l’URL demandée par l’utilisateur.
Nous avons toujours entendu parler des redirections 1:1 qui seraient préjudiciables à la vitesse d’un site. Une redirection 1:1, c’est lorsque vous écrivez une règle de redirection dans le fichier .htaccess qui indique «Redirect 301 / 1stURL / / 2ndURL /». Comme chaque ligne est une simple redirection, vous pouvez vous retrouver avec une longue liste dans le fichier .htaccess, qui doit être analysé dans sa globalité à chaque requête client (voir schéma simplifié ci-dessous).
L’étude fait par SEOMike a permis de démontrer que l’impact est négligeable sur le TTFB en dessous de 40 000 lignes de redirections 1:1 dans le fichier .htaccess.
Il est donc possible de définir un nombre important de redirections 1:1 (lors d’une migration par exemple) sans altérer le TTFB.
. D’autres pistes d’optimisation sont donc à travailler en priorité.