Migration de site SEO : checklist pour ne rien perdre

Tu prépares une migration de site ? Changement de domaine, passage en HTTPS, refonte complète de l'arborescence, migration de CMS, peu importe le scénario, le risque est le même : perdre du trafic organique. Parfois temporairement. Parfois définitivement.

Selon une étude de Moz (2024), 37 % des migrations de sites entraînent une perte de trafic organique supérieure à 30 % dans les 60 jours suivants. La bonne nouvelle : la quasi-totalité de ces pertes sont évitables avec une préparation méthodique.

Cette checklist couvre les trois phases d'une migration SEO réussie, avant, pendant, après, avec des actions concrètes, des outils gratuits et les pièges que personne ne mentionne. Elle s'applique aussi bien à un blog WordPress qu'à un site e-commerce sur Shopify ou un SPA React.

Pour approfondir ce sujet, consultez notre article sur Audit SEO gratuit : checklist complète en 50 points.

Avant de plonger dans la checklist, il faut comprendre ce qui casse. Les migrations ne provoquent pas de pertes parce que Google "punit" les changements, elles échouent à cause d'erreurs techniques prévisibles :

Redirections 301 manquantes (cause numéro un), contenu supprimé ou fusionné sans logique (pages ranking disparaissent), canonical/hreflang mal reconfiguré (Google indexe la mauvaise version), perte de maillage interne (liens pointent vers des 404, crawl budget gaspillé), ou robots.txt/noindex hérités du staging qui bloquent l'indexation.

La règle d'or : une migration bien préparée provoque un creux de trafic de 10 à 20 % pendant 2 à 4 semaines, puis le trafic remonte au niveau initial, voire au-dessus si la nouvelle version corrige des problèmes techniques. Une migration mal préparée peut prendre 6 à 12 mois pour récupérer, si elle récupère un jour.

J'ai suivi un client SaaS qui s'est lancé un changement de domaine un vendredi sans planifier les redirections. Lundi : trafic -68 %. Récupération en trois mois. Ce qui m'a frappé : ce n'était pas une grosse agence, c'était une équipe marketing interne qui croyait maîtriser. Les redirections 301, c'est techniquement basique, mais ça demande une discipline qu'on oublie.

C'est la phase la plus importante. 80 % du succès d'une migration se joue dans la préparation.

Étape 1 : Crawl complet du site actuel#

