Perte de trafic après une refonte

La conversation démarre presque toujours de la même façon. Le nouveau site est en ligne depuis dix jours, il est plus beau, plus rapide, et le trafic a été divisé par trois. La tentation est alors de tout remettre en cause, y compris des choix de conception qui n'ont rien à voir. Je commence donc par poser une question de cadrage, et une seule : est-ce que la chute est brutale ou progressive ?

Distinguer un creux d'un accident

Une refonte qui change les adresses provoque presque toujours un creux. Google doit recrawler l'intégralité du site, suivre les redirections, réévaluer chaque page et transférer les signaux d'une adresse à l'autre. Ce travail prend du temps, et pendant ce temps le trafic baisse.

La forme de la courbe oriente déjà tout le diagnostic. Une chute verticale est presque toujours technique. Une érosion lente est presque toujours éditoriale. Les deux ne se traitent ni avec les mêmes outils ni dans les mêmes délais.

Les sept causes, dans l'ordre où je les vérifie

Les causes sont classées ici selon le rapport entre le coût de la vérification et l'ampleur du dégât qu'elles provoquent, sans souci de cohérence thématique.

1. Une balise noindex restée en place

Voilà ce qui provoque le plus d'effondrements totaux, sur une bêtise que tout le monde a déjà commise. Le site de préproduction porte une balise meta name="robots" content="noindex" pour éviter d'être indexé pendant les travaux. Personne ne la retire au moment de la bascule. Le site disparaît alors de l'index en quelques jours.

Affichez le code source d'une page et cherchez le mot noindex, l'affaire est réglée en trente secondes. Sur WordPress, il faut aussi contrôler la case « demander aux moteurs de recherche de ne pas indexer ce site » dans les réglages de lecture, qui produit le même effet sans laisser de trace dans le thème.

2. Un robots.txt qui bloque tout

Le même oubli se produit dans le fichier robots.txt. Une règle Disallow: / recopiée depuis la préproduction interdit tout parcours du site. L'effet diffère légèrement du noindex, puisque les pages peuvent rester quelque temps dans l'index sans description, mais le résultat final est le même.

Le contrôle se fait en appelant directement l'adresse du fichier, et en vérifiant qu'aucune règle ne bloque les répertoires importants ni les fichiers de style et de script.

3. Des redirections absentes

Quand la baisse s'installe sans remonter, cherchez d'abord de ce côté. Les anciennes adresses renvoient une erreur 404, et tout ce qu'elles avaient accumulé disparaît avec elles : positions, liens entrants, historique.

La méthode est mécanique. On récupère la liste complète des anciennes URL, idéalement depuis un export de la Search Console sur seize mois croisé avec un ancien crawl du site, et on teste chacune. Toute adresse qui ne renvoie pas un code 301 vers une page pertinente est un point de fuite.

4. Des redirections qui existent mais qui sont mauvaises

Trois défauts reviennent, par ordre de gravité.

Le renvoi global vers la page d'accueil, d'abord. Google traite ces redirections sans rapport comme des pages introuvables, et le transfert de signaux n'a tout simplement pas lieu. Vous avez donc supprimé l'intégralité de vos anciennes pages, en croyant les sauver.

Les chaînes de redirections, ensuite. Une adresse qui renvoie vers une deuxième, elle-même redirigée vers une troisième, finit par être suivie, mais le signal s'affaiblit et le parcours coûte inutilement du budget de crawl. Sur un site de plusieurs milliers de pages, ces chaînes se comptent souvent par centaines.

Les redirections temporaires enfin. Un code 302 indique à Google que le changement n'est pas définitif, si bien qu'il conserve l'ancienne adresse dans son index et ne transfère rien. Sur une refonte, seule la redirection permanente a du sens.

5. Du contenu perdu en route

