Migration de site et SEO : mapping 301 et protection du trafic lors d’un changement de domaine, de plateforme ou de structure
1. Les trois types de migration et leurs niveaux de risque
Toutes les migrations de site ne font pas aussi mal. Commencez par identifier votre cas, puis décidez du niveau d’investissement.
| Type de migration | Changement d’URL | Cycle de transmission de l’autorité | Niveau de risque | Actions clés |
|---|---|---|---|---|
| Changement de domaine (example.com → new.com) | Toutes les URL changent | 2 à 6 semaines | Élevée | Change of Address + 301 sur tout le site |
| Changement de plateforme (Shopify → développement interne / WordPress → Next.js) | La plupart des URL changent | 2 à 4 semaines | Moyenne à élevée | Mapping ligne par ligne + resoumission du sitemap |
| Modification de l’arborescence (/blog/ → /insight/) | Une partie des URL change | 1 à 2 semaines | Moyenne | 301 en masse via expressions régulières |
| Passage en HTTPS ou ajout de www | Changement de protocole ou de sous-domaine | En 1 semaine | Faible | 301 de tout le site vers le nouveau protocole |
| Refonte sans changer les URL | Aucun changement | Non | Faible | Pas de 301 nécessaire, surveiller les performances et le contenu |
Contre-intuitif : pour une migration qui semble « mineure » comme le passage en HTTPS ou l’ajout de www, si les 301 sont mal écrites et que les versions https et http coexistent, la division de l’autorité sur le long terme coûte bien plus cher qu’une refonte de contenu.Configuration HTTPS et HSTS sont le prérequis technique de ce type de migration.
2. Comment construire la table de mapping 301 : de J-30 au jour J
La table de mapping ne se complète pas après la mise en ligne : c’est le livrable principal à démarrer 30 jours avant.
| Moment | Action | Source des données | Critères de validation |
|---|---|---|---|
| J-30 | Exporter toutes les URL de l’ancien site | XML sitemap + Screaming Frog 爬取 | Couvrir 100 % des URL indexées |
| J-28 | Croiser avec les données de clics des 12 derniers mois dans GSC | Rapport de performance Search Console | Marquer comme prioritaires toutes les URL avec des clics |
| J-21 | Croiser avec les données de backlinks | Ahrefs / Google Search Console 链接 | Les URL avec backlinks ne doivent pas renvoyer un 404 sans raison |
| J-14 | Mapping 1:1 ligne par ligne | Réalisé conjointement par l’équipe contenu et le SEO | 100 % des URL avec des clics ont une nouvelle destination |
| J-7 | Revue technique de la table de mapping | Développement + exploitation | Aucune chaîne de 301, aucune destination en 404 |
| Jour J | Mise en ligne des 301 + soumission des changements | Configuration serveur + Change of Address dans GSC | Vérifier un échantillon de 50 URL : toutes redirigent en 301 vers la bonne page |
Exemple concret : un site B2B industriel migre d’un ancien domaine vers un nouveau domaine de marque, avec 2 300 URL sur l’ancien site. L’équipe n’a pas mappé URL par URL, mais a fait des redirections 301 par répertoire : tout /products/ pointe vers /products/ du nouveau site, tout /blog/ vers /insight/. Quatre semaines après la mise en ligne, le trafic du blog du nouveau site ne représente que 40 % de celui de l’ancien : les anciens articles étaient classés par thème, le nouveau site les classe par année de publication, et la redirection 301 au niveau du répertoire a envoyé tous les articles vers les archives annuelles, faisant perdre toute pertinence thématique. La bonne méthode est un mapping URL par URL : 2 300 redirections se font en 2 jours-homme.
Le principe de mapping est le « thème à thème » : ancienne page produit → nouvelle page produit ; ancien article de blog → l’article le plus pertinent du nouveau site ; une ancienne page sans contenu correspondant redirige en 301 vers la page de catégorie, pas vers l’accueil. Rediriger toutes les anciennes URL vers l’accueil est l’erreur la plus fréquente.
III. Les six actions à faire le jour de la mise en ligne
| Action | Outil | Pourquoi le faire le jour même |
|---|---|---|
| Vérifier 50 redirections 301 au hasard | Screaming Frog / Redirect Path | Une erreur de configuration se corrige le jour même ; attendre une semaine, c’est perdre une semaine de budget de crawl |
| Soumettre le Change of Address | Search Console | Signal officiel de migration pour Google, accélère le recrawl |
| Soumettre le nouveau sitemap | Search Console | Permet à Google de découvrir immédiatement la nouvelle structure d’URL |
| Désactiver le crawl des sessions connectées sur l’ancien site | robots.txt / noindex sur l’ancien site | Éviter que l’ancien site continue d’être crawlé |
| Prévenir les principaux sites de backlinks | E-mail / LinkedIn | Annuaires et partenaires mettent à jour leurs liens vers le nouveau domaine |
| Surveiller la file d’erreurs dans GSC | Search Console | À vérifier chaque jour pendant les 7 premiers jours ; traiter immédiatement toute flambée de 404 |
Lors d’un changement de domaine, pensez aussi à valider Google Analytics, Search Console et les comptes publicitaires sur le nouveau domaine, sinon les données repartent de zéro.Surveillance et alertes du site Les indicateurs doivent être configurés avant la migration pour avoir une base de comparaison après.
IV. Comment juger du succès à T+60 jours
| Indicateur | Fourchette saine | Signal d’alerte | Action immédiate |
|---|---|---|---|
| Clics organiques | Retour à plus de 90 % de l’ancien site à T+60 | Encore sous les 50 % de l’ancien site à T+60 | Revérifier chaque redirection 301 |
| Taux de couverture de l’index | Part de pages indexées ≥ 90 % | « Explorée, non indexée » en masse | Vérifier la qualité du contenu et le budget de crawl |
| Chaînes de 301 | 0 commentaire | Redirections en 2 sauts ou plus | Fusionner en 301 direct |
| Nombre de 404 | Stable à un niveau bas après T+30 | En hausse continue | Exporter le rapport 404 de GSC et ajouter les 301 |
| Core Web Vitals | Pas de baisse après la migration | LCP dégradé de plus de 0,5 seconde | Test de régression des performances sur la nouvelle plateforme |
Deuxième exemple concret : un site B2B migre de WordPress vers Next.js et, à T+30 jours, le trafic organique chute de 35 % ; l’équipe envisage un retour en arrière. En consultant le rapport de couverture de GSC, on découvre que les pages indexées sont passées de 1 800 sur l’ancien site à 600 : le nouveau sitemap ne contenait que les pages produit, tous les articles de blog manquaient. Après avoir soumis le sitemap complété, deux semaines plus tard, l’index remonte à 1 700 et le trafic atteint 92 % de l’ancien site. Ce cas montre que face à une baisse de trafic après migration, il faut d’abord regarder l’index, pas se précipiter pour revenir en arrière.
V. Erreurs courantes et lignes rouges
| Pratique courante | Conséquence | Bonne pratique |
|---|---|---|
| Rediriger toutes les anciennes URL en 301 vers la nouvelle accueil | Risque de soft 404, dilution thématique de l’accueil | Mapping 1:1 des thèmes, page de catégorie uniquement en l’absence de page correspondante |
| Après la migration, les redirections 301 de l’ancien site sont fermées au bout de 3 mois | Perte de l’autorité des backlinks | Conserver les redirections 301 de l’ancien site au moins 12 mois |
| Oubli de modifier la canonical après un changement de domaine | Contenu dupliqué entre l’ancien et le nouveau domaine | La canonical des nouvelles pages pointe vers le nouveau domaine lui-même |
| Oubli de migrer les données structurées lors d’un changement de plateforme | Disparition totale des résultats enrichis | Migrer le Schema avec le template et le valider après migration |
| Interdire l’exploration dans robots.txt le jour de la migration | Google arrête complètement d’explorer le site | Laisser robots ouvert, retirer uniquement le blocage de la session connectée de l’ancien site |
Le Schema doit être validé en même temps pendant la migration,Données structurées Schema Si le template n’est pas repris sur la nouvelle plateforme, les résultats enrichis disparaissent dans les 4 à 8 semaines suivant la migration. Les sites multilingues doivent aussi vérifier Hreflang et versions multilingues s’ils sont migrés avec la structure d’URL.
Six. Comment conserver une base de référence avant et après la migration
Sans base de référence avant la migration, impossible de savoir si une baisse est une fluctuation normale ou un incident. Dès J-30, il faut figer les données clés de l’ancien site dans un instantané, puis comparer chaque semaine après la migration.
| Indicateur de référence | Date de gel | Fréquence de comparaison | Seuil d’alerte |
|---|---|---|---|
| Clics et impressions organiques GSC | Moyenne des 12 dernières semaines à J-30 | Chaque lundi | Alerte si baisse de plus de 20 % sur une semaine |
| Nombre de pages indexées | J-30 | Chaque semaine | Alerte si baisse de plus de 15 % par rapport à la référence |
| Positionnement sur les mots-clés principaux | Top 100 des mots-clés à J-30 | Toutes les deux semaines | Alerte si un mot-clé du top 10 sort du top 20 |
| Nombre total de backlinks et ancres | Export Ahrefs à J-30 | Mensuel | Alerte si perte de plus de 10 % de backlinks |
| Core Web Vitals | Moyenne CrUX à J-30 | Toutes les deux semaines | Alerte si le LCP se dégrade de plus de 0,5 seconde |
Ce tableau de référence doit être prêt avant le jour J. Après la migration, consultez-le une fois par jour la première semaine, puis une fois par semaine. Beaucoup d’équipes ne remarquent la chute de trafic que deux semaines après la migration et découvrent alors qu’aucune référence n’a été conservée, les obligeant à juger à l’instinct. Avec une référence en place, la validation à J+60 repose sur des faits, et non sur un « on dirait que c’est revenu » lancé à l’aveugle.
Autre rappel : ne faites pas en même temps une refonte majeure, un changement de template ou l’ajout de nouvelles fonctionnalités pendant la migration. Ne modifiez qu’une variable à la fois, sinon impossible de savoir si le problème vient des redirections 301 ou du nouveau template. Décomposez la refonte du contenu, l’optimisation des performances et les ajustements Schema en lots à réaliser 30 jours après la migration : le diagnostic des incidents n’en sera que plus simple.
Pendant la migration, surveillez aussi les logs du serveur. De J à J+14, consultez chaque jour le volume de requêtes 404 et 5xx. Si les 404 explosent sur un type d’URL, c’est probablement une catégorie oubliée dans la table de mapping ; si les 5xx explosent, c’est probablement un problème de configuration du serveur du nouveau site, sans lien avec le SEO mais tout aussi critique. Placez les alertes de logs et les rapports GSC sur le même tableau de bord, pour que les équipes technique et SEO partagent la même vue au lieu de regarder chacune la sienne.
Une fois la migration terminée, ne coupez pas tout de suite le serveur de l’ancien site. Gardez les redirections 301 de l’ancien site au moins douze mois. Pendant cette période, connectez-vous chaque mois à la Search Console de l’ancien domaine pour vérifier le trafic organique. Attendez que le trafic soit à zéro pendant deux mois consécutifs, puis confirmez avec l’équipe technique que vous pouvez le mettre hors ligne. Si vous coupez l’ancien site trop tôt, le poids des liens entrants disparaît d’un coup et les efforts des trois derniers mois peuvent être perdus.
FAQ — Questions fréquentes
Faut-il obligatoirement utiliser Change of Address pour changer de domaine ?
Quelle baisse de trafic est normale après une migration ?
Combien de temps faut-il conserver les redirections 301 de l’ancien site ?
Pourquoi les redirections 301 par répertoire ne suffisent-elles pas ?
Faut-il soumettre un nouveau sitemap lors de la migration ?
Que faire si les résultats enrichis disparaissent après la migration ?
Pour conclure
La migration de site est l’une des rares opérations SEO impossibles à annuler : si une redirection 301 est mal configurée, il faut 3 à 6 mois pour reconstituer le poids perdu. Traitez-la comme une mise en production technique, pas comme une livraison de design.
Trois étapes pour réussir : à J-30, exportez toutes les URL de l’ancien site et croisez-les avec les données GSC et de backlinks ; à J-14, finalisez la table de correspondance 1:1 et faites-la valider techniquement ; à J+60, vérifiez les cinq indicateurs et corrigez un par un ceux qui ne sont pas au niveau.
Une phrase à retenir : le succès d’une migration se joue 30 jours avant la mise en ligne. La table de redirections 301 est le livrable clé ; le jour J, il ne reste qu’à l’appliquer.