Lance Screaming Frog (gratuit jusqu'à 500 URL, sinon licence à 199 £/an). Tu dois exporter toutes les URL indexables : pages en 200, sans noindex, avec canonical self-referencing. Les titres, meta descriptions et H1 aussi, tu en auras besoin pour vérifier qu'ils n'ont pas été modifiés accidentellement.

Rapatrie la cartographie complète du maillage interne et les images avec leurs attributs alt (souvent oubliées lors des migrations). Enregistre ce crawl, c'est ta baseline, ton point de comparaison après la migration.

Étape 2 : Inventaire des pages à forte valeur SEO#

Toutes les pages ne valent pas le même coup. Dans Google Search Console, exporte 12 mois de données de performance et identifie tes Top 50 pages par trafic organique (ce sont tes vaches à lait), tes Top 50 par impressions (même si peu de clics, du potentiel) et les pages avec des backlinks externes (Ahrefs Webmaster Tools gratuit ou GSC > Liens).

Classe-les par priorité. Une seule redirect cassée sur ta page n°1 te fait perdre plus de trafic que 50 pages mineures qui cassent.

Étape 3 : Cartographie des redirections 301#

C'est LE livrable critique de la préparation. Crée un fichier CSV (ou Google Sheets) avec :

Règles de base : chaque URL indexée doit avoir une destination (pas générique vers la homepage), les redirections 1:1 autant que possible, fusionner deux pages → redirige les deux vers la fusion, supprimer sans équivalent → redirige vers la page parente thématiquement proche, jamais de chaînes (A→B→C), toujours direct vers la destination finale.

Étape 4 : Vérifier les canonical et hreflang#

Si ton site utilise des canonical personnalisés ou des hreflang (sites multilingues), note la config actuelle. Après migration, chaque canonical doit pointer vers la nouvelle URL, chaque hreflang vers la nouvelle structure.

L'erreur classique : le nouveau site génère des canonical pointant toujours vers les anciennes URL. Résultat : Google ignore les nouvelles pages, continue de référencer les anciennes qui retournent des 404.

Étape 5 : Sauvegarder les données structurées#

Si tu as implémenté du schema markup (JSON-LD), exporte les templates. Les migrations de CMS perdent souvent les données structurées parce qu'elles étaient injectées par un plugin ou un thème spécifique. Vérifie que le nouveau site reproduit au minimum les types Article, BreadcrumbList et Organization.

Étape 6 : Préparer le plan de rollback#

Documentez un plan de retour arrière : combien de temps pour DNS repointing vers l'ancien serveur (TTL bas : 300s pendant migration), snapshot complet de l'ancien site sauvegardé, et seuil de déclenchement du rollback (perte de trafic ou d'erreurs). Le vrai test : tous les intervenants connaissent ce plan.

Un plan de rollback que personne ne connaît n'est pas un plan. Partage-le avec tous les intervenants.

Étape 7 : Configurer le monitoring#

Avant de migrer, mettez en place : Google Search Console configurée pour le nouveau domaine (si changement), UptimeRobot sur les 10 URL les plus critiques, et alertes Search Console par email pour les erreurs de crawl.

Le jour J doit être court et méthodique. Pas de surprises, pas d'improvisation.

Étape 8 : Implémenter les redirections 301#

Applique ton fichier de redirections. Selon ton stack :

• Nginx : fichier de rewrite ou bloc map
• Apache : .htaccess avec RewriteRule
• Next.js : redirects() dans next.config.ts (c'est ce qu'on utilise ici, et ça fonctionne très bien à grande échelle)
• Cloudflare : Page Rules ou Bulk Redirects (pour les gros volumes)

Vérifie immédiatement un échantillon de 20 redirections avec curl -I :

curl -I https://ancien-site.com/article-important/

Tu dois voir HTTP/1.1 301 Moved Permanently avec le bon Location:. Si tu vois un 302 (temporaire), corrige, Google ne transfère pas le PageRank sur les 302 de la même manière.

Étape 9 : Vérifier robots.txt et sitemap#

Le robots.txt autorise-t-il bien le crawl (erreur classique : Disallow: / du staging) ? Le sitemap.xml référence-t-il les nouvelles URL et pas les anciennes ?

Si tu utilises un générateur de sitemap dynamique, force une régénération et vérifie manuellement les 10 premières URL.

Étape 10 : Tester les Core Web Vitals#

Le nouveau site ne doit pas être plus lent que l'ancien. Lance un test PageSpeed Insights sur tes 5 pages les plus importantes. Compare les scores LCP, CLS et INP avec tes valeurs pré-migration.

Si les performances se sont dégradées, identifie la cause avant de poursuivre : nouveau thème non optimisé, images non compressées, scripts tiers ajoutés.

Étape 11 : Valider le maillage interne#

Screaming Frog rapide sur le nouveau site : 0 lien interne cassé (404), 0 redirect interne (301 avant destination), profondeur correcte (pages importantes à moins de 3 clics de la homepage).

Les liens internes cassés après migration sont le signe que le maillage n'a pas été mis à jour. Corrige-les en priorité : ils affectent directement la transmission de PageRank.

Étape 12 : Changement de domaine dans Search Console#

Si tu changes de domaine (pas seulement l'arborescence), utilise l'outil "Changement d'adresse" de Search Console :

1. Vérifie que tu es propriétaire des deux propriétés (ancien et nouveau domaine)
2. Va dans Paramètres > Changement d'adresse sur l'ancienne propriété
3. Sélectionne la nouvelle propriété
4. Google vérifie automatiquement les redirections

Ce signal aide Google à comprendre que le nouveau domaine remplace l'ancien. Sans cette déclaration, le transfert d'autorité prend plus de temps.

La migration n'est pas terminée quand le nouveau site est en ligne. C'est là que le vrai travail de monitoring commence.

Étape 13 : Monitoring quotidien (J+1 à J+7)#

Pendant la première semaine : Search Console Couverture (erreurs, pages exclues), Performance (impressions/clics vs semaine avant), Uptime (alertes UptimeRobot). Quotidien, sans exception.

Un creux de 10 à 20 % des impressions pendant les 3 à 5 premiers jours est normal. Au-delà, il y a un problème.

Étape 14 : Crawl comparatif post-migration#

À J+7, lance un nouveau crawl Screaming Frog et compare avec ta baseline pré-migration :

Chaque écart est une action corrective. Priorise : 404 sur des pages à fort trafic d'abord.

Étape 15 : Surveiller les redirections pendant 90 jours#

Garde tes redirections 301 actives pendant au minimum 12 mois. Idéalement, elles restent permanentes. Supprimer les redirections avant que Google ait complètement transféré l'autorité annule tout le travail.

Vérifie régulièrement (une fois par mois) que les redirections fonctionnent toujours. Un déploiement malheureux ou une mise à jour de serveur peut les supprimer silencieusement.

Étape 16 : Mettre à jour les backlinks#

Contacte les sites qui te font des liens (au moins les 20 plus importants) et demande-leur de mettre à jour l'URL. Oui, les redirections 301 transfèrent environ 90 à 99 % du PageRank, mais un lien direct reste toujours mieux.

Tu peux utiliser Google Search Console > Liens > Sites avec le plus de liens pour identifier les sources prioritaires.

Étape 17 : Soumettre les URL clés à l'indexation#

Dans Search Console, utilise l'outil d'inspection d'URL pour demander l'indexation de tes 20 à 30 pages les plus importantes. Ne soumets pas en masse, Google limite le nombre de demandes quotidiennes et peut ignorer les soumissions excessives.

Pagination et filtres#

Les pages de catégories avec pagination (/categorie/?page=2, /categorie/?page=3) sont souvent oubliées. Si la structure de pagination change, chaque page paginée a besoin de sa propre redirection. Sinon, Google perd des dizaines voire des centaines de pages indexées.

Migration progressive vs big bang#

La migration progressive (section par section) est tentante mais risquée. Elle crée des périodes de transition où deux versions du site coexistent, avec des canonical croisés et des liens internes mixtes. Dans 90 % des cas, le big bang (tout d'un coup) est plus propre et plus facile à monitorer, à condition d'avoir bien préparé.

Les images oubliées#

Google Images génère en moyenne 20 à 25 % du trafic organique d'un site. Si les chemins d'images changent sans redirection (ou si les balises alt disparaissent), ce trafic s'évapore sans que tu t'en rendes compte, parce que la plupart des gens ne monitorent pas le trafic Google Images séparément.

Le cache CDN#

Si tu utilises Cloudflare ou un CDN similaire, purge le cache après la migration. Sinon, les visiteurs (et Googlebot) risquent de voir l'ancienne version du site pendant des heures voire des jours.

HTTPS : le cas particulier#

Le passage HTTP → HTTPS est une migration à part entière. Google traite les versions HTTP et HTTPS comme des URL différentes. Chaque page HTTP doit avoir une 301 vers son équivalent HTTPS. Et les canonical doivent pointer vers HTTPS.

Après une migration propre, tu observeras presque toujours un creux de trafic. C'est normal et attendu. Google doit re-crawler les nouvelles URL, mettre à jour son index, et recalculer les signaux de positionnement.

Le timing typique :

• J+1 à J+3 : baisse de 10 à 20 % des impressions
• J+7 à J+14 : les impressions remontent progressivement
• J+30 : retour au niveau pré-migration (si tout est propre)
• J+60 à J+90 : potentiel de dépassement si le nouveau site est techniquement meilleur

Si à J+30 tu es encore en dessous de 80 % de ton trafic pré-migration, il y a un problème. Reprends ta checklist depuis le début : redirections, canonical, robots.txt, maillage interne. La réponse est dans les détails techniques.

Avant (J-30 à J-7)#

1. Crawl complet du site actuel (baseline Screaming Frog)
2. Inventaire des pages à forte valeur SEO
3. Fichier de redirections 301 exhaustif (1:1)
4. Vérification canonical et hreflang
5. Sauvegarde des données structurées
6. Plan de rollback documenté et partagé
7. Monitoring pré-configuré

Pendant (Jour J)#

1. Implémentation des redirections 301
2. Vérification robots.txt + sitemap
3. Test Core Web Vitals
4. Validation maillage interne (0 lien cassé)
5. Changement d'adresse Search Console (si domaine change)

Après (J+1 à J+90)#

1. Monitoring quotidien J+1 à J+7
2. Crawl comparatif à J+7
3. Redirections actives pendant minimum 12 mois
4. Mise à jour des backlinks externes
5. Soumission des URL clés à l'indexation

Une migration réussie, c'est une migration où personne ne remarque qu'il y a eu une migration. Tes utilisateurs trouvent le même contenu, Google conserve le même classement, et toi tu gagnes un site techniquement meilleur.

Écoute, je dois être honnête : j'ai longtemps pensé que la checklist suffisait. C'est vrai, mais insuffisant. Ce qui tue vraiment les migrations, c'est pas une ligne oubliée dans le CSV de redirects. C'est l'absence de communication interne. Ton équipe support qui ne sait pas qu'il y a eu une migration et qui sert des anciens URLs aux clients. Ton vendeur qui envoie des vieux liens à des prospects. La clé réelle : préparer, communiquer en interne, exécuter, monitorer, dans cet ordre, sans sauter d'étape.