Un millier de redirections, zéro 404 : l'audit qu'on fait après la migration
Un plan de redirection, ça ne se remplit pas une fois pour toutes. On a audité le nôtre avec un agent par langue, en croisant trois sources. Quatre familles de défauts, et une checklist réutilisable.
L’essentiel en bref
Notre plan de redirection comptait environ 800 lignes. Il en fallait plus d'un millier. Et parmi celles qui existaient, près d'une centaine menaient droit vers une page qui n'existait pas.
Je suis Jim. Deuxième épisode de l'après-migration Eurofiscalis. Dans l'article sur la migration de 2700 pages en 7 langues, j'ai expliqué ce qu'est une redirection 301 et comment prévoir le devenir de chaque ancienne adresse. Ici, je ne refais pas la leçon. Je raconte ce qu'on a trouvé quand on a vérifié notre propre plan, et comment on l'a vérifié.
Le problème : trois sources à confronter
Un plan de redirection, c'est un tableau. À gauche, l'ancienne adresse. À droite, la nouvelle. Simple. Sauf que pour savoir s'il est complet et juste, il faut le confronter à la réalité. Et la réalité, sur un site de cette taille, elle est éclatée en trois endroits.
Un, la liste des adresses du nouveau site. Près de 2 900 pages, toutes langues confondues. C'est là que les redirections doivent atterrir.
Deux, le crawl du site en ligne. Environ 2 800 adresses, relevées par le crawler que j'avais codé pour la migration. C'est ce que l'outil avait pu atteindre à cette date. Ce relevé ne prouve pas que Google connaît ou indexe chacune de ces adresses.
Trois, le plan de redirection lui-même, tenu dans notre tableau de bord de migration.
Aucune de ces trois sources ne suffit seule. Le plan ne sait pas ce qui existe en ligne. Le crawl ne sait pas ce qu'on a prévu. La liste du nouveau site ne sait pas d'où viennent les visiteurs. Le croisement permet de repérer les écarts et de les vérifier.
Un agent par langue
On aurait pu lancer un seul gros audit. On en a lancé sept : un agent IA par langue, coordonnés par un agent chef, avec les mêmes consignes et les mêmes trois sources.
Pourquoi découper par langue ? Plusieurs défauts que l'on avait repérés venaient de différences dans les adresses traduites. En allemand, le représentant fiscal s'appelait « Fiskalvertreter » dans l'ancien plan, et « Fiskalvertretung » sur le nouveau site : une vingtaine de redirections pointaient vers une adresse qui n'existait pas, à cause d'une simple terminaison. En anglais, même histoire entre « fiscal representative » et « fiscal representation ». En tchèque, des pages de taux avaient perdu leur année dans l'adresse.
Ce découpage aide à regrouper les écarts d'une même langue. Il faut ensuite contrôler les propositions et les correspondances entre langues.
Les quatre familles de problèmes
Au bout de l'audit, tout rentrait dans quatre familles.
Famille A : les redirections vers une page qui n'existe pas. Près d'une centaine. L'ancienne adresse redirigeait bien, mais vers une nouvelle adresse fausse. La redirection existait, mais elle n'amenait pas au contenu attendu. Il fallait corriger la destination et tester sa réponse.
Famille C : les pages en ligne sans aucun plan. Plusieurs centaines. Des pages bien vivantes sur l'ancien site, avec parfois du trafic, que personne n'avait prévu de rediriger. Le gros morceau : le glossaire tchèque, environ 250 définitions, dont la rubrique avait simplement changé de nom en route.
Famille B : les sources fantômes. Une dizaine de lignes correspondaient à des adresses que nos inventaires ne retrouvaient pas. Il fallait les vérifier avant de conclure qu'elles n'avaient jamais existé.
Famille D : les boucles. Une vraie boucle, où A renvoie vers B qui renvoie vers A. Et environ 160 fausses boucles : des pages qu'on avait décidé de garder, mais étiquetées « à rediriger » par erreur, qui se redirigeaient donc vers elles-mêmes sur le papier.
Le piège le plus sournois
La vérification de l'export a révélé un autre défaut.
Dans notre tableau de bord, une redirection pouvait exister de deux façons : comme une vraie redirection, ou comme une simple « cible prévue », une colonne où l'on notait l'adresse de destination. Sauf que seules les vraies redirections partaient à l'export. Une quarantaine de lignes n'existaient que dans cette colonne. Dans le tableau, elles avaient l'air parfaites. En production, elles n'auraient jamais existé. Ces adresses auraient donc été absentes de cet export de redirections.
C'est le même genre de bug que le faux positif silencieux du crawler : tout paraît vert, et c'est faux. Une information dans un tableur n'est pas une redirection. Il faut contrôler l'export, puis la règle réellement servie après déploiement.
Et quand l'outil ne veut pas te répondre
Petite anecdote au passage. Pour le tchèque, il fallait l'inventaire complet des pages de l'ancien site. Sauf que l'accès automatique à l'ancien WordPress était bloqué par une extension de sécurité, et que le crawl ne remontait qu'une partie des pages.
Pour compléter l'inventaire, j'ai copié-collé l'écran « Toutes les pages » de l'administration WordPress dans un tableur. Quelques centaines de lignes, nettoyées, classées par type. Ce relevé nous donnait une source supplémentaire à confronter au crawl.
Ce que ça a donné
Après corrections : les fausses boucles nettoyées, la centaine de cibles fausses repointées, les centaines de redirections oubliées ajoutées, la quarantaine de « cibles prévues » transformées en vraies redirections.
Sur le périmètre contrôlé à la fin de cet audit : un millier de redirections exportées, sans boucle, cible en 404, redirection sans cible ni doublon repéré. Ce constat décrit ce contrôle, pas l'absence de toute erreur possible sur le site.
L’indexation demande un suivi distinct dans Search Console, comme expliqué dans la méthode de migration. Une redirection qui mène à la bonne page ne confirme pas que Google l’a indexée.
Ce que je retiens
Sur ce projet, croiser les trois inventaires a fait apparaître des défauts que le tableau seul ne montrait pas. Le découpage par langue a aidé à les regrouper. La dernière vérification reste celle des anciennes adresses après déploiement : réponse HTTP, destination finale et contenu correspondant.
Questions fréquentes
Quand faut-il auditer un plan de redirection ?
Une redirection vers une page 404 est-elle grave ?
Pourquoi découper l'audit par langue ?
La suite
Après les adresses, on a aussi vérifié le contenu destiné à chaque pays. Certains passages traduits conservaient des références françaises. J'y reviens dans l'article suivant : quand la France fuit dans vos traductions.