Migrer un site sans perdre son trafic organique

Les équipes réservent le mot au changement de domaine, puis perdent un tiers de leur trafic sur une refonte que personne n'avait appelée migration. En pratique, quatre types de changement portent le même risque et méritent le même plan : changer de domaine ou de sous-domaine, changer le schéma d'URL, changer de plateforme, et réorganiser le contenu — fusionner des catégories, supprimer des sections, restructurer un catalogue. Une refonte qui conserve toutes les URL est réellement peu risquée ; une refonte qui renomme cent URL de catégorie est une migration, quel que soit l'intitulé du ticket.

Le risque provient du même mécanisme dans les quatre cas. Chaque URL accumulée porte un historique : des liens qui pointent vers elle, des impressions et des clics enregistrés, une évaluation de sa qualité. Cet historique est attaché à l'adresse, pas au contenu. Déplacez le contenu sans déplacer correctement l'adresse et vous repartez de zéro sur une page qui a mis deux ans à gagner sa position.

Le corollaire est rassurant : une migration qui préserve les adresses, ou les apparie une à une, préserve l'historique. Rien dans un changement de plateforme n'est intrinsèquement nuisible au SEO. Ce qui nuit, c'est de perdre l'appariement — et perdre l'appariement relève presque toujours d'un défaut de préparation, pas d'un problème technique.

L'heure la plus rentable d'une migration se passe avant le début des travaux, à archiver l'état actuel. Lancez un crawl complet du site en production et conservez l'export : URL, codes de statut, titres, méta-descriptions, canoniques, hreflang, nombre de mots, nombre de liens internes. Exportez seize mois de données Search Console par page et par requête. Exportez le profil de liens depuis l'index auquel vous vous fiez. Rangez les trois quelque part qui existera encore dans un an.

Figez ensuite une base de performance par gabarit plutôt qu'à l'échelle du site. Pages produit, pages de catégorie, pages éditoriales et page d'accueil se comportent différemment après une migration, et une moyenne globale masquera le seul segment qui a cassé. Notez, avant la mise en ligne, ce qu'ont donné les quatre dernières semaines stables pour chaque gabarit : impressions, clics, position moyenne, nombre de pages indexées.

Cette archive n'est pas de la paranoïa, c'est le seul moyen de répondre à la question qui sera posée en semaine six : « cette page était-elle positionnée avant ? ». Sans elle, chaque discussion sur la récupération devient une affaire d'opinion, et l'équipe dépense son énergie à rejuger ce qui s'est passé plutôt qu'à le réparer.

Bâtir la table à partir du seul export du CMS est l'erreur la plus fréquente, car le CMS ne connaît que les pages qu'il publie actuellement. Il ignore l'ancienne page de campagne qui porte encore quarante liens, l'URL produit retirée qui reçoit deux cents impressions par mois, ou le PDF qu'une revue professionnelle a lié en 2021. Construisez la table sur l'union de trois sources : le crawl, toutes les URL ayant des impressions dans la Search Console, et toutes celles portant des liens externes.

La règle est un pour un vers l'équivalent le plus proche. Quand une page a un remplaçant direct, redirigez vers lui. Quand une page a été fusionnée, redirigez vers la destination de fusion. Quand une page n'a réellement aucun successeur — un produit arrêté sans équivalent — un 410 est honnête et traité plus vite qu'un 404. Ce qu'il ne faut pas faire, c'est rediriger le reliquat non apparié vers la page d'accueil : les moteurs traitent une redirection de masse vers une page générique comme un soft 404, et le signal accumulé est écarté plutôt que transféré.

Deux détails d'implémentation causent l'essentiel des dégâts. Les chaînes : une URL redirigée vers une URL elle-même redirigée gaspille du budget de crawl et dilue les signaux ; aplatissez chaque chaîne pour pointer directement vers la destination finale avant la mise en ligne. Et les détails de forme — protocole, www, barre oblique finale, sensibilité à la casse, paramètres — dont chacun peut silencieusement doubler votre espace d'URL si la nouvelle plateforme les traite différemment de l'ancienne.

Les environnements de préproduction provoquent deux accidents récurrents, tous deux évitables. Le premier : une préproduction indexée parce qu'elle était ouverte ; utilisez une authentification HTTP plutôt que le robots.txt, car un site interdit d'exploration peut tout de même se retrouver listé. Le second est l'inverse, et bien plus coûteux : le `Disallow: /` de préproduction livré en production le jour du lancement, qui désindexe silencieusement tout le site alors que tout paraît normal dans le navigateur.

Sur la préproduction elle-même, explorez-la comme si elle était en ligne et comparez à l'archive du crawl de l'ancien site. Ce que vous cherchez : des titres et méta-descriptions qui ont survécu à la réécriture des gabarits, des canoniques qui pointent où il faut, des grappes hreflang toujours réciproques, des données structurées toujours présentes et valides, des liens internes qui pointent vers les URL finales plutôt que vers des redirections, et le contenu principal présent dans le HTML rendu côté serveur plutôt qu'injecté après hydratation.

Testez ensuite la table de redirections mécaniquement. Prenez l'export du crawl de l'ancien site, demandez chaque URL sur la préproduction, et vérifiez que chacune renvoie une unique 301 vers une destination répondant en 200. Un tableau de mille lignes est fastidieux ; découvrir en production qu'un cinquième renvoie des 404 l'est davantage. C'est aussi le moment de vérifier que le sitemap du nouveau site ne contient que des URL canoniques, indexables et en 200.

Lancez en milieu de semaine, le matin, jamais avant un jour férié. La raison est ennuyeuse et décisive : les quatre premières heures sont celles où l'on découvre ce que la préproduction n'a pas reproduit, et il faut toute l'équipe disponible. Dans cette fenêtre, vérifiez le robots.txt en production, demandez vingt redirections à la main, soumettez le nouveau sitemap, et confirmez dans l'outil d'inspection d'URL qu'une page représentative de chaque gabarit s'affiche avec son contenu, sa canonique et ses données structurées.

Attendez-vous ensuite à un creux. Même bien exécutée, une migration perd généralement de la visibilité pendant deux à six semaines, le temps que le moteur réexplore, retraite les redirections et réévalue les nouvelles URL. La discipline utile consiste à suivre par gabarit face à la base figée, et à distinguer trois formes : un creux peu profond qui remonte régulièrement est normal ; un segment qui reste plat pendant que le reste remonte est un bug d'appariement ou d'indexation ; un effondrement global qui ne bouge pas vient en général d'une ligne du robots.txt ou d'un noindex égaré.

Passé la huitième semaine, la patience cesse d'être une stratégie. Si un gabarit est toujours bas, retournez à l'archive : cette page était-elle positionnée avant, son remplaçant existe-t-il, répond-il en 200, figure-t-il dans le sitemap, est-il lié en interne, porte-t-il la même profondeur de contenu ? En pratique, la grande majorité des migrations non rétablies se ramène à cinq causes — redirections manquantes, chaînes de redirection, noindex resté dans un gabarit, liens internes pointant encore vers les anciennes URL, ou contenu perdu discrètement lors du changement de plateforme. Notre checklist d'audit technique couvre les diagnostics, et la grille de santé SEO aide à ordonner les réparations.