Refonte de site web : ce qui casse le référencement, et comment l'éviter.

Une refonte rate rarement sur le design. Elle rate sur le référencement, et le constat tombe six semaines plus tard, quand le trafic ne revient pas. Nous avons migré studjoow.com de WordPress vers Next.js en mai 2026 : 247 URLs, dont cinq fiches typographiques qui portaient à elles seules 43 % des clics. Voici ce que cette migration a appris, et ce qu'il faut faire dans l'ordre.

Ce qu'une refonte fait vraiment perdre

Le risque n'est pas esthétique, il est arithmétique. Sur un site établi, le trafic se concentre sur une poignée de pages. Dans notre inventaire, cinq fiches typographiques totalisaient 779 clics sur 1 801, et onze articles couleur cumulaient 227 354 impressions. Perdre ces URLs, c'est perdre la moitié du trafic, quelle que soit la beauté du nouveau site.

Les trois causes de perte, par ordre de fréquence : des URLs qui changent sans redirection, des redirections temporaires qui ne transmettent pas l'autorité, et un rendu technique qui ralentit l'exploration du site par les robots. Aucune des trois ne se voit à l'œil nu.

Étape 1 : geler l'inventaire avant de toucher à quoi que ce soit

Avant la première maquette, exportez depuis la Search Console la totalité de vos URLs sur seize mois, avec clics, impressions et position moyenne. Cet export devient un fichier versionné dans le dépôt, pas une pièce jointe dans un mail.

Pour chaque URL, une décision et une seule : conservée à l'identique, redirigée vers une cible précise, ou abandonnée. Notre inventaire tenait en 247 lignes, et chaque ligne portait sa route cible. Sur 146 fiches portfolio, trente ont été conservées ; les 116 autres redirigent en 301 vers une page unique, parce que leur trafic ne justifiait pas de les maintenir.

Ce fichier est le contrat de la refonte. Toute URL qui n'y figure pas n'existe pas, et toute modification passe par une relecture explicite.

Étape 2 : décider ce que vous abandonnez

Une refonte est aussi un élagage. Le critère n'est pas l'attachement au contenu, c'est le nombre de clics sur douze mois. Une page à zéro clic depuis un an ne mérite pas d'être portée, elle mérite d'être redirigée vers la page qui la remplace.

Assumez la perte quand elle est décidée. Consolider cent pages mortes vers une page vivante vaut mieux que maintenir cent pages que personne ne lit et que Google explore à votre place.

Étape 3 : les trois pièges techniques de la migration

La redirection temporaire qui ne transmet rien

Une redirection 307 est temporaire : elle ne transfère pas l'autorité acquise. Les hébergeurs la posent parfois par défaut entre le domaine nu et le sous-domaine www. Google traite alors les deux comme des sites distincts, et l'historique reste du mauvais côté.

La vérification tient en une ligne :

curl -sI https://votresite.com | grep -i "HTTP\|location"

Un 301 ou un 308 est correct. Un 307 est à corriger avant le lancement, pas après.

Le rendu dynamique qui tue le cache

Sur les frameworks modernes, lire les en-têtes ou les cookies dans un composant partagé, un en-tête de page ou un pied de page, bascule le site entier en rendu dynamique. Chaque visite d'un robot devient un appel serveur, et l'exploration ralentit d'autant.

Le symptôme est lisible dans les en-têtes de réponse : un cache-control qui passe en private, no-cache et un cache CDN qui ne se remplit jamais. Nous l'avons vécu sur studjoow.com : une simple ligne de géolocalisation dans le pied de page avait rendu dynamiques toutes les pages du site.

Le maillage interne qui ne dit plus rien

Quand une carte entière est un lien, le texte de l'ancre devient le teaser complet : plusieurs centaines de caractères illisibles pour un lecteur d'écran et muets pour un moteur. Le lien doit porter le titre, et la carte reste cliquable par un recouvrement en CSS.

Étape 4 : mesurer après, avec les bons indicateurs

La Search Console met une à deux semaines à refléter la migration. Ce délai est normal et il ne se rattrape pas en le regardant tous les jours.

Ce qu'il faut suivre, dans cet ordre : les erreurs de couverture, la position moyenne des dix URLs qui portaient le trafic avant, puis les Core Web Vitals de terrain. Un score de laboratoire ne dit rien de ce que vivent vos visiteurs.

Fixez la ligne de base avant le lancement. Sans photographie de l'avant, l'après n'est qu'une impression.

Étape 5 : remplacer la refonte par l'entretien

Une refonte tous les cinq ans coûte cher et fait peur, donc on la repousse, donc elle coûte plus cher. Un site entretenu en continu ne connaît pas ce cycle : les pages évoluent une par une, le socle technique suit les versions, et la question de la refonte ne se pose plus.

C'est le modèle que nous appliquons à nos propres sites et à ceux que nous opérons : une mise à jour continue plutôt qu'une reconstruction périodique.

Combien de temps, et avec qui

Une refonte correctement inventoriée prend entre six et dix semaines pour un site de cent à trois cents pages, dont une semaine entière consacrée au seul inventaire des URLs. C'est la semaine que tout le monde veut sauter, et c'est celle qui décide du résultat.

Si vous voulez voir comment nous procédons sur une refonte Next.js, la méthode est détaillée sur notre page refonte Next.js. Si vous préférez en parler de votre cas, le premier échange dure trente minutes et ne coûte rien.