Il y a trois ans, on m'a confié une migration déjà en ligne. Pas d'environnement de staging. Pas de plan de redirection. Un catalogue de 22 000 pages pour l'e-commerce qu'on venait de pointer vers un nouveau domaine et d'appeler « fait ». Le trafic organique a chuté de 74% en six semaines. Le client m'a appelé dans un léger état de panique, et j'ai passé le meilleur part de quatre mois à démêler ça.
Point clé : les migrations de site perdent des classements à cause d'audits de redirections ignorés, non pas à cause des changements de plateforme ; la liste de contrôle comprend la cartographie des redirections, le transport des métadonnées, la continuité du schéma et la vérification après le lancement.
Cette expérience, aussi douloureuse qu'elle ait été, est fondamentalement la raison pour laquelle cette checklist existe. J'ai depuis migré des sites allant de brochures de 800 pages à un éditeur de 31 000 pages avec des sous-domaines régionaux, et les fondamentaux sont les mêmes à chaque fois. Si vous vous trompez dans l'ordre, si vous sautez une étape, Google vous le fera savoir dans Search Console de la manière la plus désagréable possible.
Le voilà. La véritable checklist que j'utilise chez Seahawk Media, pas un cadre théorique.
---
1. Commencez par un crawl complet avant de toucher à quoi que ce soit
Évident ? Oui. Ignoré ? Constamment.
Avant de déplacer un seul fichier, je crawle l'intégralité du site en direct avec Screaming Frog SEO Spider. Sur un site de 20 000 pages, cela prend quelques heures, généralement je le lance le soir avec le crawl stocké en mode base de données pour que la mémoire ne pose pas problème. Ce que je capture :
- Chaque URL indexable (la version canonique, pas le bruit de la pagination)
- Les codes de réponse dans tous les domaines, 200, 301, 302, 404, tout.
- La structure des liens internes existants
- Les balises canoniques, les attributs hreflang le cas échéant
- Les titres de page et les méta descriptions (pour vérifier qu'ils survivent à la migration)
J'exporte l'analyse complète en CSV et je la conserve. C'est ma ligne de base. C'est le document que je comparerai trois semaines après le lancement du nouveau site.
Beaucoup de gens sautent cette étape parce que « on connaît déjà le site ». Vous ne le connaissez pas. J'ai cru connaître le site d'un client du voyage en 2021, il s'avère qu'il avait 4 000 URLs servies depuis un sous-répertoire d'un ancien CMS que personne n'avait mentionné dans le brief. Je l'ai trouvé dans le crawl. Cela aurait été un désastre.
N'oublie pas les données propres de Google
Récupérez tout de Google Search Console, les données de performance des 16 derniers mois minimum, le rapport de couverture d'index, les éventuelles actions manuelles, tous les sitemaps. Et récupérez depuis Google Analytics (GA4 maintenant, bien sûr) pour avoir vos références de trafic organique verrouillées avant que quoi que ce soit change. Les captures d'écran fonctionnent bien ici ; j'exporte aussi les CSV bruts.
---
2. Construisez la carte de redirection. Puis vérifiez-la à nouveau.
C'est là que les migrations réussissent ou échouent. Sur les gros sites, la carte des redirections est une véritable feuille de calcul, généralement partagée dans Google Sheets avec le client, son équipe de développement et toute autre personne qui pourrait accidentellement écraser une formule à 23h.
La structure est simple :
- Colonne A : Ancienne URL (exacte, avec slash final ou sans)
- Colonne B : Nouvelle URL (exacte)
- Colonne C : Type de redirection (301 dans presque tous les cas)
- Colonne D : Statut (mappée, vérifiée, active)
- Colonne E : Notes (redirections fourre-tout, consolidations de catégories, abandons intentionnels)
Sur un site de 20 000 pages, vous ne pouvez évidemment pas mapper chaque URL individuellement. Voici l'ordre dans lequel je procède :
- Mappez d'abord toutes les URLs les plus performantes (par trafic organique depuis GSC, les 500 premières génèrent généralement 80% du trafic)
- Mapper les pages de catégories et taxonomies
- Mappez toute URL qui a des backlinks significatifs (utilisez Ahrefs pour cela, filtrez par domaines référents, pas seulement les liens bruts)
- Gérer les redirections basées sur des motifs pour tout le reste (par exemple, /product/old-slug/ → /shop/old-slug/)
- Documenter les 410 intentionnels pour les pages que vous supprimez
Les redirections basées sur des motifs sont ce que la plupart des développeurs juniors ratent. Ils écrivent une règle wildcard trop large et avalent accidentellement les URLs qu'ils ne voulaient pas rediriger. Testez chaque règle de motif sur staging avant qu'elle n'approche la production.
---
3. Staging n'est pas optionnel
Je vais rester bref parce que cela ne devrait pas demander beaucoup d'explications. Chaque migration obtient un environnement staging. Un point, c'est tout.
Seahawk avait un client fintech en 2022 qui a contesté cela, voulait « juste le faire en direct parce que le site est petit ». Le site avait 6 000 pages. Nous l'avons fait en staging. Nous avons trouvé un conflit de plugin qui supprimait les balises canonical de toutes les pages produit. Cela aurait été invisible jusqu'à ce que Google recrawle tout, ce qui sur un domaine peu autoritaire peut prendre des semaines.
En staging, vous vérifiez :
- Tous les redirects se déclenchent correctement (j'utilise Screaming Frog à nouveau, pointé vers staging, pour vérifier la carte de redirection en masse)
- Robots.txt bloque l'environnement de staging de l'indexation (important, utiliser Disallow: / mais aussi ajouter un en-tête noindex pour une double protection)
- Le nouveau sitemap est exact et ne contient pas d'URLs de staging
- Les balises canonical pointent vers les bonnes URLs de production
- Établir des lignes de base de vitesse de page avec PageSpeed Insights, les migrations sont souvent utilisées comme des opportunités de refonte, et les refontes détruisent fréquemment les Core Web Vitals
---
4. La séquence de mise en live (L'ordre compte plus que vous ne le pensez)
C'est la partie où les gens improvisent et se créent des problèmes. Il y a un ordre spécifique. Je ne m'en écarte pas.
Étape 1 : Avant le lancement (48 heures avant)
- Réduisez le TTL sur tous les enregistrements DNS à 300 secondes (5 minutes). Cela accélère considérablement la propagation.
- Briefez le client : pas de changements de contenu, pas de nouvelles pages, pas de mises à jour de plugins pendant la fenêtre de migration.
- Notifiez les intégrations tierces (CDNs, plateformes publicitaires, outils de monitoring) du changement à venir.
Étape 2 : Fenêtre de lancement
- Mettez à jour les DNS
- Déployer les redirections avant que le nouveau contenu soit entièrement propagé, les redirections doivent être actives au niveau du serveur, pas seulement dans WordPress
- Activez le nouveau sitemap, désactivez l'ancien
- Vérifiez que robots.txt est correct (fichier de production, pas celui de staging)
Étape 3 : Immédiatement après le lancement
- Analysez le nouveau site en deux heures avec Screaming Frog, pointé sur la production, en respectant les redirections. Je cherche des erreurs 404 inattendues, des chaînes de redirection plus longues que deux sauts, et toute page qui devrait être indexable affichant une balise noindex.
- Soumettez le nouveau sitemap dans Search Console
- Récupérez la page d'accueil via l'outil Inspection des URL de GSC pour inviter Googlebot à visiter
Une chose que je signale toujours aux clients : Google ne reflète pas immédiatement les nouvelles URLs dans les résultats de recherche. Il y a un délai de crawl et de retraitement. Sur un grand site, prévoir deux à six semaines avant d'avoir une image claire. Paniquer au jour quatre parce que les classements ont bougé, c'est normal, ça ne signifie pas que quelque chose est cassé.
---
5. Audit des chaînes de redirection (L'étape que la plupart des agences facturent séparément)
Les chaînes de redirection sont une fuite lente. Une URL qui passe de A → B → C → D fait faire du travail supplémentaire à Googlebot, et cela dilue aussi l'équité des liens sur plusieurs sauts. Sur un site qui a connu plusieurs migrations précédentes ou changements de plateforme, les chaînes peuvent devenir surprenamment profondes.
Après le lancement, j'exporte l'exploration complète de Screaming Frog et filtre les chaînes de redirection. Tout ce qui dépasse deux sauts est regroupé. Si l'URL d'origine était sur la carte de redirection, je la mets à jour pour pointer directement vers la destination finale. Si c'était une chaîne héritée d'une migration que personne n'a documentée, je l'ajoute.
Cette étape seule, chez un client que nous avons migré de Magento vers WooCommerce début 2023, a pris deux jours. Ils avaient eu trois migrations en huit ans. Certaines URLs passaient par cinq redirections avant d'arriver à la bonne page. On a tout consolidé, et leurs métriques de crawl budget dans Search Console se sont améliorées notablement en un mois.
---
6. Vérification du contenu à grande échelle
Vous ne pouvez pas examiner manuellement 20 000 pages. Mais vous pouvez vérifier systématiquement ce qui compte vraiment.
Voici ce que je vérifie au cours des deux premières semaines après le lancement :
- Balises de titre et méta-descriptions : Comparez un échantillon aléatoire de 200 pages par rapport à l'export Screaming Frog d'avant la migration. Les incohérences sont signalées immédiatement.
- Données structurées : Lance un échantillon de pages produit, pages articles et homepage dans Google's Rich Results Test. Les migrations cassent le balisage de schéma plus souvent qu'on ne le pense, surtout si le nouveau thème utilise un plugin différent.
- Liaisons internes : Crawl Screaming Frog, filtrez par inlinks. Les pages de haute valeur doivent toujours avoir un nombre solide de liens internes. Si une page de catégorie qui avait précédemment 400 liens internes n'en a maintenant que 12, quelque chose s'est mal passé dans le modèle.
- Images et texte alternatif : Pas strictement critique pour le SEO, mais les images cassées nuisent aux signaux d'expérience utilisateur et elles sont faciles à manquer sur les sites utilisant des modèles.
---
7. Surveillance pendant les 90 jours suivants
La migration ne se termine pas le jour du lancement. Elle dure au minimum 90 jours.
J'ai mis en place des cadences de reporting hebdomadaires avec le client pendant le premier mois, puis tous les quinze jours après. Voici ce que je surveille :
- Couverture d'index GSC : Le nombre de pages indexées se rétablit-il vers le compte pré-migration ? Une baisse importante qui persiste au-delà de trois semaines nécessite une enquête.
- Trafic organique par rapport à la ligne de base : segmenté par type de page de destination (produit, catégorie, blog). Les chutes de trafic sont souvent inégales, parfois les pages de catégories s'effondrent tandis que les pages produits tiennent le coup.
- Budget de crawl : Le rapport de statistiques de crawl de GSC affiche le nombre moyen de pages crawlées par jour et les temps de réponse du serveur. Si Googlebot rencontre beaucoup de 404, cela apparaît ici.
- Suivi de la position de classement : J'utilise une combinaison du suivi de classement d'Ahrefs et du rapport de performance de Google Search Console. La volatilité du classement au cours des deux ou trois premières semaines est courante et n'est pas nécessairement un problème. Les baisses soutenues au-delà de la quatrième semaine justifient une action.
- Profil des backlinks : Utilisez Ahrefs pour vérifier que les backlinks de grande valeur pointant vers les anciennes URLs sont soit déjà redirigés correctement, soit signalés pour une sensibilisation afin de les mettre à jour.
La vérité honnête ? La plupart des problèmes SEO de migration sont détectables dans les 30 jours si vous surveillez les bonnes métriques. Ceux qui posent problème sont ceux où personne n'a mis en place de monitoring et le client le remarque huit mois plus tard.
---
8. Les erreurs que j'ai commises (pour que vous ne les fassiez pas)
En 2019, j'ai raté une implémentation hreflang sur une migration pour un client ayant des sous-dossiers UK, australien et canadien. Les balises canoniques étaient correctes. Les redirections fonctionnaient bien. Mais les annotations hreflang sur le nouveau site avaient les mauvais codes de région, en-au au lieu de en-AU (la casse compte, apparemment, dans certaines implémentations). Google a commencé à servir les pages UK aux internautes australiens. Ça nous a pris six semaines pour comprendre pourquoi le trafic organique australien avait baissé de moitié. On a une étape de validation hreflang dans chaque migration internationale depuis.
Un autre cas : les sitemaps XML contenant des URLs noindexées. Cela semble être une petite incohérence, mais cela envoie des signaux contradictoires et vaut vraiment la peine d'être nettoyé. Screaming Frog peut auditer votre sitemap et signaler toute URL qui retourne une balise noindex.
Et probablement la leçon la plus coûteuse : ne pas avoir de plan de retour en arrière. Lors d'une migration qui tourne mal, la capacité à basculer le DNS vers l'ancien serveur en une heure vaut son poids. J'insiste toujours pour que l'ancien environnement reste actif et intact pendant au moins 30 jours après la migration. Les clients hésitent parfois devant le coût d'hébergement. Je leur explique ce qu'une baisse de trafic de 70 % coûte en revenus et ils arrêtent de rechigner.
---
FAQ
Combien de temps faut-il réellement pour planifier la migration d'un site de 20 000 pages ?
Réaliste ? Six à dix semaines de préparation avant la date de mise en ligne. La carte de redirection seule sur un site de cette taille peut prendre deux à trois semaines à construire correctement, surtout si vous auditez les backlinks pour chaque URL. Précipiter la préparation, c'est finir par passer des mois en phase de récupération.
Dois-je soumettre un fichier disavow après une migration ?
Généralement non, à moins que l'ancien domaine n'ait eu des liens toxiques et que vous fassiez une migration spécifiquement pour en échapper. Si vous migrez vers un nouveau domaine et souhaitez un profil de liens propre, traitez le disavow sur la nouvelle propriété dans GSC. Mais pour la plupart des migrations de plateforme ou de redesign sur le même domaine, disavow est sans pertinence.
Quelle est la plus grosse erreur que vous voyez les agences commettre lors de migrations importantes ?
Traiter la carte de redirection comme une tâche de dev. Les redirections sont une tâche SEO qu'un développeur implémente. L'équipe SEO, ou celui qui détient la stratégie de recherche, doit être propriétaire de la carte, la vérifier et l'approuver. J'ai vu des développeurs construire des règles de redirection techniquement correctes mais SEO-erronées parce que personne ne leur avait dit quelle variante d'URL était canonique.
La vitesse du site affecte-t-elle la migration SEO ?
Oui, plus que ce que la plupart des gens en tiennent compte. Les Core Web Vitals sont un facteur de classement, et les refontes, qui accompagnent souvent les migrations, introduisent fréquemment du JavaScript plus lourd ou des images non optimisées. Toujours faire une comparaison PageSpeed Insights entre l'ancien et le nouveau site avant le lancement. Si le nouveau site est sensiblement plus lent sur mobile, le corriger avant de basculer.
Comment gérez-vous les migrations pour les sites avec beaucoup de contenu généré par les utilisateurs ?
Avec prudence. Les pages UGC sont souvent de faible qualité individuellement, mais collectivement elles génèrent du trafic long-tail. Je recommande généralement une étape de crawl et d'analyse : identifiez les URLs UGC qui ont du trafic organique, redirigez celles-ci spécifiquement, et retournez un 410 pour les autres plutôt que de les laisser en 404. Un 410 indique à Google que la page est intentionnellement supprimée ; un 404 est ambigu.
---
Les migrations sont une de ces choses où la différence entre bon et catastrophique réside presque entièrement dans la préparation. L'implémentation technique est habituellement la partie facile. Faire le travail de pré-lancement correctement, le crawl, la carte de redirection, la vérification du staging, c'est là que le vrai travail se fait. Et si on vous confie une migration qui est déjà en ligne et déjà cassée, la checklist s'applique quand même. Vous le faites juste en sens inverse.