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.

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 : la première cause de perte de trafic. Chaque URL sans redirect est un lien cassé pour Google et pour tes utilisateurs
• Contenu supprimé ou fusionné sans logique : les pages qui rankaient disparaissent, et le trafic avec
• Canonical et hreflang mal reconfigurés : Google indexe la mauvaise version de la page
• Perte de maillage interne : les liens internes pointent vers des URL mortes → le crawl budget est gaspillé
• Robots.txt ou meta noindex oubliés : hérités de l'environnement de staging, ils bloquent toute 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.

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 (version gratuite pour les sites de moins de 500 URL, sinon licence à 199 £/an) et exporte :

• Toutes les URL indexables : pages en 200, sans noindex, avec canonical self-referencing
• Les titres, meta descriptions, H1 : tu en auras besoin pour vérifier qu'ils n'ont pas été modifiés accidentellement
• Les liens internes : cartographie complète du maillage
• Les images et leurs attributs alt : souvent oubliées lors des migrations

Enregistre ce crawl. C'est ta baseline — ton point de comparaison post-migration.

Étape 2 : Inventaire des pages à forte valeur SEO

Toutes les pages ne se valent pas. Dans Google Search Console, exporte les données de performances des 12 derniers mois et identifie :

• Top 50 pages par trafic organique : ce sont tes vaches à lait, elles ne doivent pas casser
• Top 50 pages par impressions : même si elles génèrent peu de clics, elles ont du potentiel
• Pages avec des backlinks externes : utilise Ahrefs Webmaster Tools (gratuit) ou Google Search Console > Liens

Classe ces pages par priorité. Si une seule redirect échoue sur ta page n°1, tu perds plus de trafic que si 50 pages mineures 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 pour les redirections :

• Chaque URL indexée doit avoir une destination — pas de redirect générique vers la homepage
• Les redirections doivent être 1:1 (une source → une destination) quand c'est possible
• Si deux pages fusionnent, redirige les deux vers la page fusionnée
• Si une page est supprimée sans équivalent, redirige vers la page parente la plus proche thématiquement
• Pas de chaînes de redirections (A → B → C) — toujours pointer directement vers la destination finale

Étape 4 : Vérifier les canonical et hreflang

Si ton site utilise des balises canonical personnalisées ou des attributs hreflang (sites multilingues), note la configuration actuelle. Après migration, chaque canonical doit pointer vers la nouvelle URL, et chaque hreflang doit référencer la nouvelle structure.

Erreur classique : le nouveau site génère des canonical qui pointent encore vers les anciennes URL. Le résultat ? Google ignore les nouvelles pages et continue de référencer les anciennes — qui renvoient 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

Que fais-tu si tout casse le jour J ? Documente un plan de retour arrière :

• DNS : combien de temps pour repointage vers l'ancien serveur ? (TTL bas recommandé : 300 secondes pendant la migration)
• Backup : as-tu un snapshot complet de l'ancien site (base + fichiers) ?
• Deadline : à partir de quel seuil de perte (en trafic ou en erreurs) tu déclenches le rollback ?

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, mets en place le monitoring qui te servira après :

• Google Search Console : vérifie que la propriété est configurée pour le nouveau domaine (si changement de domaine)
• Uptime monitoring : un outil comme UptimeRobot (gratuit) sur les 10 URL les plus critiques
• Alertes Search Console : active les notifications par email pour les erreurs d'exploration

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

Deux vérifications critiques :

1. robots.txt : est-ce que le nouveau site autorise bien le crawl ? Erreur classique : un Disallow: / hérité du staging
2. sitemap.xml : est-ce qu'il référence 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

Lance un crawl rapide du nouveau site avec Screaming Frog et vérifie :

• 0 lien interne cassé (pages en 404 pointées par d'autres pages)
• 0 redirect interne (des liens qui passent par une 301 avant d'atteindre la destination)
• Profondeur de crawl : aucune page importante à plus 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, vérifie chaque jour :

• Search Console > Couverture : nouvelles erreurs d'exploration, pages exclues
• Search Console > Performances : évolution des impressions et des clics (compare au même jour la semaine précédente)
• Uptime : les alertes UptimeRobot ne doivent pas se déclencher

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. La clé : préparer, exécuter, monitorer — dans cet ordre, sans sauter d'étape.