Comment détecter les chaînes de redirections sur un gros site ?

Une redirection isolée ne coûte presque rien. Trois redirections en cascade coûtent trois requêtes, trois temps de réponse et une part de la confiance que le moteur accorde à l'adresse de départ. Sur un site qui a connu deux refontes, un changement de domaine et une réorganisation de rubriques, les chaînes de redirections se comptent souvent par centaines, sans que personne ne les ait décidées : chacune est le résultat de deux règles écrites à des années d'intervalle, dont les auteurs ignoraient l'existence de l'autre. Les trouver n'est pas difficile, mais demande de croiser plusieurs sources, car aucune ne contient à elle seule la totalité des adresses concernées.

D'où viennent les chaînes

Comprendre le mécanisme de formation évite de traiter les symptômes un par un pendant des années. Une chaîne naît toujours de la même manière : une adresse A est redirigée vers B, puis plus tard B est redirigée vers C, sans que la règle initiale soit mise à jour. Ce phénomène est cumulatif et silencieux, et il constitue l'une des dettes techniques les plus faciles à laisser grossir, comme nous le constatons régulièrement dans nos audits de la rubrique référencement naturel.

Les refontes successives

Chaque refonte apporte son jeu de règles, écrit à partir de l'état du site à ce moment là. Une adresse ayant traversé trois refontes traverse donc trois règles, dont chacune était correcte au moment de son écriture. Personne n'a commis d'erreur, et pourtant la chaîne existe. C'est la raison pour laquelle un contrôle ponctuel après chaque refonte ne suffit pas : le problème n'apparaît pas au moment de la mise en ligne, il apparaît à la refonte suivante, quand une règle ancienne devient le premier maillon d'une chaîne nouvelle.

La normalisation, qui ajoute un saut invisible

Une bonne partie des chaînes tient à des règles de normalisation empilées : passage en HTTPS, ajout ou retrait du sous domaine, ajout de la barre oblique finale, passage en minuscules. Chacune est légitime, mais leur ordre d'application décide du nombre de sauts. Une adresse ancienne en HTTP, sans barre finale et avec une majuscule peut ainsi subir trois redirections successives avant d'atteindre la page. La correction ne consiste pas à supprimer ces règles mais à les faire opérer en une seule fois, ce qui est presque toujours possible en réécrivant la condition plutôt que la destination.

Les redirections gérées par plusieurs couches

Sur un site un peu construit, plusieurs dispositifs peuvent rediriger : la configuration du serveur, une éventuelle couche de mise en cache en amont, l'application elle même, et parfois une extension dédiée. Chacun ignore ce que font les autres, et une même adresse peut traverser deux couches avant d'arriver. Ce cumul est particulièrement difficile à diagnostiquer depuis un navigateur, qui n'affiche que le résultat final, et c'est la raison pour laquelle l'observation doit se faire avec un outil qui montre chaque saut.

Les liens internes jamais mis à jour

La cause la plus fréquente n'est pas la règle mais le lien. Un lien interne pointant vers une ancienne adresse fait subir une redirection à chaque visiteur qui le suit et à chaque passage du robot, alors qu'il suffirait de corriger la cible du lien. Ce cas ne relève pas de la gestion des redirections mais du contenu, et il représente en général la majorité des redirections réellement subies sur un site, très loin devant les adresses appelées depuis l'extérieur.

Ce que coûte réellement une chaîne

Il vaut la peine de chiffrer le problème avant de s'y attaquer, ne serait ce que pour le prioriser correctement. Chaque saut ajoute un aller retour réseau complet, résolution du nom comprise si le domaine change, soit typiquement entre cent et trois cents millisecondes sur une connexion mobile. Une chaîne de trois sauts ajoute donc jusqu'à une seconde avant que la page ne commence à se charger, ce qui se voit directement dans les indicateurs de performance mesurés sur le terrain. Du côté du moteur, chaque saut consomme une unité d'exploration, et la documentation officielle indique que le robot suit un nombre limité de redirections successives avant d'abandonner, ce qui transforme une chaîne trop longue en page purement et simplement inaccessible.

Rassembler la liste complète des adresses à tester

La difficulté principale n'est pas de tester une adresse mais de savoir lesquelles tester. Aucune source ne contient l'ensemble, et se contenter d'une seule laisse dans l'ombre des familles entières, notamment les adresses anciennes qui ne figurent plus nulle part sur le site. Le raisonnement est le même que pour l'analyse du crawl exposée dans notre article sur la manière de calculer son budget d'exploration à partir des journaux serveur.

Le plan de site et l'exploration interne

