Les migrations ont mauvaise réputation, et les récits de trafic divisé par trois circulent abondamment. Ces catastrophes existent, mais elles ne viennent presque jamais de la migration elle-même : elles viennent d’une préparation insuffisante et d’un plan de redirection bâclé. Une migration correctement conduite est une opération sans perte, et parfois même l’occasion d’un gain. Voici le plan, dans l’ordre.
Quatre migrations, quatre niveaux de risque
Le mot « migration » recouvre des opérations très différentes, et la première erreur consiste à leur appliquer le même protocole.
Le changement de nom de domaine. Toutes vos URL changent d’hôte. C’est l’opération la plus risquée, parce que vous transférez l’intégralité de l’historique accumulé liens entrants, notoriété, ancienneté d’un domaine vers un autre. Un point positif : la correspondance entre ancien et nouveau est mécanique, chemin pour chemin.
Le changement de structure d’URL. Le domaine reste, mais les adresses changent. Refonte de l’arborescence, passage d’URL techniques à des URL lisibles, réorganisation des catégories. Risque élevé, et surtout travail de correspondance page par page, sans automatisation possible.
Le changement de technologie. Passage d’un CMS à un autre, refonte complète du code, adoption d’un rendu différent. Les URL peuvent être conservées, ce qui limite le risque de référencement, mais tout le reste change : balises, données structurées, performances, rendu. Les régressions sont insidieuses.
Le changement d’hébergement. Le moins risqué des quatre. Ni les URL ni le contenu ne changent : seul le serveur diffère. Les points de vigilance sont techniques propagation DNS, certificat, messagerie plutôt que sémantiques.
Une typologie utile, car le plan de bataille diffère à chaque fois, comme le montre https://seo-jimenezjulien.com dans sa documentation sur le sujet. Et il est fréquent qu’un projet cumule plusieurs de ces migrations simultanément nouveau domaine, nouvelles URL et nouvelle technologie le même week-end. C’est précisément ce qu’il faut éviter : séquencez. Migrez la technologie en conservant les URL, stabilisez pendant six semaines, puis changez la structure. Vous saurez ainsi ce qui a causé quoi.
Avant : l’inventaire
C’est l’étape la plus longue, la plus ennuyeuse, et celle qui détermine tout le reste. Y consacrer trois jours en fait gagner trois semaines.
La liste exhaustive des URL existantes. Exhaustive, au sens strict. Croisez quatre sources : une exploration complète du site avec un outil dédié, l’export de vos rapports d’indexation, vos sitemaps, et surtout vos journaux serveur sur les trois derniers mois. Cette dernière source est celle qu’on oublie, et c’est elle qui révèle les URL orphelines encore visitées par des robots ou des humains anciennes pages, fichiers téléchargés, images référencées ailleurs.
Le relevé des positions et du trafic. Pour vos deux cents pages les plus performantes au minimum : position moyenne sur leurs requêtes principales, impressions, clics, conversions. Sans ce point de référence daté, vous serez incapable de distinguer une perte réelle d’une variation saisonnière.
L’inventaire des liens entrants. Quels sites pointent vers vous, et vers quelles pages précisément. Les pages recevant des liens externes deviennent vos priorités absolues dans le plan de redirection.
La sauvegarde complète de l’état initial. Fichiers, base de données, configuration serveur. Et une copie du plan de redirection lui-même, dans un fichier versionné.
Le plan de redirection
C’est le cœur de l’opération. Tout le reste est secondaire.
Une correspondance une à une. Chaque ancienne URL doit pointer vers la nouvelle page la plus proche en contenu et en intention. Pas vers la catégorie parente, pas vers la page d’accueil : vers l’équivalent réel.
Construisez un tableau à deux colonnes, ancienne URL et nouvelle URL, et traitez-le ligne par ligne. Sur un site de mille pages, comptez deux jours. Il n’existe pas de raccourci, et les tentatives d’automatisation par correspondance de motifs produisent des erreurs qu’on met des mois à détecter.
Le traitement des pages sans équivalent. Trois cas se présentent. Si un contenu proche existe, redirigez vers lui. Si le contenu a été fusionné avec un autre, redirigez vers la page de fusion. Si le contenu disparaît réellement sans remplacement, laissez une erreur 404 propre, ou un code 410 si la suppression est définitive et assumée. Rediriger vers une page sans rapport est pire que ne rien faire : le moteur traite cela comme une soft 404 et vous perdez le bénéfice de la redirection tout en dégradant l’expérience.
Utilisez exclusivement des redirections permanentes, en code 301. Une redirection temporaire lors d’une migration définitive retarde le transfert de valeur de plusieurs mois.
Éliminez les chaînes. Si votre site a déjà connu une refonte, vous avez probablement des redirections existantes. Ne les empilez pas : refaites pointer les anciennes directement vers les nouvelles destinations finales. Une chaîne de trois sauts dilue le signal et consomme du budget d’exploration.
Vérifiez l’absence de boucles. Un test automatisé de l’ensemble du plan, avant mise en ligne, détecte les cas où A pointe vers B qui repointe vers A.
La recette avant mise en ligne
Rien ne se déploie sans passage en préproduction.
Montez un environnement de préproduction identique à la cible, et testez-y l’intégralité du site. Parcours utilisateur, formulaires, tunnel de commande, recherche interne, affichage mobile.
Vérifiez le balisage page par page sur un échantillon de chaque gabarit : balises de titre, descriptions, hiérarchie des titres, balises canoniques, données structurées, textes alternatifs des images. Les migrations technologiques perdent régulièrement des métadonnées sans que personne ne s’en aperçoive avant six semaines.
Testez les redirections en chargeant le tableau de correspondance dans un outil de vérification en masse. Chaque ligne doit renvoyer un code 301 vers la destination attendue, en un seul saut.
Bloquez l’indexation de la préproduction et voici le point qui mérite d’être écrit en majuscules dans votre procédure : ce blocage doit être levé le jour de la bascule. Une préproduction protégée par un Disallow: / ou une directive noindex qui passe en production avec le reste du code est l’accident le plus classique et le plus dévastateur de toutes les migrations. Privilégiez une protection par mot de passe HTTP plutôt qu’une directive dans le code : elle ne peut pas être déployée par erreur.
Le jour de la bascule
Choisissez un créneau de faible activité, en début de semaine, jamais un vendredi. Prévoyez au moins trois heures de disponibilité pour l’équipe.
L’ordre des opérations. Déployez le nouveau site. Activez les redirections. Vérifiez que le blocage d’indexation a bien été retiré c’est la première chose à contrôler, avant toute autre. Contrôlez le certificat de sécurité. Vérifiez le robots.txt en production. Soumettez les nouveaux sitemaps.
Les vérifications dans l’heure. Chargez une vingtaine d’anciennes URL et confirmez qu’elles redirigent correctement. Testez un formulaire, une recherche, un parcours d’achat. Contrôlez le rendu sur mobile. Vérifiez qu’aucune page ne renvoie d’erreur serveur.
Déclarez le changement. En cas de changement de domaine, utilisez l’outil de changement d’adresse des outils pour webmasters : il accélère nettement la prise en compte. Ajoutez la nouvelle propriété, conservez l’ancienne active pendant plusieurs mois pour surveiller les résidus.
Prévenez vos partenaires principaux pour qu’ils mettent leurs liens à jour, même si les redirections font le travail. Un lien direct vaut mieux qu’un lien redirigé.
Les semaines suivantes
Une migration ne se juge pas le lendemain.
Semaine 1. Surveillance quotidienne des erreurs d’exploration. Toute erreur 404 apparaissant dans les rapports signale une URL oubliée dans le plan : ajoutez la redirection immédiatement. C’est le moment où l’on récupère les 5 % d’adresses que l’inventaire avait manqués.
Semaines 2 à 4. Suivi de l’indexation : combien de nouvelles URL sont indexées, à quel rythme. Une baisse temporaire du trafic de 10 à 20 % pendant deux à trois semaines est normale sur une migration d’ampleur le moteur réévalue l’ensemble.
Semaines 4 à 12. Retour progressif aux niveaux antérieurs, puis stabilisation. Comparez vos positions actuelles au relevé initial, requête par requête sur vos pages principales.
Si au bout de trois mois le trafic n’est pas revenu, le problème est identifiable et se situe presque toujours au même endroit : une redirection manquante, une chaîne, une directive de blocage résiduelle, ou une perte de balises. Reprenez la vérification dans cet ordre.
Les erreurs qui coûtent le plus cher
Cinq fautes expliquent la quasi-totalité des migrations catastrophiques.
Tout rediriger vers la page d’accueil. Aucun transfert de valeur, expérience désastreuse, et une masse de soft 404. C’est le raccourci qui détruit le plus d’historique.
Oublier les images et les fichiers. Vos images sont référencées ailleurs et génèrent du trafic en recherche d’images. Vos PDF sont indexés et parfois liés. Ils figurent dans le plan de redirection au même titre que les pages.
Laisser la préproduction indexable. Vous vous retrouvez avec deux versions du site en concurrence, et la mauvaise gagne parfois.
Déployer le blocage d’indexation en production. Le pendant du précédent, et il faut plusieurs semaines pour s’en remettre.
Migrer plusieurs choses à la fois. Nouveau domaine, nouvelles URL, nouvelle technologie et nouveau contenu le même jour : en cas de problème, vous ne saurez jamais lequel des quatre en est la cause, ni quoi corriger.
Séquencez, inventoriez, redirigez page à page, vérifiez avant. C’est peu spectaculaire, et c’est exactement ce qui distingue une migration réussie d’un accident.