Comment migrer un site sans perdre ses positions ?

Les chutes de trafic qui suivent une refonte ne viennent presque jamais du design. Elles viennent d'adresses qui ont changé sans redirection, de balises d'indexation restées en place depuis la préproduction, d'un fichier réservé aux robots recopié tel quel, ou d'un plan de site qui pointe encore vers l'ancienne structure. Une migration de site réussie tient à un inventaire fait avant, à un plan de redirections vérifié ligne par ligne, et à une série de contrôles menés dans les heures et les semaines qui suivent la bascule. Aucune de ces étapes n'est difficile, et c'est leur omission, sous la pression d'une date de mise en ligne, qui produit les pertes.

Avant la migration

Tout ce qui suit doit être fait avant la bascule, sur le site encore en ligne. Une fois l'ancien site éteint, une partie de ces informations devient impossible à récupérer, ce qui transforme un contrôle de routine en enquête.

Inventorier toutes les adresses

Une exploration complète du site en production donne la liste exhaustive des adresses accessibles, avec leur code de réponse, leur titre et leur profondeur. Cette liste doit être complétée par l'export des adresses connues des moteurs et par celles figurant dans les rapports d'audience, qui contiennent souvent des pages que l'exploration ne trouve pas faute de lien. La réunion de ces trois sources constitue le périmètre réel à traiter, systématiquement plus large que ce que l'équipe imaginait. Il faut y ajouter les adresses figurant dans les campagnes en cours et dans les documents imprimés, qui n'apparaissent dans aucune de ces sources.

Relever les pages qui comptent

Toutes les adresses n'ont pas la même valeur. Le classement par trafic organique, par liens entrants et par conversions désigne les quelques dizaines de pages dont la perte serait dommageable. Ce sont celles qui méritent une vérification individuelle plutôt qu'un traitement par lot. Ce relevé se fait en une heure et il oriente tout le reste du travail, en particulier l'ordre des contrôles le jour de la bascule. Ces pages doivent également être relues pour vérifier que leur contenu n'a pas été raccourci lors de la refonte, cause fréquente de perte.

Mesurer l'état de départ

Un relevé des positions sur un échantillon de requêtes, du trafic par section et des temps de réponse constitue la base de comparaison. Sans cette photographie, toute évolution constatée après la migration sera discutée sans fin, chacun ayant sa propre idée de ce qu'était la situation antérieure. Ce relevé doit être daté, archivé et partagé avant la bascule, jamais reconstitué après coup à partir de souvenirs. Une capture des rapports principaux, en image, complète utilement les exports de données et se consulte plus vite.

Récupérer les données historiques

Les données d'audience, les journaux du serveur et les exports des outils pour webmasters doivent être sauvegardés avant tout changement d'hébergement. Sur un changement de prestataire, ces éléments disparaissent parfois avec l'ancien accès, et leur perte prive de toute possibilité d'analyse comparative. Cette précaution prend dix minutes et évite de se retrouver aveugle au pire moment. Il vaut également mieux conserver une copie complète de l'ancien site, fichiers et base, pendant au moins six mois.

Préparer la préproduction correctement

Le site de recette doit être inaccessible aux moteurs, ce qui s'obtient par une protection par mot de passe au niveau du serveur et non par une simple directive de non indexation. Cette précaution évite l'indexation de la préproduction, incident classique qui crée une duplication complète du site. Le point de vigilance porte sur le retrait de cette protection au moment de la bascule, oubli qui produit un site en ligne inaccessible aux moteurs. Ce retrait doit figurer explicitement dans la procédure de bascule, en première position.

Vérifier la configuration de destination

Le serveur cible doit être testé avant la bascule : version de l'interpréteur, modules disponibles, limites de mémoire, certificat, capacité à répondre sous charge. Un site parfaitement migré sur un serveur mal configuré donne exactement le même résultat qu'une migration ratée. Ce contrôle se fait sur la préproduction et doit inclure une mesure du temps de réponse, souvent dégradé sur un hébergement moins bien dimensionné. Une simulation de charge, même sommaire, révèle les limites avant que les visiteurs ne les découvrent.

Le plan de redirections

C'est le cœur du sujet et la principale source de pertes. Il se construit avant, se vérifie avant, et se teste avant. La gestion technique de ces règles est développée dans notre article sur la manière de gérer quatre cents redirections.

Une correspondance ancienne vers nouvelle

Le plan prend la forme d'un tableau à deux colonnes, une ligne par ancienne adresse. Ce tableau doit couvrir la totalité de l'inventaire, sans exception, y compris les pages que l'on juge sans intérêt. Une adresse sans correspondance doit faire l'objet d'une décision explicite, pas d'un oubli. C'est ce tableau qui sera relu, testé et conservé, et il constitue le livrable le plus important de toute la migration. Il doit être conservé avec le projet bien après la mise en ligne, car il servira encore lors de la migration suivante.

