Refonte : le plan de redirections, ligne par ligne.

Une refonte ne fait pas perdre le référencement. Un plan de redirections bâclé, si. Et l’écart entre les deux ne se joue pas le jour de la bascule : il se joue trois semaines avant, quand on décide ce que devient chaque ancienne adresse.

Cet article décrit la méthode que nous appliquons, y compris les pièges que nous avons rencontrés en refondant un site de 1 257 pages. Les chiffres cités viennent de ce chantier.

Pourquoi les positions tombent après une refonte

Presque jamais à cause du design. Dans l’immense majorité des cas, la cause est l’une de ces quatre, et elles se constatent dans les journaux du serveur, pas dans une intuition.

• Une adresse qui disparaît sans destination. Elle rend un 404, Google la retire, et les liens qui pointaient vers elle ne mènent plus nulle part.
• Une redirection vers la page d’accueil. Techniquement valide, éditorialement fausse : Google la traite comme un 404 déguisé parce que la destination ne répond pas à la requête d’origine.
• Une chaîne. A redirige vers B, qui redirige vers C. Chaque saut coûte, et au-delà de quelques maillons l’exploration s’arrête.
• Une boucle. La plus brutale : le site devient entièrement inaccessible.

L’inventaire, avant tout le reste

La question n’est pas « quelles pages avons-nous » mais « quelles adresses existent, et lesquelles rapportent quelque chose ». Les deux ensembles ne se recouvrent pas. Trois sources, à croiser :

1. Les sitemaps — ce que le site déclare.
2. Le maillage interne — ce que le site lie réellement, souvent différent.
3. Search Console — ce qui reçoit des impressions et des clics, y compris des adresses que plus rien ne lie.

Cette troisième source est celle qu’on oublie, et c’est la seule qui connaisse les URL héritées. Sur le chantier cité, un parcours du site vivant avait retrouvé 62 redirections. Le fichier de configuration du serveur en contenait 316. L’écart n’était pas une erreur du crawl : une URL héritée n’est plus liée nulle part, c’est précisément pour cela qu’elle est redirigée. Sur les 254 manquantes, trente gagnaient encore des clics.

Une décision par adresse, et cinq possibles

Pour chaque ancienne adresse, une seule des cinq décisions suivantes, écrite dans un tableau que la recette relira :

• Maintien — l’adresse ne change pas. C’est le meilleur cas, et il faut le préférer chaque fois qu’il est possible.
• Redirection vers l’équivalent — la page existe ailleurs, sous une autre adresse, et répond à la même intention.
• Fusion — deux anciennes pages deviennent une seule, mieux traitée. Les deux redirigent vers elle.
• Suppression assumée — le contenu ne mérite pas de survivre et n’a ni trafic ni lien entrant. On laisse un 404, ou un 410 si la disparition est définitive.
• Attente — la décision n’est pas prise. Rien ne part en ligne avec des lignes en attente.

La règle qui évite le plus de dégâts : jamais la page d’accueil comme destination par défaut. Sur le chantier cité, le fichier d’origine comptait vingt-quatre renvois vers l’accueil. La carte finale n’en garde que neuf, toutes sur des adresses sans aucun trafic.

Le piège technique qui a coûté le plus cher

Sur un serveur Apache, la directive Redirect du module mod_alias ne compare pas une adresse : elle compare un préfixe. Écrire

Redirect 301 /services /nos-services

ne redirige pas seulement /services, mais aussi /services-annexes, /services/tout-ce-qui-suit, et tout ce qui commence par ces caractères. Sur un site de plusieurs centaines de pages, l’effet de bord est invisible en recette et massif en production.

La forme correcte utilise une expression ancrée :

RedirectMatch 301 "^/services/?$" "/nos-services/"

Le ^ et le $ bornent la comparaison à l’adresse exacte. Sur le chantier cité, ce seul point expliquait une partie des redirections parasites, et une ligne Redirect 301 "/" "/" — une adresse redirigeant vers elle-même — rendait le site entièrement inaccessible dès que le cache était désactivé. Elle était passée inaperçue plusieurs semaines parce qu’un cache la masquait.

Aplatir les chaînes avant la bascule, pas après

Quand un site accumule des renommages, les chaînes s’installent naturellement : la redirection de 2019 pointe vers une adresse que la refonte de 2023 a elle-même redirigée. Le travail consiste à recalculer chaque source vers sa destination finale, puis à vérifier que cette destination répond bien un 200.

C’est mécanisable, et ça doit l’être : la carte finale du chantier cité compte 386 règles, zéro chaîne, zéro auto-redirection, et chaque destination a été confrontée à la liste des pages réellement produites. Sur les mille adresses de l’export Search Console, il n’en restait que deux en 404 — sans aucun clic.

Le maillage interne doit suivre

Une redirection qui fonctionne ne dispense pas de corriger le lien. Un lien interne vers une adresse redirigée coûte un saut à chaque visite et à chaque exploration, pour rien. Sur le chantier cité, le corps des pages contenait 1 770 liens pointant vers des adresses redirigées — dont 1 197 vers des archives d’auteur qui renvoyaient toutes vers l’accueil.

Deux traitements, selon le cas : repointer le lien vers la destination finale, ou le retirer quand la destination n’apporte rien au lecteur. Le texte visible, lui, ne bouge pas.

La recette : ce qu’on vérifie avant d’ouvrir

Un plan de redirections se teste comme du code, sur l’environnement de préparation, avant la bascule :

• chaque source rend bien un 301, et vers la destination exacte prévue ;
• chaque destination rend un 200 ;
• aucune source n’est aussi une page existante ;
• aucune chaîne, aucune boucle ;
• aucune adresse du sitemap n’est redirigée ;
• toutes les adresses qui reçoivent des clics dans Search Console répondent 200 ou 301.

Ces six contrôles s’écrivent une fois et se rejouent à chaque livraison. C’est ce qui transforme une promesse en engagement vérifiable.

Après la bascule

La surveillance dure plus longtemps qu’on ne le croit. Les trois choses à regarder, dans cet ordre : les erreurs d’exploration dans Search Console, l’évolution du nombre de pages indexées, et les positions des vingt adresses qui rapportaient le plus avant. Une baisse d’impressions à positions constantes ne signifie pas un déclassement : elle signifie que le site est affiché sur moins de requêtes, ce qui renvoie souvent à un problème d’indexation, pas de contenu.

Et l’ancien serveur reste en état de marche jusqu’à ce qu’un mois de données propres soit disponible. Un changement d’enregistrement DNS suffit alors à revenir en arrière — mais seulement si rien d’irréversible n’a été fait entre-temps.

En résumé

Une refonte bien menée ne coûte pas son référencement, et ça se démontre : un inventaire croisé sur trois sources, une décision écrite par adresse, aucune destination par défaut vers l’accueil, des expressions ancrées plutôt que des préfixes, des chaînes aplaties avant la bascule, le maillage corrigé, et six contrôles rejoués à chaque livraison. C’est plus long à préparer qu’à exécuter — et c’est exactement pour ça que la plupart des refontes qui échouent ont échoué avant la mise en ligne.