Refonte SEO : plan de redirection et checklist complète

La refonte SEO est le déplacement des adresses, des contenus et des signaux d'un site existant vers une nouvelle structure sans perdre le référencement acquis. C'est d'abord un travail d'inventaire, et sa place est au début du projet, pas dans la semaine qui précède la mise en ligne.

Cet article suppose la décision de refonte déjà prise. Le périmètre, le budget, les délais et le choix d'une agence sont traités dans notre guide de la refonte de site internet. Ici, il s'agit de la migration elle-même : le tableau que vous construisez, les règles que suivent les redirections, ce qui se vérifie en préproduction et ce qui se surveille ensuite.

Les positions chutent après une refonte pour des raisons mécaniques, pas mystérieuses. Une URL qui renvoie une erreur sort de l'index. Une page qui n'existe plus ne se positionne plus. Des liens internes cassés cessent de transmettre des signaux. Rien de tout cela n'est de la malchance, et tout cela s'évite avec un tableau construit avant la mise en ligne.

Ce qui fait réellement chuter les performances :

• Les redirections manquantes. L'ancienne adresse renvoie une erreur et la page disparaît avec tout ce qu'elle avait accumulé.
• Les pages supprimées. Retirer une page qui recevait des entrées organiques supprime ce trafic, refonte ou pas.
• Le maillage interne cassé. Les liens servent à la découverte et signalent l'importance. Une navigation refaite qui pointe vers les anciennes adresses dégrade les deux.
• La réécriture massive des titres et intertitres. Ils décrivent le sujet d'une page. Les remplacer tous change les requêtes sur lesquelles la page est pertinente.
• Un contenu qui n'apparaît que côté navigateur. Si la nouvelle version cache le contenu principal derrière l'exécution de JavaScript, il risque de ne pas être indexé.

Ce qui ne casse rien, contrairement à ce qu'affirment la plupart des checklists : une refonte purement graphique sur des URL et des contenus inchangés présente très peu de risque, puisque presque rien de ce qui compte pour la recherche n'a bougé. Et une redirection temporaire transmet bien les signaux : selon Google Search Central, les redirections côté serveur transmettent les signaux de classement et de canonisation. La raison d'utiliser la redirection permanente est qu'elle déclare le déplacement définitif, pas que l'autre perdrait de la valeur.

Cette distinction décide où va le budget : dans l'inventaire des URL et le plan de redirection, pas dans la réécriture de métadonnées qui fonctionnaient déjà.

Le tableau de correspondance est le seul document sur lequel repose toute la migration, et il se construit avant l'existence des gabarits. Chaque ancienne adresse reçoit une ligne, et chaque ligne une décision. Une URL sans décision enregistrée est une URL non traitée, et c'est ainsi que des sites découvrent leurs pertes six semaines après la mise en ligne dans un rapport d'erreurs 404.

Construisez-le à partir de six sources, dans cet ordre. Aucune source n'est complète à elle seule, et c'est précisément pourquoi il en faut six :

1. Les URL indexées dans la Search Console, section Indexation puis Pages.
2. Un crawl complet du site actuel.
3. Les sitemaps en vigueur.
4. Les pages recevant des entrées organiques et des conversions, depuis l'analytique.
5. Les URL vers lesquelles pointent des liens externes.
6. Un export de contenu du CMS, qui révèle les pages publiées mais non liées.

Cet ordre relève de la pratique du métier et non d'une exigence de Google. Il vaut la peine de le préciser, car la plupart des checklists présentent leur propre ordre comme s'il était documenté. Ce qui est documenté, c'est ce qui arrive quand une adresse est oubliée.

Le tableau ci-dessous est la spécification que nous utilisons. Télécharger une liste de conseils ne sert pas à grand-chose ; une structure de colonnes, si, parce que c'est ce que vous remplissez réellement.