Rediriger vers l'équivalent le plus proche

Chaque ancienne adresse doit pointer vers la page qui répond à la même intention, pas vers l'accueil. Une redirection massive vers la page d'accueil est traitée comme une page d'erreur par les moteurs et fait perdre l'intégralité de la valeur accumulée. Lorsqu'aucun équivalent n'existe, la catégorie parente est un moindre mal, et la disparition assumée avec un code d'erreur est parfois la réponse la plus honnête. Une page d'erreur soignée, proposant une recherche et les contenus principaux, limite alors la déception du visiteur.

Employer le bon code

Une migration appelle des redirections permanentes, qui transmettent les signaux à la nouvelle adresse. Les redirections temporaires conservent l'ancienne adresse dans l'index et ne consolident rien, ce qui est exactement l'inverse de l'effet recherché. La distinction est détaillée dans notre article sur le code HTTP 302 et ses enjeux, et son mauvais choix explique une partie des migrations dont les effets ne se stabilisent jamais. Le contrôle du code renvoyé fait partie du test automatisé du plan, au même titre que celui de la destination.

Éviter les chaînes

Une ancienne adresse redirigée vers une adresse elle même redirigée double le temps de résolution et dilue les signaux. Sur un site ayant déjà connu une migration, les anciennes règles doivent être réécrites pour pointer directement vers la destination finale. Ce travail est purement mécanique, il se script en quelques lignes, et il est presque toujours oublié parce que les anciennes règles fonctionnent encore. Un contrôle automatisé détectant les chaînes dans le plan avant la bascule règle la question une fois pour toutes.

Traiter les fichiers et les images

Les documents et les images changent souvent d'adresse lors d'une migration, et leurs anciennes adresses figurent dans des liens externes et dans des contenus partagés. Elles méritent le même traitement que les pages. Ce point est systématiquement oublié, alors qu'il représente parfois un volume supérieur à celui des pages elles mêmes sur les sites documentaires. Un simple filtre sur les extensions dans l'inventaire suffit à isoler cette population et à la traiter séparément.

Tester le plan avant la bascule

Un script parcourant chaque ancienne adresse sur la préproduction et vérifiant le code de réponse et la destination valide l'ensemble en quelques minutes. Ce test doit passer intégralement avant d'envisager la mise en ligne. Le repousser après la bascule revient à découvrir les erreurs pendant que les visiteurs les subissent, et à travailler dans l'urgence sur un sujet qui ne s'y prête pas. Le résultat de ce test doit être archivé, il constitue la preuve que le plan était correct au moment de la bascule.

Le jour de la bascule

La liste des contrôles à mener dans l'heure qui suit la mise en ligne est courte, et chacun d'eux prend moins de deux minutes. Ils doivent être effectués dans cet ordre, par une personne qui dispose de la liste sous les yeux plutôt que de mémoire.

Retirer les blocages de recette

La protection par mot de passe, les directives de non indexation et les règles de blocage dans le fichier réservé aux robots doivent disparaître. C'est le contrôle numéro un, celui dont l'oubli produit les pertes les plus spectaculaires, et il se vérifie en consultant le code source d'une page et le fichier de directives en ligne. Un site parfait mais marqué comme non indexable disparaît des résultats en quelques jours. La remise en état est ensuite longue, le moteur mettant plusieurs semaines à reconsidérer un site qu'il a désindexé.

Vérifier les balises d'indexation

Un contrôle sur une dizaine de pages représentatives, dans le code source, confirme l'absence de directive de non indexation et la présence de canoniques pointant vers les bonnes adresses. Les canoniques héritées de la préproduction, pointant vers un domaine de test, constituent un défaut fréquent et dévastateur. Ce contrôle se fait plus vite avec un outil d'exploration qui vérifie l'ensemble du site en quelques minutes. Il doit porter sur toutes les sections, les gabarits pouvant différer d'un type de contenu à l'autre.

Contrôler le fichier de directives

Le fichier réservé aux robots de production doit être en place, différent de celui de la recette, et autoriser l'exploration. Une directive interdisant l'ensemble du site, recopiée depuis la préproduction, est l'un des incidents les plus courants et les plus coûteux. Sa vérification prend dix secondes et devrait figurer en tête de toute procédure de mise en ligne. Le fichier de production doit être versionné avec le projet, et non recopié à la main au moment de la bascule.

Soumettre le nouveau plan de site

