Migration de site sans perdre votre SEO : la checklist

Une migration de site mal préparée peut anéantir 5 ans de travail SEO en 48 heures. Sur les 12 migrations PME que nous avons auditées en 2025, la perte moyenne de trafic était de 38 % le mois suivant la mise en ligne. Trois sites n’ont jamais récupéré leur niveau initial.

À l’inverse, une migration bien préparée perd 5 à 15 % de trafic temporairement, puis dépasse le niveau pré-migration en 90 jours. L’écart entre les deux scénarios n’est jamais une question de chance : c’est une question de méthode.

Cet article détaille la checklist en 14 points pour migrer un site PME sans perdre de trafic. Avec exemples, outils, planning type et erreurs critiques à éviter.

Les trois types de migration SEO

Toutes les migrations ne portent pas le même risque. Il est essentiel de classer la vôtre avant de commencer.

Type 1 — refonte de design sans changement d’URL. Risque : faible. Le contenu reste, les URLs restent, seul le rendu change. Perte typique : 0-5 %. C’est le scénario le plus sûr.

Type 2 — changement de CMS avec adaptation des URLs. Risque : moyen. Passer de WordPress à Shopify, ou de Wix à Webflow, implique souvent des structures d’URLs différentes. Perte typique : 10-25 % si bien préparé, 40-60 % sinon.

Type 3 — changement de nom de domaine et/ou refonte complète. Risque : élevé. Tout change en même temps : domaine, URLs, design, parfois contenu. Perte typique : 15-30 % bien préparé, jusqu’à 80 % sinon.

Quelle que soit la catégorie, la méthode est la même. Seule l’intensité du suivi varie.

Phase 1 — Inventaire avant migration (3-5 jours)

C’est l’étape la plus critique. Sans inventaire complet, impossible de garantir un mapping propre.

Point 1 — Crawl complet du site actuel

Screaming Frog (gratuit jusqu’à 500 URLs, 199 £/an au-delà) ou Sitebulb. Export complet avec : URL, status code, title, meta description, H1, canonical, nombre de liens internes entrants.

Pour un site PME de 200 pages, comptez 30 minutes de crawl + 1 heure d’analyse.

Point 2 — Liste des URLs avec trafic et autorité

Search Console → export du rapport « Performances » sur les 12 derniers mois. Liste des URLs qui ont reçu au moins 1 clic.

Ahrefs ou Semrush → liste des URLs avec backlinks externes. C’est l’information la plus précieuse : ces URLs portent l’autorité du site.

Point 3 — Identification des pages stratégiques

Croisement des deux exports précédents. On obtient 4 catégories :

• Pages avec trafic + backlinks → priorité absolue, redirection 301 obligatoire
• Pages avec trafic uniquement → priorité haute
• Pages avec backlinks uniquement → priorité haute
• Pages sans trafic ni backlinks → candidates à la suppression

Sur un site PME standard, 20 % des pages génèrent 80 % du trafic. C’est ce 20 % qu’il faut sécuriser en priorité.

Phase 2 — Préparation du mapping (5-10 jours)

Le mapping est le document central de la migration. Un tableur 2 colonnes : ancienne URL → nouvelle URL. Sans approximation, sans oubli.

Point 4 — Mappage URL par URL

Pour chaque URL ancienne, déterminer la nouvelle URL équivalente. Trois cas possibles :

1. URL conservée à l’identique — aucune action nécessaire (idéal)
2. URL modifiée — redirection 301 vers la nouvelle URL
3. URL supprimée — redirection 301 vers la page la plus proche thématiquement, ou 410 si vraiment inutile

Pour 500 URLs, comptez 6-12 heures de travail. Ne jamais sous-traiter cette étape à un développeur sans contexte SEO : c’est l’erreur la plus fréquente.

Point 5 — Test du mapping en environnement de staging

Le site refait est déployé en staging (généralement staging.votresite.fr ou dev.votresite.fr). Crawl complet du staging avec Screaming Frog, comparé au mapping.

Toute incohérence est corrigée avant la mise en prod. Cette étape évite 70 % des incidents de migration.

Point 6 — Vérification des balises critiques