Les redirections suivent trois règles, et les trois sont documentées plutôt qu'affaire de goût. Utiliser une redirection permanente pour un déplacement définitif, résoudre chacune en un seul saut, et les conserver au moins un an. Les sites qui perdent leurs positions pendant une refonte enfreignent généralement l'une des trois.

Permanente, parce que le déplacement l'est. Selon Google Search Central, une redirection permanente indique aux moteurs que l'URL d'origine ne doit plus être servie. C'est exactement le signal recherché quand une page a définitivement changé d'adresse.

Un seul saut, jamais de chaîne. L'ancienne pointe directement vers la nouvelle. Les chaînes ancienne, intermédiaire, nouvelle consomment des requêtes de crawl et ajoutent des points de rupture. C'est facile à provoquer sans le vouloir : un changement d'URL suivi des mois plus tard d'un second crée une chaîne si la première redirection n'est pas repointée vers l'adresse finale. Vérifiez les chaînes comme une étape du processus, pas par réflexe.

Les conserver au moins un an. Les recommandations de Google sur le déménagement de site indiquent un an minimum, et plus longtemps ne nuit pas. Notez le sens de cette consigne : c'est un plancher, pas une date de péremption. Rien ne justifie de retirer une redirection tant que l'ancienne adresse reçoit du trafic ou porte des liens externes.

Une décision supplémentaire se prend ici : que faire des pages supprimées volontairement. Ne les redirigez que là où une page réellement équivalente existe. Rediriger une page retirée vers la page d'accueil parce qu'il faut bien en faire quelque chose est pire qu'une erreur propre, car cela produit une destination hors sujet pour quiconque suit le lien.

Les sites multilingues portent un risque supplémentaire, et c'est celui que la plupart des checklists ignorent complètement. Quand les URL changent dans plusieurs langues en même temps, les annotations qui relient ces versions cassent simultanément, et le résultat est la mauvaise version linguistique affichée sur le mauvais marché.

Trois exigences doivent être respectées après le déplacement. Selon la documentation de Google sur les versions localisées, les annotations de langue doivent viser des URL canoniques, chaque version doit lister toutes les autres y compris elle-même, et une entrée par défaut peut être déclarée pour les langues non couvertes.

En pratique, les annotations de langue se régénèrent contre les nouvelles adresses au moment de la mise en ligne, sans compter sur les redirections. Une redirection indique à un robot où une page est partie ; elle ne répare pas une annotation qui pointe encore vers l'ancienne adresse.

C'est là qu'un identifiant stable prend toute sa valeur. Si chaque langue possède son propre slug localisé, il faut autre chose que le slug pour relier les versions entre elles. Un identifiant permanent qui ne change jamais, même quand toutes les adresses visibles changent, rend la régénération des annotations mécanique plutôt que manuelle. C'est la décision de conception que nous referions en premier, et notre article sur l'architecture web et la visibilité l'approfondit.

La préproduction est l'endroit où la migration se vérifie, et elle s'accompagne d'un interrupteur à actionner dans le bon ordre. Bloquer l'indexation de la préproduction avant tout travail, et débloquer la production à la mise en ligne. Inverser les deux est l'une des façons les plus courantes de perdre un mois, car une préproduction indexée pose à la fois un problème d'index et un problème de duplication.

Ce qui se vérifie avant de basculer :

• La résolution des redirections. Passer la liste complète des anciennes URL contre la préproduction et confirmer que chacune arrive en un seul saut à la destination prévue. On teste la liste, pas un échantillon.
• Les liens internes visent les adresses finales. Pas à travers une redirection. Vérifiez le corps des contenus comme la navigation et les boutons, car ils sont stockés séparément.
• Les balises canoniques visent les nouvelles URL. Auto-référencées, pas dirigées vers l'ancien site.
• Les annotations de langue se référencent mutuellement, dans les deux sens.
• La parité de contenu. La nouvelle page porte la substance qui faisait ressortir l'ancienne. Une page qui perd la moitié de son contenu pendant la migration perd la raison de sa pertinence.
• Le rendu. Confirmer que le contenu principal est présent sans exécution côté navigateur. Selon Google Search Central, Googlebot exécute bien le JavaScript, mais ce rendu est différé et dépend des ressources, si bien qu'un contenu apparaissant seulement après exécution risque davantage d'être manqué.
• Les sitemaps. Générés depuis la nouvelle structure, avec des dates de modification exactes.