Voilà d'où viennent la plupart des érosions lentes, et c'est le sujet le plus délicat à aborder avec l'agence qui vient de livrer. Une refonte s'accompagne presque toujours d'un travail graphique qui privilégie l'aération, les visuels et les blocs courts. Une page de 1 800 mots devient une page de 400 mots plus élégante, et elle cesse de répondre à la question qui lui amenait du trafic.

La vérification consiste à comparer, pour les vingt pages qui apportaient le plus de trafic, la quantité de texte réellement affichée avant et après. Je mesure le texte rendu à l'écran, le poids du fichier n'ayant plus aucun rapport avec lui sur un site moderne.

6. Un maillage interne appauvri

Les refontes simplifient les menus. Une navigation qui comptait quarante entrées en compte huit, et les trente-deux pages qui n'y figurent plus perdent d'un coup l'essentiel de leurs liens entrants internes. Elles restent en ligne, elles restent indexées, et elles descendent.

Le symptôme typique est une baisse concentrée sur des pages profondes alors que les pages principales se portent bien. Un crawl comparatif entre ancien et nouveau site le met en évidence en quelques minutes.

7. Une structure de titres modifiée

Dernier poste, le moins spectaculaire. Les gabarits changent, les balises de titre aussi. Une page dont le titre principal reprenait exactement la requête cible se retrouve avec un titre générique dicté par le nouveau design. C'est un facteur d'appoint, jamais une cause d'effondrement, mais il compte dans les baisses de 10 à 15 % qui suivent une refonte par ailleurs correcte.

Le protocole des premières quarante-huit heures

1. Contrôler l'indexabilité. Balise meta robots, robots.txt, en-tête HTTP X-Robots-Tag, et réglage de lecture si le site tourne sous WordPress. Ces quatre points prennent cinq minutes à contrôler.
2. Interroger la Search Console. Le rapport d'indexation des pages montre les motifs d'exclusion et leur volume. C'est la source la plus rapide pour distinguer un problème d'accès d'un problème de qualité.
3. Tester un échantillon d'anciennes URL. Une vingtaine, choisies parmi celles qui apportaient le plus de clics. Le résultat donne immédiatement l'état du plan de redirections.
4. Crawler le nouveau site. Pour repérer les pages orphelines, les chaînes de redirections et les erreurs internes.
5. Comparer le contenu des vingt meilleures pages. Volume de texte rendu, titres, liens internes. Comptez une journée sur un site de taille moyenne, et c'est là que se trouve la réponse quand les quatre étapes précédentes n'ont rien donné.

Combien de temps pour récupérer

Une fois le correctif appliqué, la remontée n'est pas immédiate. Google doit repasser, constater et réévaluer. Sur une migration correctement redirigée, je constate une stabilisation en quatre à huit semaines, avec les premières remontées visibles au bout de deux à trois semaines sur les pages les plus crawlées.

Le délai s'allonge nettement quand le correctif arrive tard. Un site laissé six mois avec des 404 massives a vu ses anciennes adresses désindexées et ses liens entrants pointer dans le vide. La récupération est alors partielle, et elle ressemble davantage à une reconstruction qu'à une réparation.

La remontée ne ramène jamais exactement au niveau antérieur, parce que le marché a bougé pendant ce temps. Le trafic d'avant la refonte sert de repère pour mesurer le chemin parcouru, et je déconseille d'en faire un objectif contractuel.

Ce qui aurait évité tout ça

Trois documents produits avant la mise en ligne suffisent à écarter l'essentiel du risque, et aucun ne demande de compétence rare.

Un export complet des URL existantes avec leur trafic, pour savoir ce qu'on a à protéger. Un tableau de correspondance ancienne adresse vers nouvelle adresse, validé ligne à ligne. Et une liste de contrôle de mise en ligne où figurent le retrait du noindex et la vérification du robots.txt, cochée par quelqu'un dont c'est explicitement la responsabilité.

La méthode complète, y compris la préparation en amont, est détaillée sur ma page consacrée à la migration de site.

Questions fréquentes