Sécuriser la visibilité SEO lors d'une refonte ou d'un changement de domaine.
SEO seniorUne migration de site est l'un des rares événements qui peut effacer des années de travail SEO en quelques jours. Les causes sont toujours les mêmes : des redirections incomplètes, un sitemap non mis à jour, un fichier robots.txt qui bloque Googlebot en production, des balises canoniques pointant encore vers l'ancien domaine. Ces erreurs ne sont pas des hypothèses — elles se produisent sur presque tous les projets qui n'ont pas intégré le SEO dès la phase de conception.
Google peut mettre plusieurs semaines à traiter un volume important de redirections 301. Les crawl budgets sont limités. Si le nouveau site est mis en ligne sans que les redirections soient testées et complètes, les pages stratégiques disparaissent temporairement des résultats — et "temporairement" peut signifier plusieurs mois. Préparer la migration en amont, c'est compresser ce délai au maximum et éviter les chutes de trafic qui déstabilisent les équipes et les directions.
Avant de toucher à quoi que ce soit, on établit la baseline : crawl complet de l'existant avec Screaming Frog, export des données Search Console (pages, impressions, clics, positions sur les 12 derniers mois), inventaire des backlinks stratégiques. C'est la photo de départ qui permettra de mesurer l'impact post-migration et de détecter les régressions rapidement.
On identifie aussi les pages à risque : celles qui génèrent le plus de trafic, celles qui portent des backlinks de qualité, celles qui sont fortement liées en interne. Ces pages bénéficieront d'une attention particulière dans le mapping d'URLs.
Chaque URL de l'ancien site est associée à son équivalent sur le nouveau. Les règles de priorité : redirection directe 1-to-1 quand la correspondance est évidente, redirection vers la page parente quand une page est supprimée, page 404 uniquement en dernier recours pour les pages sans aucune valeur. Le fichier de mapping est documenté, versionné, et validé avant la mise en production.
On évite les chaînes de redirections (A → B → C) qui diluent le signal et ralentissent le crawl. On vérifie aussi les redirections côté assets (images, PDFs téléchargeables) si ceux-ci génèrent du trafic direct.
Avant de basculer en production, on valide sur le staging : robots.txt non bloquant, sitemap à jour et soumis, balises canoniques pointant vers les nouvelles URLs, balises hreflang cohérentes si site multilingue, Search Console configurée sur le nouveau domaine, GA4 opérationnel. On vérifie également que les redirections sont bien en 301 (permanentes) et non en 302, que le certificat SSL est en place, et que les temps de réponse serveur sont conformes.
La mise en ligne n'est pas la fin du projet : c'est le début de la phase critique. On surveille quotidiennement les erreurs de crawl dans Search Console, les variations de positions sur les mots-clés stratégiques, les 404 générées par des liens internes oubliés, les chutes de trafic sur les pages migrées. On dispose d'un plan de réponse pour chaque scénario d'anomalie.
La plupart des problèmes post-migration sont détectables et corrigeables dans les 48 premières heures si le monitoring est en place. Sans suivi structuré, on peut laisser des erreurs s'installer pendant des semaines sans s'en rendre compte.
Changement de domaine (HTTPS, nouveau TLD, fusion de domaines), migration vers un nouveau CMS (WordPress, WooCommerce, Drupal, headless), restructuration d'URL (suppression de /category/, ajout de sous-dossiers par langue), migration vers une architecture internationale : chaque cas a ses spécificités. L'expérience sur des projets complexes depuis 1996 — dont des migrations multi-domaines pour des groupes médias et des plateformes e-commerce à fort volume — permet d'anticiper les points de friction propres à chaque configuration.