Consignez le résultat de chaque vérification dans le tableau de correspondance plutôt que dans la tête de quelqu'un. La colonne de statut existe pour rendre visible une vérification partielle au lieu de la supposer faite.

La checklist ci-dessous est classée par phase et non par thème, parce que c'est l'ordre qui la rend efficace. Les points traités dans la mauvaise phase sont exactement ceux qu'on oublie. Chaque entrée est une action au résultat vérifiable, pas un rappel à la vigilance.

Avant le gel des contenus

1. Exporter les URL indexées depuis la Search Console.
2. Crawler intégralement le site actuel et rapprocher les deux listes.
3. Extraire les pages à entrées organiques et à conversions depuis l'analytique.
4. Extraire les URL portant des liens externes.
5. Construire le tableau avec toutes les URL de toutes les sources, dédoublonnées.
6. Enregistrer une décision pour chaque ligne : conserver, rediriger, fusionner ou supprimer.
7. Relever la position et le trafic des pages les plus importantes, comme point de départ.

En préproduction

1. Confirmer que la préproduction est bloquée à l'indexation.
2. Mettre en place les redirections et tester contre elles la liste entière des anciennes URL.
3. Rechercher chaînes et boucles ; chaque redirection se résout en un saut.
4. Repointer les liens internes vers les adresses finales, dans les contenus comme dans la navigation.
5. Vérifier les balises canoniques et les annotations de langue.
6. Vérifier la parité de contenu des pages portant le plus de valeur en recherche.
7. Confirmer que le contenu principal s'affiche sans exécution côté navigateur.

Le jour de la mise en ligne

1. Débloquer l'indexation de la production et le vérifier, puis vérifier que la préproduction reste bloquée.
2. Soumettre les sitemaps régénérés.
3. Recontrôler par sondage les redirections en production, une seconde fois.
4. Confirmer par un envoi réel que l'analytique, les objectifs et le suivi des formulaires se déclenchent sur les nouveaux gabarits.

Les premières semaines

1. Surveiller la couverture d'indexation, ses erreurs et ses pages exclues.
2. Comparer une à une les pages du relevé initial.
3. Corriger les nouvelles erreurs 404 en ajoutant des lignes au tableau, pour qu'il reste la source de référence.
4. Conserver les redirections, au minimum un an.

Chaque cause de perte de trafic après une refonte peut être classée selon la solidité de la preuve qui l'appuie, et ce classement change ce qu'on en fait. Les causes documentées par Google méritent du temps de développement. Les affirmations sans base documentée méritent de la méfiance, en particulier celles qui annoncent des délais de récupération.

Le tableau ci-dessous sépare les deux. La dernière ligne mérite une seconde lecture : aucun délai chiffré de récupération n'est documenté nulle part. Google évoque des fluctuations attendues pendant le retraitement des signaux, sans donner de durée. Les chiffres de quatre-vingt-dix jours ou de trois à six mois proviennent de l'expérience d'un prestataire sans méthodologie publiée, ce qui n'appartient pas à la même catégorie qu'une documentation.

Répondez plutôt par le mécanisme : les effets deviennent visibles à mesure que Google recrawle les URL concernées, de quelques jours à quelques semaines selon la fréquence de crawl, et la consolidation des signaux via les redirections demande un délai supplémentaire que Google ne décrit que qualitativement.

En mai 2026, ce site a déplacé l'intégralité de ses contenus vers des URL localisées dans cinq langues à la fois. C'est le cas que les autres guides de migration traitent le plus mal, parce que les modes de défaillance se multiplient quand toutes les langues changent d'adresse le même jour. Le récit ci-dessous provient de l'historique du dépôt et non de souvenirs.

