Perte de trafic après une refonte : le plan de redirections est un livrable

Le site est plus beau, plus rapide, mieux structuré. Trois semaines après la mise en ligne, les demandes entrantes ont fondu et personne ne sait qui devait produire la liste des anciennes adresses. La réunion de crise commence toujours par la même phrase : je pensais que c’était dans votre périmètre.

La perte de trafic après une refonte ne vient presque jamais du design. Elle vient d’une tâche que trois prestataires croyaient chacun assignée à l’autre, et qui n’apparaît sur aucun devis.

Cet article décrit la mécanique de cette perte, désigne les responsabilités, propose un cahier de recette en douze points à annexer au contrat, puis deux mécanismes simples de calendrier et une clause de non-régression avec son seuil. Aucun pourcentage de perte n’y figure, pour une raison expliquée plus bas.

Perte de trafic après une refonte : la mécanique réelle

Quand une adresse disparaît sans redirection, elle ne cesse pas d’exister pour Google le jour de la bascule. Le moteur continue de la proposer dans ses résultats tant qu’il ne l’a pas revisitée. Les internautes qui cliquent arrivent alors sur une erreur.

Le décalage tient au rythme d’exploration. Google explore les pages à des fréquences très inégales, et sa documentation sur les migrations précise qu’un déménagement n’est considéré comme terminé que lorsque chaque adresse de l’ancien et du nouveau site a été visitée au moins une fois. Sur un site de quelques centaines de pages, cela prend des jours ; sur un catalogue, des semaines.

Deux facteurs allongent encore ce décalage. Les liens externes qui pointent vers vos anciennes adresses ne sont réévalués qu’au rythme où Google réexplore les sites qui les hébergent. Et un ancien plan de site laissé accessible aide le moteur à découvrir les redirections plus vite, ce qui explique la consigne de ne pas le supprimer le jour de la bascule.

D’où l’effet le plus déroutant pour un dirigeant : la courbe ne s’effondre pas le jour de la mise en ligne. Elle tient deux ou trois jours, décroche ensuite, et le lien de cause à effet se perd en route.

Un mot sur les chiffres qui circulent. Les pourcentages de perte publiés par les agences ne sont vérifiables par personne, ils dépendent du volume de pages, de la fréquence d’exploration et de la qualité du plan. Aucun ordre de grandeur n’est repris ici, parce qu’aucun ne serait honnête.

La perte n’est pas non plus inévitable. Google documente précisément la marche à suivre, et les couches techniques qui portent le référencement situent la redirection à l’endroit exact où une migration se joue.

Trois prestataires, une refonte, aucune responsabilité désignée

Le schéma se répète. Une agence de création dessine et rédige, un intégrateur développe et met en ligne, un prestataire SEO suit le référencement. Trois prestataires, aucune responsabilité écrite sur les redirections.

Chacun a une bonne raison. L’agence de création ignore quelles adresses sont indexées aujourd’hui. L’intégrateur sait poser une règle de redirection, mais la liste ne lui parvient pas. Et le prestataire SEO, qui détient cette liste, n’a pas les accès au serveur.

Le résultat est une tâche orpheline, qui coûte pourtant moins d’une journée quand elle est attribuée. Le budget d’une refonte l’ignore presque toujours, comme le montre ce que couvre le budget d’un site et ce qu’il oublie.

Le plan de redirections n’est pas un fichier, c’est une recette

Un tableur listant deux mille correspondances ne prouve rien. Ce qui compte, c’est que chaque ligne ait été exécutée et vérifiée sur le serveur de production, avec le bon code de réponse.

La distinction change la formulation contractuelle. Vous n’achetez pas un plan de redirections, vous achetez une recette avant mise en ligne : un contrôle daté, signé, portant sur un échantillon tiré au sort et sur la totalité des adresses à fort trafic.

Le cahier de recette de migration en douze points

Les douze points ci-dessous s’annexent au contrat. Chacun porte un responsable et une preuve, ce qui supprime la discussion du lendemain. La logique est celle décrite pour annexer un cahier de recette au cahier des charges.

Trois points méritent un commentaire. Les codes 301 ou 308 sont ceux que Google recommande pour un changement permanent : un code temporaire laisse le moteur dans l’expectative. Les chaînes de redirection, ensuite, sont explicitement déconseillées par la documentation ; une adresse doit pointer vers sa destination finale, pas vers une étape intermédiaire.

