Générateur de plan de redirections 301

Comment construire un plan de redirection qui tient

Un plan de redirection tient quand chaque ancienne URL de valeur atteint sa destination en un seul saut, vers une page qui traite du même sujet. Il se construit sur un inventaire croisé des anciennes adresses, jamais sur la mémoire de l'équipe ou sur le plan de site du nouveau projet. Le générateur ci-dessus écrit la syntaxe et relit la cohérence de la liste, mais c'est la qualité de l'inventaire qui décide du résultat.

Sur les refontes que je pilote, le tableur de correspondances arrive presque toujours trop tard, rempli dans la semaine de la bascule par quelqu'un qui n'a pas le temps de le relire. Cet outil ne remplace pas ce travail, il en supprime la partie mécanique : la traduction en syntaxe serveur, et la relecture des défauts qui ne se voient pas à l'œil dans un tableau de plusieurs centaines de lignes. La méthode complète, elle, est détaillée dans ma page sur le plan de redirection 301.

D'où vient la liste des anciennes URL

Trois sources alimentent la colonne de gauche, et aucune ne suffit seule. Prendre la première venue, c'est accepter de laisser des pages en dehors du plan sans savoir lesquelles.

Le bon geste est de fusionner les trois exports dans un même tableur, de dédoublonner sur la colonne des anciennes URL, puis de trier par valeur : trafic, positions, liens entrants. Une page orpheline qui ne reçoit plus un seul lien interne peut très bien concentrer des backlinks anciens, et c'est exactement le genre d'adresse qu'on oublie quand on se contente du crawl. Pensez aussi aux fichiers indexés, images et PDF, qui ont eux aussi une URL et disparaissent silencieusement.

Si la refonte s'accompagne d'un changement de nom de domaine, la logique reste la même, avec une contrainte de plus : les redirections partent d'un domaine qui doit rester actif et servi longtemps après la bascule.

Les erreurs qui coûtent du trafic

Trois défauts reviennent sur presque tous les plans que je relis. Ce sont les trois que l'outil traque en priorité.

Tout rediriger vers l'accueil. C'est la solution qui fait disparaître les 404 du rapport sans rien préserver. Google traite souvent ces redirections comme des soft 404, c'est-à-dire comme des pages introuvables déguisées, et la valeur de l'ancienne adresse ne se reporte pas. La règle que j'applique : chaque URL pointe vers la page la plus proche par le sujet, à défaut vers sa catégorie parente. Si aucune page ne convient et que l'adresse n'a ni trafic ni lien entrant, une 404 ou une 410 assumée vaut mieux qu'une redirection vers l'accueil.

Les chaînes de redirection. Elles apparaissent quand un plan se superpose à un ancien : une refonte précédente avait déjà déplacé la page, celle d'aujourd'hui la déplace encore, et personne n'aplatit le premier saut. Une chaîne ralentit le crawl, dilue le signal et allonge le temps de réponse pour le visiteur. Chaque ancienne URL doit atteindre sa cible finale en un seul saut, ce qui veut dire réécrire les règles anciennes plutôt que les empiler.

Oublier les variantes. Une même page est souvent atteignable avec et sans slash final, avec et sans www, en HTTP et en HTTPS, parfois avec une extension .html historique. Si vous ne traitez qu'une des formes, les autres tombent en 404 le jour de la bascule. La case à cocher du générateur couvre la variante avec et sans slash ; les variantes de protocole et de sous-domaine se traitent en amont, par une règle globale de canonicalisation.

Un dernier point de vigilance que l'outil ne peut pas couvrir : les URL à paramètres. Les directives générées portent sur le chemin, pas sur la chaîne de requête. Une adresse du type /produit?id=42 demande une règle spécifique, écrite à la main ou par votre hébergeur. L'outil recopie ces lignes telles quelles et vous le signale dans le bloc de sortie, mais il ne les résout pas à votre place.

Comment tester avant la bascule

Un plan qui n'a pas été exécuté n'est qu'une intention. Les contrôles automatiques de cet outil portent sur la cohérence de la liste : ils ne peuvent pas savoir si /blog/nouvel-article répond réellement en 200, puisque la page ne fait aucun appel réseau. Cette vérification-là se fait sur l'environnement de préproduction, avant la mise en ligne.

• Posez les règles sur la préproduction et lancez un crawler sur la liste complète des anciennes URL, en désactivant le suivi automatique des redirections pour voir le premier code renvoyé.
• Vérifiez que le code est bien 301 et pas 302 : certains CMS et certains plugins appliquent une temporaire par défaut, sans prévenir.
• Contrôlez le nombre de sauts. Une cible atteinte en deux étapes signale une chaîne que le plan n'a pas aplatie.
• Testez un échantillon des pages les plus stratégiques à la main, en regardant la page d'arrivée : une règle techniquement correcte peut mener au mauvais contenu.
• Rejouez le même contrôle juste après la bascule, en production, puis surveillez le rapport d'indexation les deux premières semaines.

Ce passage fait partie intégrante de la recette de la refonte, au même titre que les tests fonctionnels, et il conditionne le feu vert de la mise en production. Sur les projets où le plan de redirection reste un fichier que personne n'a exécuté avant le jour J, la découverte des erreurs se fait dans Search Console, avec plusieurs jours de retard et du trafic déjà perdu.

À propos de l'auteur

Laurent Tulpan

Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il pilote des refontes et des migrations à fort enjeu de trafic, et a écrit ce générateur à partir des contrôles qu'il menait à la main sur les plans de redirection de ses clients. Découvrir son approche.