// guide pilier · écosystème seo
Migration SEO : réussir une refonte sans perdre son trafic.
Une migration ne se sauve pas après la bascule, elle se rend inoffensive avant. Crawl de référence, mapping URL par URL, fenêtre de mise en ligne, contrôles à J+1, et le protocole de suivi sur 90 jours qui distingue une baisse normale d'un vrai problème.
Les 4 types de migration.
Le mot "migration" recouvre des opérations dont les risques n'ont rien de comparable. Identifier le type exact avant de dimensionner le chantier, parce que le plan de bataille en découle entièrement.
Changement de domaine
L'hôte change, la structure reste. Le mapping est mécanique, URL pour URL. Search Console fournit un outil de changement d'adresse dédié qui accélère la prise en compte. Le cas le moins risqué.
→ risque faible
Passage en HTTPS
Techniquement une migration complète, puisque toutes les URLs changent. En pratique le cas le plus sûr, à condition de rediriger en 301 et de corriger les ressources en contenu mixte.
→ risque faible
Refonte avec changement d'URLs
Le domaine reste, les URLs et les gabarits changent. Le mapping doit être établi page par page, et c'est là que les oublis se produisent. Le cas le plus fréquent, et le plus accidenté.
→ risque élevé
Migration cumulée
Domaine, URLs et CMS en une seule opération. Chaque variable masque les effets des autres : en cas de chute, impossible de savoir laquelle est en cause. À éviter, ou à découper.
→ risque maximal
// à retenir
Ne jamais cumuler plusieurs types dans une même bascule. Séparer les chantiers de 4 à 6 semaines coûte du temps projet, mais rend chaque effet mesurable isolément. Si le trafic chute après une migration à trois variables, le diagnostic devient une enquête au lieu d'une lecture.
Le crawl de référence.
L'étape à ne pas rater, parce qu'elle n'est pas rattrapable. Une fois l'ancien site éteint, ses URLs sont perdues : plus de crawl possible, plus d'inventaire. Toute la migration repose sur cette photographie prise avant la bascule.
- 01
Crawler l'intégralité de l'ancien site
Export complet : URL, code de réponse, title, canonical, directive robots, profondeur de clic. C'est l'inventaire de départ, et il doit être exhaustif. Le conserver hors du serveur qui va être éteint.
- 02
Compléter avec les sources que le crawl manque
Le crawl ne voit que ce qui est lié. Ajouter les URLs de Search Console (rapport d'indexation et performances sur 16 mois), celles d'Analytics, et celles du sitemap. Les pages orphelines n'apparaissent que par ce croisement, et ce sont souvent d'anciennes pages qui reçoivent encore du trafic.
- 03
Relever les backlinks entrants
Exporter les URLs qui reçoivent des liens externes. Ce sont les pages à protéger en priorité dans le mapping : une URL avec 40 domaines référents mal redirigée détruit des années de netlinking.
- 04
Figer les métriques de départ
Trafic organique par page sur 12 mois, positions sur les mots-clés stratégiques, nombre de pages indexées. Sans ce point de comparaison, impossible de dire après la bascule si la baisse est normale ou anormale.
Le plan de redirections.
Un tableau à deux colonnes : ancienne URL, nouvelle URL. Sa simplicité apparente est trompeuse, car c'est le document dont dépend l'intégralité du capital SEO accumulé.
1
saut maximum. Chaque redirection supplémentaire dans une chaîne dilue le signal et gaspille du crawl.
12
mois minimum de conservation des 301, jusqu'à 24 si les anciennes URLs portent des backlinks.
Les règles du mapping
- Une correspondance sémantique, pas approximative. Chaque ancienne URL pointe vers la page qui traite le même sujet. La proximité de contenu est le critère, pas la proximité de structure.
- Toujours 301, jamais 302. La 302 est temporaire et ne transfère pas durablement les signaux. Une 302 laissée en place des mois est un des motifs classiques de migration qui ne remonte jamais. Voir page avec redirection.
- Un seul saut. Si A pointait déjà vers B avant la migration et que B devient C, écrire A vers C directement plutôt que de laisser la chaîne s'allonger. Voir erreur de redirection.
- Assumer la 410 quand il n'y a pas d'équivalent. Une page supprimée sans remplacement se déclare en 410. Rediriger vers une page sans rapport pour "ne pas perdre le jus" produit un soft 404 et perd tout de toute façon.
// vérification
Tester le plan avant la bascule : passer la liste des anciennes URLs dans un crawler en mode liste, pointé sur la préproduction. Chaque ligne doit renvoyer un seul 301 vers une URL en 200. Toute ligne qui renvoie un 404, une chaîne ou une boucle est un défaut corrigeable gratuitement à ce stade, et coûteux le lendemain.
La fenêtre de bascule.
Le moment de la mise en ligne se planifie à l'heure près. Les redirections s'activent dans la même opération que le nouveau site : ni avant, ce qui redirige vers des pages inexistantes, ni après, ce qui laisse une fenêtre de 404 que Google crawle et mémorise.
- Choisir un creux de trafic. Jamais pendant une campagne marketing, un pic commercial ou un envoi d'emailing de masse. Un mardi matin d'un mois calme plutôt qu'un vendredi soir de décembre.
- Jamais un vendredi. Si un problème survient, personne n'est là pour le corriger avant lundi, et Google aura crawlé tout le week-end.
- Vérifier le robots.txt et les noindex de préproduction. Le
Disallow: /et le noindex global qui protégeaient la recette doivent sauter à la bascule. C'est l'incident de migration le plus fréquent, et le plus facile à éviter. Voir URL marquée noindex. - Préparer le rollback. Savoir revenir en arrière en moins d'une heure. Une migration sans plan de retour est un pari, pas un projet.
Les contrôles à J+1.
Les vingt-quatre premières heures décident du reste. Un blocage détecté à J+1 se corrige sans conséquence ; le même blocage détecté à J+30 aura fait désindexer des sections entières.
- 01
Recrawler la liste des anciennes URLs
En mode liste, sur la production cette fois. Chaque ancienne URL doit renvoyer un 301 unique vers une URL en 200. Toute 404 dans ce rapport est une page perdue : la traiter le jour même.
- 02
Vérifier l'indexabilité du nouveau site
Crawl complet du nouveau site : robots.txt, directives meta robots, headers X-Robots-Tag, canonical. Chercher en priorité les restes de préproduction. Le protocole complet est dans audit SEO technique.
- 03
Soumettre les sitemaps
Nouveau sitemap dans Search Console immédiatement. Astuce utile : conserver temporairement un sitemap des anciennes URLs, ce qui pousse Google à les recrawler et donc à découvrir les 301 plus vite. Le retirer après 60 à 90 jours. Voir sitemap XML.
- 04
Déclarer le changement d'adresse
Si le domaine change, utiliser l'outil de changement d'adresse de Search Console. Il ne remplace pas les 301, il les complète en accélérant la prise en compte. Voir Search Console.
Accélérer la découverte des pages prioritaires
Google recrawle un site migré à son rythme, et sur un gros catalogue cela prend des semaines. Pour les pages qui portent le chiffre d'affaires, la demande d'indexation manuelle de GSC fonctionne mais reste limitée en volume. Au-delà, un service d'indexation pousse un signal de découverte sur une liste d'URLs, ce qui raccourcit la phase de flottement post-migration.
Le protocole 90 jours.
Une migration ne se juge pas à J+3. Le suivi structuré évite les deux réactions coûteuses : paniquer sur une baisse normale, ou laisser filer un vrai problème en se disant que "Google a besoin de temps".
La baisse attendue
Une baisse de 10 à 20 % est dans la norme : Google recrawle et réévalue. Surveiller le rapport d'indexation quotidiennement, pas les positions. Ne rien changer de structurel pendant cette phase.
→ observer, ne pas agir
Le retour attendu
Le trafic doit revenir vers son niveau initial. S'il stagne encore à moins 30 % à la semaine 6, ce n'est plus un délai, c'est un défaut. Reprendre le mapping et le rapport d'indexation.
→ diagnostiquer
// seuil d'alerte
Le signal qui doit déclencher une enquête immédiate n'est pas la baisse de trafic mais la hausse des pages exclues dans le rapport d'indexation de Search Console. Le trafic réagit avec des semaines de retard ; l'indexation réagit en jours. C'est le seul indicateur avancé disponible pendant une migration.
Les erreurs qui coûtent le plus.
Cinq erreurs expliquent l'essentiel des migrations ratées. Toutes sont évitables, et aucune ne relève de la malchance ou d'un algorithme obscur.
01 Rediriger toutes les anciennes URLs vers la home
Le raccourci qui détruit tout. Google traite ces redirections comme des soft 404 et désindexe. Chaque URL mérite sa correspondance, ou une 410 assumée.
02 Oublier le noindex de préproduction
Le nouveau site part en ligne avec la directive qui protégeait la recette. Invisible pour les visiteurs, catastrophique en trois semaines. Contrôle obligatoire à J+1.
03 Migrer sans crawl de référence
Une fois l'ancien site éteint, l'inventaire est irrécupérable. Sans liste des anciennes URLs, le mapping est impossible à vérifier et les oublis deviennent invisibles.
04 Laisser les liens internes pointer vers les anciennes URLs
Les 301 font le travail, mais chaque lien interne non mis à jour gaspille du crawl et dilue le signal. Mettre à jour le maillage interne vers les URLs finales.
05 Retirer les redirections trop tôt
Au bout de six mois, "ça a l'air stable" pousse au nettoyage. Chaque backlink historique devient alors un lien vers une 404. Minimum 12 mois, 24 si backlinks.
Questions fréquentes.
Combien de trafic va-t-on perdre lors d'une migration ?
Une baisse de 10 à 20 % pendant 2 à 4 semaines est normale : Google doit recrawler l'ensemble des URLs et réévaluer le site. Le trafic revient ensuite à son niveau initial si le plan de redirections est correct. Au-delà de 20 %, ou si la baisse persiste après quatre semaines, ce n'est pas Google qui prend son temps, c'est un problème technique dans le mapping ou la configuration. Chercher la cause immédiatement plutôt que d'attendre.
Faut-il rediriger les anciennes URLs vers la page d'accueil ?
Non, c'est l'erreur la plus destructrice d'une migration. Google traite une redirection massive vers la home comme un soft 404 : il considère que le contenu n'a pas d'équivalent et supprime la page de son index, ce qui détruit l'autorité accumulée par chaque URL. Chaque ancienne URL doit pointer vers son équivalent le plus proche. Quand aucun équivalent n'existe, une 410 assumée vaut mieux qu'une redirection mensongère. Voir soft 404.
Quand activer les redirections 301 ?
Exactement au moment de la bascule, ni avant ni après. Les activer avant redirige vers des pages qui n'existent pas encore et génère des erreurs. Les activer après laisse une fenêtre pendant laquelle toutes les anciennes URLs renvoient des 404 que Google crawle et enregistre. Le plan de redirections doit être testé en préproduction et déployé dans la même opération que le nouveau site, pas dans un lot séparé.
Combien de temps garder les redirections ?
Minimum 12 mois, et jusqu'à 24 mois si les anciennes URLs portent des backlinks. Google a besoin de plusieurs passages pour transférer durablement les signaux, et les liens externes pointant vers les anciennes URLs continuent d'arriver longtemps après la migration. Retirer les 301 trop tôt transforme d'un coup chaque backlink historique en lien vers une 404. Dans le doute, les garder : leur coût est nul.
Faut-il changer les URLs pendant une refonte ?
Si rien ne l'impose, non. Chaque URL modifiée est un risque pris et une redirection à maintenir, pour un gain SEO généralement nul. La structure d'URL n'est pas un facteur de classement significatif, et "des URLs plus propres" ne justifie pas de remettre en jeu l'antériorité de milliers de pages. Ne changer les URLs que si la refonte les rend techniquement inévitables, et dans ce cas les traiter comme le cœur du projet plutôt que comme un détail.
Quelle différence entre changement de domaine et refonte ?
Le changement de domaine conserve la structure et change l'hôte : c'est la migration la moins risquée, et l'outil de changement d'adresse de Search Console la prend explicitement en charge. La refonte conserve le domaine mais change les URLs, les gabarits ou le CMS : plus risquée, car le mapping doit être établi page par page. Le pire cas est de cumuler les deux dans une même opération. Séparer les deux chantiers de plusieurs semaines quand c'est possible. Voir redirection de nom de domaine.
Comment accélérer la reprise après une migration ?
Trois leviers, dans l'ordre. Soumettre le nouveau sitemap dans Search Console dès la bascule, et conserver temporairement un sitemap des anciennes URLs pour que Google recrawle les redirections plus vite. Utiliser l'outil de changement d'adresse si le domaine change. Pousser l'indexation des pages prioritaires via demande manuelle, ou via un service d'indexation quand le volume dépasse ce que GSC permet à la main. Voir forcer l'indexation.
Le trafic n'est pas revenu après 3 mois, que faire ?
À ce stade, ce n'est plus un délai de migration mais un problème identifiable. Vérifier dans l'ordre : le mapping (des URLs à trafic oubliées dans le plan), les chaînes de redirections (chaque saut dilue le signal), les canonical du nouveau site qui pointeraient encore vers les anciennes URLs, et le rapport d'indexation GSC pour repérer une exclusion massive. Neuf fois sur dix la cause est dans le mapping, et elle est réparable même tardivement.
// passer à l'action
Contrôler une URL après bascule.
Le premier réflexe à J+1 : vérifier qu'une page stratégique du nouveau site ne porte aucun blocage hérité de la préproduction.