Le relevé de référence, enfin, est le seul point dont le client est responsable. Personne d’autre n’a intérêt à le produire, puisque c’est la pièce qui permettra de mesurer l’écart. Un export daté des indicateurs, la veille de la bascule, suffit.

Le gel de mise en ligne et le contrôle à trente jours

Deux mécanismes de calendrier suppriment la majorité des accidents, et aucun ne coûte quoi que ce soit.

Le gel de mise en ligne interdit toute bascule un vendredi, une veille de jour férié ou pendant un pic saisonnier. La raison est prosaïque : un problème découvert le samedi matin reste ouvert jusqu’au lundi, et les trois jours perdus se paient en exploration.

Le point de contrôle à trente jours fixe une revue conjointe un mois après la bascule, avec un ordre du jour écrit : couverture d’indexation, erreurs relevées, comparaison au relevé de référence, adresses encore visitées par Google sur l’ancienne structure.

Trente jours ne sont pas un délai magique. C’est simplement la première date à laquelle un site de taille moyenne a été suffisamment réexploré pour qu’une comparaison veuille dire quelque chose. La méthode pour suivre l’effet d’une intervention sur trente jours s’applique telle quelle.

Ajoutez une consigne de durée. Google recommande de conserver les redirections au moins un an, et son outil de changement d’adresse cesse de rapprocher l’ancien et le nouveau site au bout de cent quatre-vingts jours. Retirer les redirections au troisième mois, comme le font certains hébergeurs lors d’un changement d’offre, annule une partie du travail.

La clause de non-régression et son seuil de déclenchement

Une clause de non-régression engage le prestataire sur le maintien d’un niveau mesuré, pas sur une promesse de progression. Elle se rédige en quatre éléments.

• L’indicateur : clics organiques, adresses indexées, ou les deux, jamais la position moyenne.
• La référence : la période de trente jours précédant la bascule, exportée et datée.
• Le seuil de déclenchement : un écart négatif constaté sur une période comparable.
• La conséquence : correction sous délai et reprise aux frais du prestataire.

Le choix du seuil demande un arbitrage honnête. Trop bas, il se déclenche sur une saisonnalité ou une mise à jour d’algorithme sans rapport avec la migration. Trop haut, il ne sert jamais. Un seuil discuté avec le prestataire, écrit dans le contrat et assorti d’une clause d’exclusion pour les événements externes documentés tient mieux qu’un chiffre imposé.

Un dernier point, souvent oublié à la signature. La clause doit dire ce qui se passe si le prestataire conteste la mesure. Un tiers désigné à l’avance, ou simplement la source de données du client retenue comme référence contractuelle, évite trois semaines de courriels sur la méthode plutôt que sur la correction.

Ce que la clause doit préciser, plus que le chiffre lui-même : qui produit la mesure, sur quelle source, et sous quel délai la correction doit intervenir. Une clause sans source de données nommée se discute indéfiniment.

Ces trois mécanismes relèvent de ce qui ne se délègue pas. Ils font partie de ce qui doit rester sous contrôle du client lors d’un projet web, au même titre que la propriété du domaine et des comptes de mesure.

Les quarante-huit heures qui décident du trimestre suivant

Une migration se joue sur deux jours et se paie sur trois mois. Les deux jours sont ceux où l’on vérifie la recette avant de basculer ; les trois mois sont ceux qu’il faut pour revenir au niveau antérieur quand la recette n’a pas été faite.

Annexez le cahier de recette au contrat avant de signer, avec le nom du responsable en face de chaque ligne. Un prestataire qui refuse de s’engager sur douze points vérifiables vous apprend quelque chose d’utile, et il vous l’apprend avant la bascule plutôt qu’après.

Sources et références

Cet article s’appuie notamment sur la documentation de Google Search Central consacrée au déplacement d’un site avec changement d’adresses, qui recommande les redirections permanentes côté serveur, déconseille les chaînes de redirection et fixe une durée de conservation d’au moins un an, et sur la page dédiée aux redirections et à la recherche Google. Les délais de rapprochement entre ancien et nouveau site viennent de l’aide consacrée à l’outil de changement d’adresse de la Search Console. Les moyens de contrôle après bascule reposent sur l’outil d’inspection d’URL, sur le rapport d’indexation des pages et sur le guide de Google pour analyser une baisse de trafic de recherche.