L'ordre des opérations, qui est la partie qui compte :

1. Un identifiant stable a été ajouté aux index de contenu avant tout renommage. Chaque article a conservé un identifiant permanent, tandis que chaque langue recevait son propre slug visible. Sans cela, changer les slugs dans cinq langues coupe le lien entre les versions.
2. Les annotations de langue ont été reconstruites pour lire des chemins explicites avant le déplacement des slugs, et non après. L'inverse aurait créé une fenêtre avec des signaux de langue cassés.
3. Slugs générés, puis fichiers renommés. Un seul commit de renommage a modifié 491 fichiers.
4. Plan de redirection construit, puis branché dans la compilation. Au 3 août 2026, il contient 383 redirections permanentes. 358 d'entre elles concernent le blog, soit 93 % du plan, et l'espagnol comme le français en portent 96 chacun, 25 % du total pour chaque langue ; l'allemand en compte 92 et le néerlandais 89, soit 24 % et 23 %.
5. Les liens internes dans les contenus ont été réécrits vers les adresses finales, afin que le maillage interne ne passe pas par des redirections.
6. Sitemaps avec alternatives linguistiques, puis les miroirs markdown et l'index lisible par machine.

Ce qui s'est mal passé, plus utile que ce qui a fonctionné :

Le premier passage sur les liens internes a manqué les champs qui ne ressemblaient pas à des liens. Les clés nommées d'après des appels à l'action plutôt que d'après des URL ont été ignorées, et un commit de rattrapage a été nécessaire. La leçon se généralise : analyser la forme de la valeur, pas le nom du champ.

Trois jours plus tard, une deuxième lacune est apparue. Les liens situés à l'intérieur des contenus markdown n'étaient pas couverts par le passage sur les champs structurés et ont dû être corrigés séparément. Un contenu stocké sous deux représentations demande deux passages, et c'est le second qu'on oublie.

Un troisième problème est survenu ensuite : des dates de dernière modification absentes du sitemap statique, découvertes après la mise en ligne plutôt qu'avant.

Nous ne citons volontairement aucun résultat de trafic pour cette migration. Il n'existe pas de mesure isolée à lui attribuer, puisque des contenus ont été ajoutés tout au long de la même période. La valeur de ce récit tient à la séquence et aux erreurs, pas à un chiffre.

Le suivi après la mise en ligne porte sur des pages précises, pas sur un total. Une courbe de trafic globale bouge pour de nombreuses raisons et ne dira pas si la migration a fonctionné. Les pages que vous aviez identifiées comme les plus importantes, comparées une à une au relevé initial, le diront.

Ce qu'il faut surveiller, dans l'ordre où cela devient informatif :

• La couverture d'indexation. Les nouvelles erreurs et les pages nouvellement exclues apparaissent d'abord ici et signalent en général une redirection manquante ou un chemin bloqué.
• L'activité de crawl sur les anciennes adresses. Tant que Google les demande encore, le déplacement est toujours en cours de traitement.
• Les pages du relevé initial, une par une. Position et impressions par page, comparées à ce qui avait été noté avant le gel.
• Les nouvelles erreurs 404. Chacune correspond à une ligne absente du tableau. Ajoutez-la au tableau et pas seulement à la configuration du serveur, pour qu'il reste la référence.
• Le rendu des nouveaux gabarits, si l'approche de rendu a changé.

Résistez à l'envie d'intervenir dès les premiers jours. Les redirections défaillantes et les vraies erreurs se corrigent immédiatement, mais réécrire des titres ou restructurer des pages pendant que les signaux se consolident rend impossible de savoir quelle modification a produit quoi. La suite du travail est traitée dans notre article sur l'optimisation post-lancement.

Si vous préférez confier la migration à des personnes qui l'ont menée sur cinq langues, cela fait partie de nos services SEO.