Sur chaque URL stratégique du staging :

• Balise title transférée et adaptée
• Meta description transférée et adaptée
• Balise H1 cohérente
• Balise canonical correcte
• Schema.org transféré (Organization, Article, Product, etc.)
• Open Graph et Twitter Cards transférés

L’oubli des balises canonical est l’erreur la plus fréquente. Conséquence : duplication massive entre staging et prod après bascule.

Phase 3 — Validation technique (3-5 jours)

Avant le go-live, vérifications structurelles.

Point 7 — Audit Core Web Vitals du nouveau site

Lighthouse + PageSpeed Insights sur 10 pages représentatives. Le nouveau site doit avoir des Core Web Vitals au moins équivalents à l’ancien. Idéalement meilleurs.

Une migration qui dégrade la vitesse de chargement perd 10-20 % de trafic supplémentaire en raison de la baisse de classement post-CWV. Pour une vérification approfondie, lisez notre guide sur l’optimisation de la vitesse.

Point 8 — Validation robots.txt et sitemap

Le nouveau site doit avoir :

• Un fichier robots.txt cohérent (pas de Disallow: / accidentel)
• Un sitemap.xml généré et accessible
• Le sitemap référencé dans robots.txt

Erreur fatale classique : oublier de retirer le Disallow: / du staging qui empêche tout crawl. À vérifier en priorité absolue.

Point 9 — Test des redirections en staging

Si le mapping inclut 300 redirections, testez-en au moins 50 manuellement et 100 % via Screaming Frog en mode « Liste ». Aucune redirection en chaîne (302 puis 301, ou 301 puis 301).

Une chaîne de redirections perd 5-15 % d’autorité par saut. À éviter à tout prix.

Phase 4 — Go-live et bascule (1 journée)

L’heure du basculement réel. Plan d’action heure par heure.

Point 10 — Choix du moment

Pas un vendredi soir (impossible à gérer le week-end). Pas en pleine période d’activité commerciale (Black Friday, soldes, Noël). Idéal : mardi ou mercredi matin, créneau 9h-12h.

Point 11 — Bascule technique

Ordre des opérations en production :

1. Mise en place des redirections 301 (fichier .htaccess, _redirects, ou config nginx)
2. Bascule DNS si changement de domaine ou d’hébergement
3. Vérification immédiate avec curl ou Postman des codes HTTP
4. Crawl partiel des URLs prioritaires
5. Soumission du nouveau sitemap à Search Console
6. Si changement de domaine : Change of Address Tool dans Search Console

Pour la gestion fine des redirections, voyez notre guide sur les redirections 301.

Point 12 — Communication aux moteurs

Pour un changement de domaine, le « Change of Address Tool » dans Search Console (ancienne propriété → nouvelle) accélère le transfert de 50-70 %.

Soumission du sitemap : Search Console + Bing Webmaster Tools.

Notification aux principaux backlinks externes : email aux partenaires importants pour mise à jour des liens (optionnel mais payant).

Phase 5 — Suivi post-migration (30-90 jours)

C’est dans cette phase qu’on récupère ce qui a été perdu. Surveillance quotidienne pendant 14 jours, puis hebdomadaire pendant 60 jours.

Point 13 — Monitoring des KPIs critiques

Indicateurs à suivre quotidiennement les 14 premiers jours :

• Trafic organique — Search Console + Analytics. Une baisse < 20 % est normale.
• Pages indexées — Search Console. Doit converger vers le niveau pré-migration en 30 jours.
• Erreurs de crawl — Search Console → « Indexation ». Toute hausse est à investiguer.
• 404 et soft 404 — Search Console. Liste à traiter en continu.
• Positions clés — Top 50 mots-clés stratégiques. Suivi quotidien.

Point 14 — Itérations correctives

Chaque problème détecté en monitoring déclenche une correction immédiate. Le pire scénario est d’attendre pour voir : Google ancre les nouvelles positions en 30-60 jours. Une correction tardive prend plus longtemps à porter ses fruits.

Sur les 14 jours suivant le go-live, prévoyez 5-10 heures de monitoring et corrections. C’est le moment où l’investissement préparatoire paye.

Les erreurs fatales à éviter

