Pourquoi la plupart des refontes échouent
La statistique est constante depuis dix ans : la majorité des refontes s’accompagne d’une baisse de trafic organique, souvent supérieure à 30 %, et il faut en moyenne six à douze mois pour revenir au niveau initial. La cause est rarement le design.
Trois mécanismes reviennent systématiquement.
Les URL changent sans plan de redirection. Chaque URL indexée qui renvoie une erreur 404 est un lien perdu, une position perdue et un visiteur perdu. Il ne suffit pas de rediriger la page d’accueil : chaque URL doit pointer vers son équivalent le plus proche.
Les contenus « anciens » sont supprimés. Un article de 2019 qui reçoit 400 visites par mois est un actif, pas un déchet. Le réflexe de faire table rase au moment d’une refonte détruit une partie du capital accumulé.
Le rendu passe côté client. Un site entièrement rendu en JavaScript est indexable en théorie, beaucoup moins en pratique sur des sites de plusieurs milliers de pages. Nous restons sur du rendu serveur, sauf raison précise.
Notre méthode
Nous commençons par l’inventaire, pas par le design. Trois sources sont croisées : l’export complet de la Search Console sur seize mois, les journaux du serveur, et un crawl exhaustif du site existant. Cela produit une liste d’URL avec leur trafic, leurs liens entrants et leur valeur.
Cette liste devient le cahier des charges de la migration : chaque URL doit trouver une destination, et la décision est explicite pour chacune — conservée, redirigée, ou supprimée avec justification.
Ce qu’une refonte doit aussi corriger
Une refonte est le seul moment où l’on peut changer des fondations sans coût marginal. C’est donc l’occasion de traiter ce qui ne se corrige pas facilement ensuite : la structure des URL, la profondeur de navigation, le maillage interne, le rendu serveur, et le socle de données structurées.