L'essentiel, si vous manquez de temps
Trois règles suffisent à éviter la majorité des catastrophes. Ne changez vos URLs que si vous avez une vraie raison. Produisez le tableau de correspondance entre anciennes et nouvelles adresses avant la bascule, pas après. Et gardez le contenu des pages qui fonctionnent : un site refait qui perd du trafic a le plus souvent perdu du texte au passage, en même temps qu'il gagnait du design.
Pourquoi les refontes échouent, et ce n'est pas la technique
Sur les cas que j'ai eu à traiter, la cause profonde est presque toujours la même, et elle est organisationnelle. Le projet de refonte est piloté par le design et les fonctionnalités. Le SEO est appelé en fin de parcours, généralement quand l'arborescence est validée, les gabarits développés et les contenus rédigés. À ce stade, les décisions coûteuses sont déjà prises et on ne fait plus que du rattrapage.
Le second facteur est plus insidieux : une refonte s'accompagne presque toujours d'un allègement des contenus. On trouve les anciennes pages trop longues, trop denses, on épure, on modernise. Le résultat est plus beau et moins bien positionné, parce qu'on a supprimé exactement ce qui répondait aux recherches. Le texte que le designer trouve encombrant est souvent la raison pour laquelle la page se classait.
Autrement dit, une refonte réussie ne demande pas des compétences rares. Elle demande que le SEO soit dans la pièce au moment du cadrage, et que personne ne supprime de contenu sans regarder les données de la page.
Le calendrier complet
Voici le déroulé que j'applique. Les délais sont donnés pour un site de taille moyenne : adaptez-les, mais gardez l'ordre, qui lui n'est pas négociable.
| Moment | Ce qui se fait | Le livrable |
|---|---|---|
| J-60 Cadrage |
Le SEO entre dans le projet. On fige ce qui ne doit pas changer et on liste ce qui peut évoluer | La liste des pages à ne surtout pas toucher |
| J-45 Inventaire |
Exploration complète de l'ancien site, export des données de la Search Console sur 16 mois, relevé des liens entrants | Le tableau de toutes les URLs actuelles, avec leur trafic et leurs liens |
| J-30 Arborescence |
Validation de la nouvelle structure, décision URL par URL : conservée, modifiée, fusionnée, supprimée | Le tableau de correspondance ancien vers nouveau |
| J-20 Contenus |
Reprise des textes des pages à trafic, sans amputation. Rédaction des pages neuves | Les contenus validés, comparés aux anciens |
| J-10 Préproduction |
Recette technique sur l'environnement de test, qui doit être inaccessible aux moteurs | Le rapport de recette, la préprod bloquée |
| J-2 Répétition |
Test des redirections à blanc, sauvegarde complète de l'ancien site | Le fichier de redirections vérifié, la sauvegarde |
| Jour J Bascule |
Mise en ligne en début de semaine, hors période chargée. Retrait du blocage moteurs, contrôle immédiat | Le site en ligne et explorable |
| J+1 à J+7 Surveillance |
Contrôle quotidien de l'indexation et des erreurs d'exploration | Les corrections à chaud |
| J+30 à J+90 Stabilisation |
Comparaison avec la situation d'avant, page par page | Le bilan et les rattrapages ciblés |
Appelez-moi avant les maquettes, pas la veille
Le SEO d'une refonte se joue au cadrage : ce qui ne doit pas bouger, le tableau de correspondance, le point de référence chiffré. Après, on ne fait plus que limiter les dégâts.
Inventaire des URLs, plan de redirections et surveillance après bascule.
Les cinq livrables à exiger avant la bascule
Si vous ne deviez retenir qu'une chose de cette page, ce serait cette liste. Ce sont des documents, pas des intentions, et vous devez pouvoir les ouvrir avant que le nouveau site soit en ligne. Leur absence est le meilleur prédicteur d'une refonte ratée.
- 1. L'inventaire complet des URLs actuelles
Toutes les adresses du site existant, obtenues en croisant trois sources : une exploration complète, l'export de la Search Console sur 16 mois, et votre sitemap actuel. Les trois, parce qu'aucune n'est exhaustive à elle seule. La Search Console révèle des pages que l'exploration ne trouve pas, typiquement des pages orphelines qui reçoivent pourtant du trafic.
- 2. Le tableau de correspondance
Une ligne par ancienne adresse, avec sa destination sur le nouveau site. C'est le document central de toute la refonte. Règle absolue : chaque page redirige vers son équivalent réel, jamais vers la page d'accueil. Une redirection de masse vers l'accueil équivaut à supprimer la page, tout en donnant l'impression d'avoir fait le travail.
- 3. La liste des pages à ne pas toucher
Vos pages à fort trafic et celles qui reçoivent des liens externes. Elles gardent leur adresse et leur contenu. C'est le document à opposer à toute proposition d'allègement éditorial : on peut refaire l'habillage, pas retirer la moitié du texte.
- 4. Le point de référence chiffré
Un instantané, la veille de la bascule : trafic organique, positions sur vos requêtes suivies, pages indexées, impressions et clics par page. Sans ce point zéro, vous ne saurez jamais dire si la refonte a nui, et toute discussion ultérieure tournera à l'impression. C'est le livrable le plus vite négligé et le plus regretté.
- 5. La sauvegarde complète de l'ancien site
Fichiers et base, restaurables. Elle sert autant à revenir en arrière qu'à retrouver le contenu d'une page qu'on découvrira amputée trois semaines plus tard. Conservez-la plusieurs mois après la mise en ligne.
Faut-il changer les URLs ?
Presque toujours non, et c'est la décision qui réduit le plus le risque global. Chaque adresse modifiée est une valeur à transférer, donc une occasion de perte. Un nouveau design ne justifie pas de nouvelles adresses : ce sont deux couches indépendantes.
| Situation | Changer l'URL ? | Pourquoi |
|---|---|---|
| Les URLs actuelles sont lisibles et cohérentes | Non | Aucun gain, uniquement du risque |
| Elles contiennent des identifiants illisibles | Oui, si le site est petit | Le gain de lisibilité vaut le risque sur un faible volume |
| Passage en HTTPS | Oui, obligatoirement | C'est une migration nécessaire, à traiter avec le même soin |
| Changement de nom de domaine | Oui, par définition | Toutes les adresses changent : c'est la refonte la plus risquée qui existe |
| « Pour faire plus propre » | Non | Le motif le plus fréquent, et le moins bon |
Si vous changez de domaine en même temps que de design et de contenu, vous cumulez trois variables. En cas de chute, vous ne saurez pas laquelle est en cause. Séparez les chantiers dans le temps quand c'est possible : c'est le conseil que l'on suit le moins et que l'on regrette le plus.
Les erreurs qui coûtent le plus cher
- La préproduction laissée ouverte, ou le blocage laissé en place après la bascule. Les deux faces d'une même erreur. Dans un cas, votre site de test est indexé et concurrence le vrai ; dans l'autre, le nouveau site interdit son exploration et disparaît. C'est la panne la plus brutale et la plus fréquente, détaillée sur préprod et référencement.
- Rediriger toutes les anciennes pages vers l'accueil. Rapide à mettre en place, désastreux à l'usage. Chaque page doit pointer vers son équivalent réel.
- Les redirections en chaîne. Une adresse qui redirige vers une autre, qui redirige encore. Chaque saut dilue, et les chaînes s'accumulent en silence après plusieurs refontes successives.
- Perdre du contenu sans s'en apercevoir. Comparez la longueur des textes avant et après sur vos pages à trafic. C'est un contrôle de dix minutes qui sauve régulièrement des refontes.
- Oublier les images et les fichiers. Les adresses des images changent aussi, et les images positionnées dans la recherche d'images disparaissent. Même chose pour les PDF, qui reçoivent parfois des liens externes.
- Basculer un vendredi. Les problèmes sérieux se manifestent dans les 48 à 72 heures. Personne ne veut les découvrir le lundi matin.
Le détail de chacune est développé sur les erreurs de refonte et les risques d'une refonte.
Après la mise en ligne : quoi surveiller, et quand
La refonte ne s'arrête pas à la bascule. Voici l'ordre de surveillance, du plus urgent au plus lent.
| Quand | Ce qu'on vérifie | Ce qui doit alerter |
|---|---|---|
| Dans l'heure | Le robots.txt, l'absence de balise noindex, un échantillon de redirections | N'importe quel blocage : à corriger immédiatement |
| Jour 1 | Envoi du nouveau sitemap, inspection des pages principales | Une page principale non explorable |
| Jours 2 à 7 | Erreurs d'exploration et pages en 404 dans la Search Console | Des 404 sur des adresses qui recevaient du trafic |
| Semaines 2 à 4 | Courbe d'indexation et évolution des impressions | Un nombre de pages indexées qui ne remonte pas |
| Mois 1 à 3 | Comparaison page par page avec le point de référence | Une page à fort trafic qui ne revient pas à son niveau |
Une baisse est normale, une chute ne l'est pas
Une variation de quelques pourcents pendant deux à quatre semaines fait partie du processus : Google réexplore et réattribue la valeur des anciennes adresses. Ce qui n'est pas normal, c'est une chute brutale de plus de la moitié dès les premiers jours, ou une baisse qui ne se corrige pas après six semaines. Dans ces deux cas, ne patientez pas en espérant que ça remonte : le diagnostic est sur perte de trafic après une refonte.
La refonte est aussi une occasion
On aborde le sujet uniquement par le risque, ce qui est réducteur. Une refonte est le seul moment où l'on peut corriger des problèmes structurels qu'on ne toucherait jamais autrement.
- Résoudre la cannibalisation. C'est l'occasion idéale de fusionner deux pages qui se disputaient la même requête depuis des années.
- Refaire le maillage interne. Sur un site ancien, il reflète l'histoire du site plutôt que ses priorités actuelles.
- Supprimer le contenu mort. Les pages sans trafic, sans lien et sans utilité peuvent enfin partir, ce qui concentre l'exploration sur ce qui compte.
- Repartir sur une base technique propre. Performance, structure, données structurées, accessibilité aux robots des IA génératives, sujet traité sur ma page GEO.
Ces gains sont réels, à une condition : qu'ils soient décidés sur des données, pas sur des impressions. Supprimer une page parce qu'elle « fait vieux » alors qu'elle apporte du trafic est exactement l'erreur que cette page cherche à éviter.