Sept erreurs qu’on retrouve sur 80 % des migrations ratées.

Erreur 1 — pas de mapping. Le développeur a refondu sans connaître les URLs critiques. Toutes les redirections sont génériques (vers l’accueil). Perte : 50-80 % de trafic.

Erreur 2 — Disallow: / oublié. Le robots.txt du staging bloque tout. Au passage en prod, le bloquage est conservé. Le site disparaît de Google en 7-14 jours.

Erreur 3 — chaînes de redirections. URL A → URL B → URL C. Perte d’autorité, latence HTTP, signal négatif. Toujours rediriger vers la destination finale.

Erreur 4 — changement de structure URL inutile. Le nouveau CMS impose un format différent (« /products/123 » au lieu de « /audit-seo »). Si vous pouvez configurer le nouveau CMS pour garder les anciennes URLs, faites-le.

Erreur 5 — pas de Change of Address Tool. En cas de changement de domaine, oublier cette étape ralentit le transfert de 3 à 6 semaines.

Erreur 6 — pas de version staging. Tester en prod, c’est garantir des bugs sur le SEO et l’expérience utilisateur. Toujours staging d’abord.

Erreur 7 — pas de monitoring post-migration. « Ça a l’air OK, on passe à autre chose ». Trois mois plus tard, le client se rend compte qu’il a perdu 60 % de trafic. Trop tard pour intervenir efficacement.

Cas particuliers à connaître

Migration HTTP vers HTTPS

Le cas le plus fréquent. Aujourd’hui, 95 % des PME sont déjà en HTTPS, mais les retardataires existent encore. Pour cette migration :

• Certificat SSL configuré et vérifié
• Redirections 301 HTTP → HTTPS au niveau serveur
• Tous les liens internes en HTTPS (pas de mixed content)
• Mise à jour du sitemap avec URLs HTTPS
• Nouvelle propriété HTTPS dans Search Console

Pour les détails complets, voyez notre guide sur la migration HTTPS.

Migration WordPress → Astro/Next.js

De plus en plus fréquent en 2026. Avantages : performance massive, SEO technique propre. Risques : changement de gestion de contenu, perte des plugins SEO.

Points critiques : migration manuelle des Schemas, recréation des sitemaps, gestion fine des redirections. Comptez 4-8 semaines pour un site PME standard.

Migration multi-domaines

Plusieurs domaines fusionnés en un seul. Risque très élevé : chaque domaine a son historique, ses backlinks, son autorité. Le bon mapping est crucial.

Recommandation : faire appel à un expert SEO pour cette configuration. L’enjeu financier dépasse souvent le coût d’expertise.

Le planning type pour 200-500 URLs

Pour une PME standard, voici le planning recommandé.

Semaines 1-2 — préparation

• Crawl et inventaire
• Export Search Console et Ahrefs
• Mapping initial

Semaines 3-4 — staging

• Déploiement en staging
• Tests de mapping
• Validation balises et Core Web Vitals

Semaine 5 — pré-production

• Tests finaux
• Validation des redirections
• Communication interne (équipe, prestataires)

Semaine 6 — go-live

• Bascule en prod
• Monitoring intensif jour 1-7

Semaines 7-10 — stabilisation

• Corrections itératives
• Monitoring quotidien
• Soumission Search Console

Semaines 11-16 — récupération

• Monitoring hebdomadaire
• Optimisations complémentaires
• Bilan final

En résumé

Une migration sans perte SEO est possible mais demande de la rigueur. 14 points à couvrir, 3 à 8 semaines de préparation, et un suivi post-migration de 90 jours. C’est un projet complet, pas une tâche annexe.

Le mapping est le document central : 6-12 heures de travail pour 500 URLs, et le succès ou l’échec de la migration en dépend à 60 %.

Si vous voulez qu’on prenne en charge votre migration ou qu’on valide votre plan, contactez-nous. Sinon, commencez par l’inventaire ce week-end. Vous saurez en 2 heures si votre projet est plus simple ou plus complexe qu’il n’y paraît. Et pour situer cette opération dans un cadre global, consultez notre checklist d’audit SEO technique avant et après migration.

Questions fréquentes