Le plan de site doit refléter la nouvelle structure et être soumis aux outils pour webmasters. Conserver l'ancien plan quelques jours, en parallèle, aide le moteur à découvrir plus vite les redirections des anciennes adresses. Cette astuce simple accélère sensiblement la prise en compte de la migration et ne présente aucun inconvénient. L'ancien plan peut être retiré une fois que la majorité des anciennes adresses a été réexplorée.

Tester les redirections en production

Le script de test rejoué sur le site en production détecte les écarts entre la préproduction et l'environnement réel, notamment ceux introduits par un service intermédiaire ou par une configuration de serveur différente. Ce second passage est indispensable, un plan de redirections valide en recette pouvant se comporter différemment derrière un réseau de diffusion. Il vaut mieux le lancer immédiatement après la bascule, quand l'équipe est encore disponible pour corriger.

Vérifier la mesure d'audience

Les balises de suivi doivent être présentes sur toutes les pages du nouveau site, avec le bon identifiant de propriété. Une migration où la mesure ne fonctionne plus donne l'impression d'une chute de trafic catastrophique et empêche tout diagnostic. Ce contrôle se fait en temps réel dans l'outil de mesure, en naviguant sur quelques pages, et il prend deux minutes. Il faut également vérifier que les objectifs et les événements de conversion sont bien déclenchés, la refonte ayant souvent changé les identifiants des éléments concernés.

Les semaines suivantes

Une migration ne se juge pas le lendemain. Les moteurs mettent plusieurs semaines à réexplorer l'ensemble du site et à transférer les signaux, et c'est pendant cette période que les problèmes résiduels se révèlent. La discipline de suivi compte alors autant que la qualité de la préparation.

Surveiller les erreurs

Les rapports de couverture et les journaux du serveur signalent les adresses qui échouent. Une revue quotidienne la première semaine, puis hebdomadaire, permet de compléter le plan de redirections au fil des découvertes. Les journaux sont ici la source la plus rapide, comme nous l'expliquons dans notre article sur la manière d'analyser les logs serveur d'un WordPress.

Suivre la réexploration

Le nombre de pages explorées par jour et la proportion d'anciennes adresses encore visitées indiquent où en est le transfert. Une exploration qui reste concentrée sur les anciennes adresses après un mois signale un problème de redirection ou un plan de site incorrect. Ce suivi se lit dans les statistiques d'exploration et dans les journaux, et il ne demande que quelques minutes par semaine. Une courbe montrant la part d'anciennes adresses dans le total exploré, semaine après semaine, résume l'essentiel de cette information.

Accepter une baisse temporaire

Une baisse de trafic de dix à vingt pour cent pendant deux à quatre semaines est un comportement normal, même sur une migration parfaitement conduite. Le savoir à l'avance et l'annoncer avant la bascule évite les décisions précipitées prises sous la pression, comme un retour arrière qui aggrave généralement la situation en ajoutant un second changement de structure. Fixer à l'avance le seuil et la durée au delà desquels on considérera qu'il y a un problème évite ces décisions dans l'émotion.

Comparer aux relevés initiaux

Au bout de six à huit semaines, la comparaison avec les relevés effectués avant la bascule permet de juger. Une position par position sur les requêtes suivies, un trafic par section, un volume d'erreurs. C'est le moment où l'on identifie les pages qui n'ont pas retrouvé leur niveau et où l'on cherche pourquoi, page par page plutôt que globalement. Un tableau comparant les positions avant et après, ligne par ligne, rend cette analyse immédiate.

Traiter les pages qui n'ont pas suivi

Les pages ayant perdu du terrain méritent un examen individuel : la redirection est elle correcte, le contenu a t il été appauvri lors de la refonte, le maillage interne vers cette page a t il été conservé. Dans la grande majorité des cas, la cause se trouve dans l'un de ces trois points, et le contenu appauvri en est de loin la première. Restaurer les sections supprimées lors de la refonte suffit souvent à retrouver le niveau antérieur en quelques semaines.

Faire demander les mises à jour de liens

Les liens externes pointant vers d'anciennes adresses continuent de fonctionner grâce aux redirections, ce qui est suffisant. Sur les liens les plus importants, une demande de mise à jour auprès du site émetteur reste préférable, une redirection restant un intermédiaire. Cet effort ne se justifie que pour une poignée de liens, ceux qui apportent réellement du trafic ou de l'autorité. Une demande courte et polie, adressée au bon interlocuteur avec l'ancienne et la nouvelle adresse, obtient un taux de réponse honorable. Cette démarche se conduit dans les trois mois qui suivent la migration, au delà de quoi l'interlocuteur ne se souvient plus du contexte et le taux de réponse chute nettement.