Le plan de site donne les adresses que le site revendique, et l'exploration de proche en proche donne celles qu'il lie réellement. Les deux listes diffèrent toujours, et cet écart est déjà une information : une adresse liée mais absente du plan de site, une adresse déclarée mais que rien ne lie. Pour la question des redirections, ces deux sources apportent surtout les liens internes fautifs, ceux qui pointent vers des adresses redirigées, qui sont la cible de correction la plus rentable.

Les journaux du serveur

Les journaux contiennent ce qu'aucune autre source n'a : les adresses réellement demandées, y compris celles qui n'existent plus depuis dix ans et que des liens externes continuent d'appeler. Extraire de trente jours de journaux la liste des adresses distinctes ayant reçu une réponse de redirection donne immédiatement la population qui compte, celle qui est effectivement empruntée, pondérée par sa fréquence. C'est de loin la source la plus utile pour prioriser, puisqu'elle indique non seulement quelles chaînes existent mais lesquelles servent.

Les fichiers de règles eux mêmes

La liste des redirections déclarées se lit directement dans la configuration du serveur ou dans la table de l'extension qui les gère. Elle a l'avantage de donner les couples de départ et d'arrivée sans avoir à tester, ce qui permet de détecter par simple analyse les cas où la destination d'une règle est elle même l'origine d'une autre. Ce croisement, qui se fait en quelques lignes de script, révèle une bonne partie des chaînes sans envoyer la moindre requête, et il faut le faire avant tout test réseau.

Les sources externes

Restent les adresses appelées depuis l'extérieur, que ni le site ni ses journaux récents ne connaissent forcément. Les rapports de couverture et de liens des outils pour webmasters, les exports d'outils d'analyse de liens entrants et les anciennes listes issues de la précédente version du site complètent la population. Ces adresses sont souvent les plus anciennes, donc celles qui traversent le plus de règles, et elles portent parfois une valeur réelle par les liens qui pointent vers elles.

Attention aux redirections qui dépendent du contexte

Certaines redirections ne se déclenchent que dans certaines conditions : selon la présence d'un cookie, selon la langue annoncée par le navigateur, selon le type d'appareil, selon la position géographique déduite de l'adresse réseau. Un relevé effectué depuis un seul poste, avec un seul jeu d'en têtes, ne les verra jamais ou les verra toutes, selon les cas. Il faut donc mener le relevé au moins deux fois, une fois en se présentant comme un navigateur de bureau et une fois comme un téléphone, et sans cookie dans les deux cas. Les écarts entre les deux relevés méritent un examen systématique, car ils sont aussi le lieu où se cachent les configurations qui servent au robot une réponse différente de celle servie aux visiteurs.

Résoudre les chaînes et lire les résultats

Une fois la liste établie, la résolution consiste à suivre chaque adresse saut par saut, sans laisser l'outil faire le chemin pour soi. C'est là que les outils grand public induisent en erreur, en n'affichant que la destination finale, et c'est aussi là que se logent les cas les plus intéressants, décrits plus largement dans notre article sur les différences entre les redirections 301, 302 et 307.

Suivre les sauts un par un

La méthode consiste à demander l'adresse sans suivre automatiquement la redirection, à noter le code de réponse et la destination annoncée, puis à recommencer sur cette destination, jusqu'à obtenir une réponse finale. Chaque étape doit être enregistrée avec son code, ce qui produit pour chaque adresse de départ une trace complète. Il faut fixer une limite au nombre de sauts, sans quoi une boucle fait tourner le script indéfiniment, et traiter le dépassement de cette limite comme un résultat en soi.

Repérer les boucles et les impasses

Deux anomalies méritent un traitement immédiat. La boucle, où une adresse finit par revenir sur elle même, rend la page définitivement inaccessible et se détecte en conservant les adresses déjà visitées. L'impasse, où une chaîne aboutit à une erreur 404, est plus insidieuse : la redirection fonctionne, mais elle mène nulle part, ce qui est pire qu'une absence de redirection puisque le visiteur a attendu pour rien. Ces deux cas passent avant l'optimisation des chaînes courtes.

Distinguer le type de chaque saut

Une chaîne composée uniquement de redirections permanentes ne pose qu'un problème de longueur. Une chaîne qui comporte une redirection temporaire au milieu pose un problème de nature : le moteur traite les deux types différemment, et une temporaire laissée en place depuis trois ans envoie un signal qui ne correspond à aucune intention réelle. Le relevé doit donc conserver le code de chaque saut, et pas seulement leur nombre, car la correction diffère selon le cas.

Prioriser par le trafic, pas par la longueur

Une chaîne de cinq sauts sur une adresse que personne n'appelle mérite moins d'attention qu'une chaîne de deux sauts empruntée mille fois par jour. Croiser le relevé avec la fréquence issue des journaux, et avec le nombre de liens entrants connus, donne un ordre de traitement qui a du sens. Sur les sites que nous auditons, dix corrections bien choisies traitent régulièrement les trois quarts des redirections réellement subies, alors que la liste complète en compte plusieurs centaines.

