Migration de site
En SEO, une migration de site est tout changement substantiel apporté à un site web susceptible d'altérer sensiblement sa visibilité dans la recherche : un nouveau domaine, une nouvelle structure d'URL, un nouveau CMS, un nouveau design, un nouveau protocole (HTTPS), ou toute combinaison de ces éléments. Le terme est plus large que « changer d'hébergeur » : du point de vue de Google, une migration est tout ce qui fait changer à grande échelle les URL, le HTML ou les modes d'accès.
En SEO, une migration de site est tout changement substantiel apporté à un site web susceptible d'altérer sensiblement sa visibilité dans la recherche : un nouveau domaine, une nouvelle structure d'URL, un nouveau CMS, un nouveau design, un nouveau protocole (HTTPS), ou toute combinaison de ces éléments. Le terme est plus large que « changer d'hébergeur » : du point de vue de Google, une migration est tout ce qui fait changer à grande échelle les URL, le HTML ou les modes d'accès.
Pourquoi c'est important
Les migrations sont la cause la plus fréquente de désastres SEO auto-infligés. Les enquêtes du secteur montrent systématiquement que 30 à 50 % des migrations de site entraînent des baisses de trafic mesurables, et que 10 à 20 % ne s'en remettent jamais totalement. Les plus grands gains se cumulent : une migration propre préserve l'equity d'entité qu'un domaine a mis des années à construire. Les plus grandes pertes sont brutales : une migration ratée peut faire perdre un chiffre d'affaires mensuel à six chiffres du jour au lendemain et prendre des trimestres à récupérer. Une liste de vérification méthodique avant, pendant et après fait toute la différence entre ces deux issues.
Types de migration de site
Migration de domaine : example.com → newbrand.com. La catégorie la plus risquée. Nécessite des redirections 301 sur chaque URL.
Migration de structure d'URL : /products/abc → /shop/abc. Va souvent de pair avec un changement de CMS.
Migration de plateforme / CMS : WordPress → Shopify, sur mesure → Webflow. Les templates changent ; les URL changent souvent aussi.
Migration de protocole : HTTP → HTTPS. Peu risquée si elle est bien faite, désastreuse si des erreurs de contenu mixte apparaissent.
Refonte / redesign : mêmes URL, nouveau HTML, maillage interne différent, profondeur de contenu différente.
Sous-domaine ↔ sous-répertoire : blog.example.com ↔ example.com/blog. Les deux fonctionnent pour le SEO, mais migrer de l'un à l'autre doit préserver les liens.
Internationalisation : ajout ou restructuration des hreflang et des sous-répertoires par pays.
Liste de vérification avant migration
Crawl complet des URL du site actuel : Screaming Frog ou Sitebulb. Capturez chaque URL indexée, son trafic et ses liens entrants.
Cartographiez les anciennes → nouvelles URL : un tableur avec l'URL actuelle, la nouvelle URL, le statut et le type de redirection. Chaque URL indexée a besoin d'une destination.
Auditez les backlinks : identifiez les pages qui reçoivent le plus de liens externes. Elles doivent conserver leurs redirections même si le reste du site est élagué.
Établissez des métriques de référence : positions, impressions GSC, trafic organique, pages indexées, Core Web Vitals. Vous avez besoin d'une photo d'avant pour mesurer la perte ou le gain.
Préparez le nouveau site sur un environnement de test : explorez-le sur un domaine de dev. Corrigez les liens cassés, les canoniques manquantes et les erreurs de nouvelle structure avant la mise en ligne.
Communiquez avec les parties prenantes : le juridique, le marketing, l'e-mailing et la publicité payante dépendent tous de la stabilité des URL. Les migrations surprises cassent tout.
Liste de vérification de la mise en ligne
Redirections 301 actives avant le basculement : chaque ancienne URL renvoie en 301 vers sa nouvelle URL cartographiée, y compris les pages de catégorie profondément enfouies.
Mettez à jour les balises canoniques vers les nouvelles URL.
Soumettez le nouveau sitemap à la Google Search Console.
Mettez à jour le robots.txt : ne bloquez pas le nouveau site, ne laissez pas l'ancien blocage en place.
Surveillez les 404 et les chaînes de redirection toutes les heures pendant les 24 premières heures.
Surveillez les Core Web Vitals : un changement de plateforme affecte souvent le LCP et l'INP de façon silencieuse.
Gardez l'ancien sitemap accessible pendant au moins quelques semaines pour que Google puisse découvrir les redirections.
Suivi après migration
Semaine 1 : erreurs de crawl, 404, boucles de redirection, chutes soudaines de positions. Comparez quotidiennement les rapports de couverture GSC.
Mois 1 : couverture de l'index, évolutions de positions, écart de trafic par rapport à la référence. Attendez-vous à une baisse temporaire ; elle devrait se stabiliser.
Trimestre 1 : évaluation finale de la récupération. Si le trafic n'est pas revenu à la référence sous 8 à 12 semaines, quelque chose ne va pas structurellement.
Erreurs fréquentes
302 au lieu de 301 : le 302 est temporaire ; Google ne transmet pas tous les signaux. Utilisez le 301.
Chaînes de redirection : ancien → intermédiaire → nouveau gaspille le budget de crawl et fait fuir le signal. Redirigez directement vers l'URL finale.
Perte des liens internes : les nouveaux templates abandonnent souvent l'ancien graphe de liens internes. Réauditez après le lancement.
Oubli de la mise à jour du sitemap : Google continue d'explorer les anciennes URL tant que vous ne lui dites pas le contraire.
Sauter le crawl de l'environnement de test : les problèmes découverts en production sont 10 fois plus difficiles à corriger.
Aucun plan de rollback : si le nouveau site casse, vous avez besoin d'un chemin de retour testé vers l'ancien, au moins pendant les 48 premières heures.
Migrations silencieuses : annoncer la migration à la Google Search Console via l'outil de changement d'adresse (pour les déménagements de domaine) aide Google à reconnaître le déplacement.
Sources :