Le mot recouvre des opérations très différentes. Les distinguer permet de calibrer l'effort, parce que le risque n'est pas du tout le même d'un cas à l'autre.
| Type | Ce qui change | Risque |
|---|---|---|
| Changement de protocole | HTTP vers HTTPS | Faible, opération bien balisée |
| Changement de domaine | Le nom de domaine, structure identique | Modéré, bien pris en charge par les moteurs |
| Refonte graphique | Le design, URL et contenus conservés | Faible en théorie, élevé si le contenu maigrit |
| Changement de structure d'URL | L'arborescence et les slugs | Élevé, chaque adresse doit être appariée |
| Changement de plateforme | Le CMS, souvent avec URL et gabarits | Élevé, plusieurs facteurs changent en même temps |
La règle qui évite la plupart des accidents tient en une phrase. Ne changez qu'une variable à la fois. Une refonte qui modifie simultanément le domaine, l'arborescence, les gabarits et les textes rend tout diagnostic impossible en cas de chute : rien ne permet de savoir laquelle des quatre décisions a coûté du trafic.
L'inventaire complet des URL. Il se construit à partir de trois sources qui ne se recouvrent jamais : le crawl du site existant, l'export des pages de la Search Console sur les seize derniers mois, et les journaux du serveur. La Search Console fait apparaître des pages positionnées que le crawl ne trouve pas, parce qu'elles sont orphelines. Les journaux révèlent les adresses encore visitées par les robots et par les visiteurs.
Le relevé de référence. Positions sur les requêtes qui comptent, trafic organique par page, pages d'entrée principales, nombre de pages indexées, backlinks reçus par URL. Ce relevé se fait avant la bascule, et sa date se note. Sans lui, la discussion d'après-migration se tient sans point de comparaison et tourne à l'impression.
La hiérarchisation. Sur un site de plusieurs milliers d'adresses, toutes ne méritent pas la même attention. Les pages qui concentrent le trafic organique et celles qui reçoivent des backlinks se traitent une par une, à la main. Le reste peut suivre des règles automatiques.
C'est aussi le moment de faire le ménage. Une migration est l'occasion naturelle de traiter les pages sans audience, par élagage ou par fusion, plutôt que de transporter un existant devenu inutile vers la nouvelle structure.
Le plan de redirection est un tableau à deux colonnes : ancienne URL, nouvelle URL. C'est le livrable central, celui qui se relit ligne à ligne, et il n'existe pas de raccourci pour le produire.
Chaque ancienne adresse doit pointer vers la page la plus proche par le contenu et par l'intention, en redirection 301 permanente. Quand aucune page équivalente n'existe, deux options se discutent : rediriger vers la catégorie parente, ce qui reste acceptable si le visiteur y trouve son compte, ou renvoyer un code 410 qui déclare la suppression définitive. La seconde option est plus honnête que la première quand le contenu a réellement disparu.
Trois contrôles se font sur le tableau avant la bascule. Aucune chaîne de redirection : une ancienne URL doit atteindre sa destination en un saut, pas en trois. Aucune boucle. Aucune destination en noindex, en erreur ou elle-même redirigée.
Le plan ne concerne pas que les pages HTML. Les images, les PDF, les flux RSS, les fichiers de sitemap et les URL d'API publiques ont aussi des adresses connues du moteur et des utilisateurs. Les oublier produit des ruptures invisibles dans les rapports de trafic mais très visibles pour les visiteurs qui avaient mis un document en favori.
La recette se fait sur l'environnement de préproduction, avec une liste de contrôles à valider avant d'ouvrir au public. Les balises title et meta descriptions sont-elles reprises ? Les données structurées sont-elles toujours présentes ? Le maillage interne pointe-t-il vers les nouvelles URL plutôt que vers les anciennes redirigées ? Les balises canonical désignent-elles bien les nouvelles adresses ?
Un point mérite une vérification isolée, parce qu'il est responsable d'un grand nombre d'accidents : le fichier robots.txt de préproduction, qui contient presque toujours un Disallow: / destiné à protéger l'environnement de test. Mis en ligne tel quel, il bloque l'exploration du site entier. La même vigilance s'applique aux balises noindex posées sur les gabarits de test.
Juste après la bascule, quatre gestes s'enchaînent. Soumettre le nouveau sitemap dans la Search Console. Conserver l'ancien sitemap en ligne quelque temps, pour que le moteur redécouvre les anciennes adresses et rencontre leurs redirections. Utiliser l'outil de changement d'adresse dans le cas d'un changement de domaine. Et vérifier immédiatement, sur un échantillon d'une trentaine d'URL représentatives, que les redirections répondent bien en 301 vers la bonne destination.
Une migration ne se juge pas le lendemain. Le moteur doit réexplorer l'ancienne structure, rencontrer les redirections, retraiter les nouvelles pages et réattribuer les signaux. Ce travail prend des semaines, et un creux passager n'est pas un échec.
La première semaine se passe dans les rapports d'erreurs : explosion des 404, pics d'erreurs serveur, pages nouvellement bloquées. Ces anomalies se corrigent dans la journée, car elles se transforment vite en pertes durables.
Le premier mois sert à surveiller la courbe d'indexation des nouvelles URL et la décroissance des anciennes. Les deux doivent se croiser. Une indexation qui ne démarre pas signale un blocage technique, pas un délai.
Le troisième mois est le moment du verdict, en comparant le relevé de référence au relevé actuel, requête par requête et page par page. Un trafic qui n'est pas revenu à son niveau antérieur au bout de trois mois a une cause identifiable, et elle se trouve presque toujours dans le plan de redirection, dans un contenu appauvri par la refonte ou dans un blocage laissé en place.
Tout rediriger vers la page d'accueil. C'est la décision la plus destructrice, souvent prise par facilité quand le plan d'appariement n'a pas été fait. Les redirections massives vers l'accueil sont traitées comme des pages introuvables déguisées et ne transmettent rien.
Supprimer les redirections trop tôt. Les anciennes adresses circulent des années dans les liens externes, les favoris et les documents. Un plan de redirection se garde au minimum un an, et il n'y a aucune raison technique de le retirer ensuite.
Profiter de la refonte pour raccourcir les textes. Un nouveau gabarit plus aéré conduit souvent à supprimer des paragraphes jugés trop longs. Le site perd alors en profondeur de contenu au moment précis où il demande au moteur de lui refaire confiance.
Migrer sans relevé de référence. Sans point de comparaison daté, personne ne peut établir l'ampleur réelle d'une perte, ni prouver un retour à la normale. C'est le contrôle le moins coûteux et le plus souvent oublié.
Choisir la mauvaise période. Une migration en pleine haute saison commerciale fait porter la baisse passagère sur les semaines les plus rentables de l'année. Le calendrier est une décision SEO à part entière.