Conserver la trace avant modification

Avant toute réécriture, le relevé complet doit être archivé tel quel, avec la date. C'est la seule référence disponible si une correction se révèle mauvaise, et c'est aussi ce qui permet de mesurer le résultat : sans état initial, l'affirmation selon laquelle les chaînes ont été supprimées ne repose sur rien. Ce fichier tient dans quelques centaines de kilooctets pour un site de dix mille adresses, et se conserve indéfiniment sans coût.

Corriger et empêcher la reformation

La correction elle même est simple, ce qui rend d'autant plus regrettable de devoir la refaire tous les deux ans. L'essentiel du travail consiste donc autant à aplatir l'existant qu'à installer ce qui empêchera les chaînes de se reformer.

Aplatir plutôt que supprimer

Corriger une chaîne consiste à réécrire la première règle pour qu'elle pointe directement sur la destination finale, et non à supprimer les règles intermédiaires, qui restent nécessaires pour les adresses qui les empruntent directement. Cette opération est mécanique et se scripte : à partir du relevé, on produit le nouveau jeu de règles, chaque origine pointant vers sa destination finale résolue. Le contrôle qui suit est indispensable, car une règle mal réécrite peut créer une boucle là où il n'y en avait pas.

Corriger les liens internes en priorité

Avant de toucher aux règles, il faut corriger les liens du site qui pointent vers des adresses redirigées, puisqu'ils sont responsables de la majorité des redirections réellement subies. Cette correction se fait dans le contenu, par un remplacement contrôlé, et elle a un effet immédiat sur le nombre de requêtes servies. Elle a aussi un effet secondaire appréciable : elle fait apparaître les liens qui pointaient vers des pages supprimées, dont personne n'avait remarqué qu'ils ne menaient plus à rien d'utile.

Vérifier ce que devient chaque famille

Une règle de redirection écrite avec une expression régulière peut couvrir des milliers d'adresses, dont certaines n'avaient pas été envisagées. Après réécriture, il faut donc tester non pas une adresse par règle mais un échantillon de chaque famille concernée, en incluant les cas particuliers : adresses avec paramètres, avec accents, avec majuscules, avec une barre finale. Ces cas sont exactement ceux qui produisent les régressions découvertes trois semaines plus tard par un client qui ne retrouve plus une page.

Installer un contrôle continu

La reformation des chaînes se prévient par un contrôle automatique, exécuté chaque semaine sur un échantillon d'adresses tirées des journaux, et qui signale toute adresse dont la résolution demande plus d'un saut. Ce contrôle tient en quelques lignes et coûte quelques secondes. C'est le seul moyen de découvrir en une semaine ce qui, sans lui, se découvre au prochain audit, c'est à dire deux ans plus tard, quand la correction est redevenue un chantier.

Documenter chaque règle au moment où on l'écrit

La dernière mesure est la plus simple et la plus négligée : consigner, à côté de chaque règle, la date, la raison et l'auteur. Une règle sans explication ne sera jamais supprimée, parce que personne n'osera prendre le risque, et le fichier grossira indéfiniment. Avec cette note, une revue annuelle permet de retirer les règles devenues sans objet, celles dont l'origine ne reçoit plus aucune demande depuis deux ans, ce qui maintient le dispositif à une taille où il reste compréhensible. Cette revue est aussi l'occasion de vérifier que les règles les plus anciennes servent encore : sur un site repris récemment, il n'est pas rare de trouver des centaines de lignes héritées d'une plateforme disparue depuis longtemps, dont aucune origine n'a reçu la moindre demande sur les douze derniers mois.

Traiter le cas du changement de domaine

Le changement de nom de domaine mérite une mention particulière, car il crée mécaniquement un saut supplémentaire pour toutes les adresses du site, et parce que la tentation d'y ajouter une réorganisation des chemins est forte. Faire les deux en même temps produit des chaînes sur l'intégralité du site et rend toute analyse ultérieure pénible, puisqu'il devient impossible de savoir si un écart vient du domaine ou du chemin. La règle qui simplifie tout est de transposer d'abord le site à l'identique sur le nouveau domaine, chemin pour chemin, puis de réorganiser les chemins dans un second temps, quelques semaines plus tard. Chaque adresse ne subit alors jamais plus d'une redirection à la fois, et chaque opération se contrôle séparément. Cette séparation en deux temps se documente dans le fichier de règles lui même, afin que la seconde opération ne soit pas oubliée une fois l'urgence passée et le trafic revenu à la normale.