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.Site migrations lose rankings through skipped redirect audits, not platform changes; the checklist is redirect map, metadata transport, schema continuity, and post-launch verification.
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 du brochureware à 800 pages à un éditeur de 31 000 pages avec des sous-domaines régionaux, et les fondamentaux sont identiques à chaque fois. Vous inversez l'ordre, vous zappez une étape, et 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.Seahawk Media, not a theoretical framework.
---
1. Commencez par un crawl complet avant de toucher à quoi que ce soit
Évident ? Oui. Ignoré ? Constamment.
Avant qu'un seul fichier ne bouge, je crawle le site en direct dans son intégralité avec Screaming Frog SEO Spider. Sur un site de 20 000 pages, cela prend quelques heures -- je le lance généralement la nuit avec le crawl stocké en mode base de données pour que la mémoire ne devienne pas un problème. Ce que je capture :Screaming Frog SEO Spider. On a 20,000-page site this takes a couple of hours -- I usually kick it off overnight with the crawl stored to database mode so memory doesn't become an issue. What I'm capturing:
- Chaque URL indexable (la version canonique, pas le bruit de la pagination)
- Les codes de réponse de tous les côtés -- 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 zappent cette étape parce que « on connaît déjà le site ». Vous ne le connaissez pas. Je pensais connaître le site d'un client du voyage en 2021 -- il s'avère qu'ils avaient 4 000 URLs servies depuis un sous-répertoire CMS hérité dont personne n'avait parlé dans le brief. Je l'ai trouvé dans le crawl. Ça 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 au minimum, le rapport de couverture de l'index, toutes les actions manuelles, tous les sitemaps. Et récupérez Google Analytics (GA4 évidemment) pour que vous ayez vos benchmarks de trafic organique verrouillés avant que quoi que ce soit ne change. Les captures d'écran fonctionnent bien ici ; j'exporte aussi les CSV bruts.Google Search Console -- performance data for the last 16 months minimum, the index coverage report, any manual actions, all sitemaps. And pull from Google Analytics (GA4 now, obviously) so you have your organic traffic benchmarks locked down before anything changes. Screenshots work fine here; I also export the raw CSVs.
---
2. Construisez la carte de redirection. Puis vérifiez-la à nouveau.
C'est là que les migrations réussissent ou échouent. Sur les grands sites, la carte de redirection est un vrai tableur -- généralement partagé dans Google Sheets avec le client, son équipe dev et toute autre personne qui pourrait accidentellement réécrire 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 top 500 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 juste les liens bruts)Ahrefs for this -- filter by referring domains, not just raw links)
- Gérer les redirections basées sur des motifs pour tout le reste (par exemple, /product/old-slug/ → /shop/old-slug/)
/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 s'est opposé à ça -- voulait « juste le faire en live parce que le site est petit ». Le site avait 6 000 pages. On l'a fait en staging. On a trouvé un conflit de plugin qui supprimait les balises canoniques de toutes les pages produit. Ça aurait été invisible jusqu'à ce que Google recrawle tout, ce qui sur un domaine à faible autorité 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)
- Le fichier 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)
Disallow: /but also add a noindex header for 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
- Les bases de référence 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 VitalsPageSpeed Insights -- migrations are often used as redesign opportunities, and redesigns frequently destroy 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 ne soit entièrement propagé -- les redirections doivent être actives au niveau du serveur, pas seulement dans WordPressWordPress
- 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ètera 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 gros site, comptez deux à six semaines avant d'avoir une vue d'ensemble claire. Paniquer le quatrième jour parce que les classements ont changé est normal -- cela 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 au début 2023 -- a pris deux jours. Ils avaient eu trois migrations en huit ans. Certaines URLs passaient par cinq redirections avant d'arriver sur la bonne page. Nous les avons toutes consolidées, et leurs métriques de crawl budget dans Search Console se sont notablement améliorées en moins d'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.: Compare a random 200-page sample against the pre-migration Screaming Frog export. Mismatches get flagged immediately.
- 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.: Run a sample of product pages, article pages, and the homepage through Google's Rich Results Test. Migrations break schema markup more often than you'd think, especially if the new theme uses a different plugin.
- 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.: Screaming Frog crawl, filter for inlinks. High-value pages should still have strong internal link counts. If a category page that previously had 400 internal links now has 12, something went wrong in the template.
- 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.: Not strictly SEO-critical, but broken images hurt user experience signals and they're easy to miss on templated sites.
---
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.: Is the number of indexed pages recovering toward the pre-migration count? A significant drop that persists beyond three weeks needs investigation.
- Trafic organique vs. base de référence : Segmenté par type de page d'atterrissage (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 bon.: Segmented by landing page type (product, category, blog). Traffic drops are often uneven -- sometimes category pages tank while product pages hold.
- 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.: GSC's crawl stats report shows average pages crawled per day and server response times. If Googlebot is hitting a lot of 404s, it shows here.
- 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.: I use a combination of Ahrefs rank tracking and Google Search Console's performance report. Ranking volatility in the first two to three weeks is common and not necessarily a problem. Sustained drops beyond week four warrant 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.: Using Ahrefs, verify that high-value backlinks pointing to old URLs are either already redirected correctly or flagged for outreach to update.
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 avec des sous-domaines au Royaume-Uni, en Australie et au Canada. Les balises canonical étaient correctes. Les redirections allaient 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 utilisateurs australiens. Il nous a fallu six semaines pour comprendre pourquoi le trafic organique australien avait baissé de moitié. Nous avons une étape de validation hreflang dans chaque migration internationale depuis.en-au instead of en-AU(case matters, apparently, in some implementations). Google started serving the UK pages to Australian searchers. Took us six weeks to figure out why Australian organic traffic had halved. We've had a hreflang validation step in every international migration since.
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 dev. Les redirections sont une tâche SEO qu'un développeur implémente. L'équipe SEO -- ou qui que ce soit qui possède la stratégie de recherche -- doit posséder la carte, la réviser et l'approuver. J'ai vu des développeurs construire des règles de redirection techniquement correctes qui étaient SEO-incorrectes 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 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. Lancez toujours une comparaison PageSpeed Insights entre l'ancien et le nouveau site avant le lancement. Si le nouveau site est notablement plus lent sur mobile, corrigez-le 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 l'une de ces choses où la différence entre bon et catastrophique est presque entièrement dans la préparation. L'implémentation technique est généralement la partie facile. Bien faire le travail de pré-lancement -- le crawl, la carte de redirection, la vérification du staging -- c'est là que le vrai travail se fait. Et si vous vous retrouvez jamais avec une migration qui est déjà en ligne et déjà cassée, la checklist s'applique quand même. Vous la faites juste dans le sens inverse.