Une refonte fait rarement chuter un site à cause de son design. Elle le fait chuter parce que les URL changent sans plan de redirections, et parce que le contenu se raccourcit au passage. La méthode tient en trois temps : inventorier avant de toucher à quoi que ce soit, rediriger une ancienne URL vers une nouvelle page équivalente, puis surveiller pendant plusieurs semaines. Google demande des redirections permanentes, conservées au moins un an, et compte quelques semaines pour tout traiter.
Sommaire
Le scénario est toujours le même. Le nouveau site est plus beau, plus rapide, enfin conforme à ce que l’entreprise est devenue. Trois semaines après la mise en ligne, le trafic a fondu de moitié et personne ne comprend pourquoi, puisque « le site est mieux qu’avant ».
Il l’est peut-être. Mais Google ne note pas un site, il indexe des adresses. Une refonte qui change les adresses sans dire à Google où sont parties les pages efface d’un coup l’historique de chacune. Voici comment on évite ça, dans l’ordre.
01Ce qu’une refonte casse réellement
Trois mécanismes expliquent la quasi-totalité des chutes post-refonte. Aucun n’a de rapport avec l’esthétique.
Les adresses changent, et l’historique reste derrière
Chaque URL indexée porte des années de signaux : les liens qui pointent vers elle, son ancienneté, ses positions acquises. Quand /nos-services/plomberie.html devient /services/plomberie/ sans redirection, Google se retrouve devant une erreur 404 d’un côté et une page inconnue de l’autre. Rien ne relie les deux, et la nouvelle page repart de zéro.
Le contenu maigrit sans que personne le décide
C’est la cause la plus fréquente, et la plus discrète. Le nouveau design est épuré, donc les longs textes deviennent des accroches de trois lignes. Les pages qui se positionnaient parce qu’elles répondaient précisément à une question ne répondent plus à rien. Le trafic baisse sur des URL pourtant correctement redirigées, et on cherche le problème du mauvais côté.
La structure interne se reconstruit au hasard
Un nouveau menu, de nouveaux gabarits, et la circulation interne change du tout au tout. Des pages qui recevaient dix liens internes n’en reçoivent plus un seul, d’autres se retrouvent à trois clics de l’accueil au lieu d’un. La façon dont les liens internes se distribuent se refait entièrement lors d’une refonte, et presque jamais volontairement.
02L’inventaire, avant de toucher à quoi que ce soit
Tout ce qui suit devient impossible si on ne l’a pas relevé pendant que l’ancien site est encore en ligne. C’est le seul moment où l’information existe.
| Ce qu’on relève | Où | À quoi ça sert ensuite |
|---|---|---|
| Toutes les URL indexées | Search Console, sitemap, crawl complet | Bâtir le plan de redirections |
| Les pages qui apportent du trafic | Search Console, statistiques | Savoir lesquelles ne doivent surtout pas bouger |
| Positions et requêtes de départ | Search Console, 3 à 6 mois | Mesurer après, sur la même base |
| Les liens externes entrants | Outil de netlinking | Repérer les URL qu’on ne peut pas se permettre de perdre |
| Le texte de chaque page qui compte | Export du contenu | Vérifier qu’il n’a pas maigri après |
Sur le texte, le contrôle le plus utile tient en une comparaison bête : le nombre de mots de chaque page avant, le même après. Une page qui passe de 900 mots à 200 a perdu ce qui la faisait ressortir, quelle que soit la qualité du nouveau gabarit. Cette liste se dresse en une heure et elle explique, après coup, la moitié des chutes qu’on met sur le dos des redirections.
Ce relevé sert de référence pendant six mois. Sans lui, la seule question qui compte après la mise en ligne, « est-ce qu’on a perdu quelque chose ou est-ce la saison ? », restera sans réponse. C’est aussi ce qui distingue une refonte pilotée d’une refonte subie, et le point de départ de l’audit que je livre avant tout chantier.
03Le plan de redirections
C’est la pièce maîtresse, et c’est aussi la plus bâclée. Google demande des redirections permanentes côté serveur, les codes 301 et 308, et précise qu’une redirection permanente lui sert de signal pour désigner la nouvelle adresse comme canonique. Une redirection temporaire, elle, laisse l’ancienne page dans les résultats.1
Une ancienne page, une nouvelle page équivalente
La règle tient en une phrase : chaque ancienne URL part vers la page qui traite le même sujet. Ni vers l’accueil, ni vers une catégorie fourre-tout. Une redirection massive vers la page d’accueil est traitée comme une erreur 404 déguisée, et fait perdre exactement ce qu’on cherchait à sauver.
Les chaînes et les impasses
Une ancienne URL qui redirige vers une deuxième, qui redirige vers une troisième, finit par diluer le signal et ralentir l’exploration. On aplatit tout : chaque ancienne adresse pointe directement vers sa destination finale. Et on vérifie qu’aucune redirection ne boucle sur elle-même, ce qui rend la page inaccessible sans que rien ne le signale.
Le cas du changement de domaine
Changer d’adresse en même temps que de site cumule les deux risques, et demande en plus une demande de changement d’adresse dans la Search Console.2 C’est faisable proprement : sur une refonte avec migration de domaine portant vingt-cinq ans d’archives, le plan de redirections a été écrit avant la mise en ligne et les positions ont tenu.
Dernier point, celui qu’on oublie tous : Google demande de conserver les redirections aussi longtemps que possible, au moins un an.2 Elles ne se démontent pas au bout de deux mois parce que « ça a l’air d’être passé ».
04La mise en ligne, et les semaines qui suivent
L’ordre du jour J
Google donne une séquence : mettre les redirections en place, vérifier les balises rel="canonical", tester les redirections, envoyer la demande de changement d’adresse s’il y a lieu, puis soumettre le nouveau sitemap.2 Dans les faits, la vérification passe avant tout : on teste le plan sur l’environnement de préproduction, ligne par ligne, avant que le public ne voie quoi que ce soit.
Combien de temps ça prend
Comptez quelques semaines pour qu’un site de taille petite à moyenne soit migré dans l’index, davantage pour un gros site.2 Une baisse pendant cette fenêtre est normale et ne prouve rien. C’est après qu’il faut regarder.
Ce qu’on surveille
- Les erreurs 404 qui apparaissent, dans la Search Console et dans les journaux du serveur. Chacune est une redirection oubliée.
- La couverture d’indexation, pour vérifier que les nouvelles URL entrent aussi vite que les anciennes sortent.
- Les positions sur les requêtes relevées avant, page par page. Une moyenne globale ne dira rien.
- Les données structurées, qui disparaissent silencieusement neuf fois sur dix lors d’un changement de gabarit. Le balisage qui alimente les résultats enrichis ne survit jamais tout seul à une refonte.
- Les impressions dans les fonctionnalités d’IA, qui se relèvent désormais séparément dans la Search Console. J’ai détaillé ailleurs ce que ce rapport permet réellement de mesurer, et surtout ce qu’il ne dit pas.