Catégorie : Migration & refonte

Selon les données consolidées de plusieurs études de référence sur les migrations de sites, environ 70 % des refontes entraînent une perte de trafic organique mesurable dans les 90 jours qui suivent le lancement. Un site sur trois récupère son niveau d’avant en moins de six mois. Les deux autres mettent entre un et deux ans — ou n’y parviennent jamais. J’ai accompagné des dizaines de projets de migration en tant que consultant SEO indépendant, et la même leçon revient systématiquement : ce n’est pas Google qui punit les refontes, c’est l’impréparation.

Les 30 % qui s’en sortent sans dommage partagent un point commun : ils traitent la migration comme un projet technique à part entière, avec une phase de préparation aussi longue — sinon plus — que la phase de développement. Cette checklist en 30 points est le condensé opérationnel de ce que j’applique sur chaque mission. Elle couvre les quatre horizons temporels critiques : avant la mise en ligne, le jour J, la première semaine, et les 30 à 90 jours de récupération.

Si vous êtes en train de préparer une migration SEO ou une refonte SEO de votre site, lisez ce guide point par point avant de pousser le premier commit en production.

Avant la migration — 12 points préparatoires

La préparation représente 80 % du succès d’une migration. Ces 12 étapes doivent être terminées avant toute mise en production.

1. Crawl complet du site actuel. Lancez Screaming Frog sur l’intégralité du domaine existant. Exportez toutes les URLs indexées (status 200), les redirections en chaîne (301→301), les pages orphelines, et les erreurs (404, 500). Ce fichier est votre référentiel de base — il n’existe pas encore sur le nouveau site.
2. Export GSC — urls, impressions, clics, positions. Dans Google Search Console, exportez les 12 derniers mois de Performance pour toutes les URLs. Filtrez par page, pas par requête. Ce tableau sera votre benchmark post-migration pour détecter les chutes précoces.
3. Export GA4 — sessions organiques par page d’entrée. Dans GA4, créez un segment « trafic organique » et exportez les 90 derniers jours de sessions par page d’entrée. Identifiez vos 20 pages les plus rentables : ce sont celles à surveiller en priorité absolue le jour J.
4. Mapping URL exhaustif. Pour chaque URL de l’ancien site, identifiez son équivalent dans la nouvelle architecture. Utilisez un tableur avec trois colonnes : ancienne URL / nouvelle URL / type de changement (slug identique, slug modifié, contenu fusionné, page supprimée). Chaque ligne sans nouvelle URL est une décision à prendre — rediriger vers la page parent ou retourner un 410.
5. Audit des backlinks entrants. Via Ahrefs ou Majestic, exportez tous les liens externes pointant vers votre domaine. Priorisez les pages cibles avec le plus de domaines référents : ces URLs ne doivent sous aucun prétexte retourner un 404 après la migration.
6. Validation du plan de redirections 301. À partir du mapping URL, rédigez le fichier de redirections complet (`.htaccess`, Nginx, ou règles Cloudflare selon votre infrastructure). Testez-le en staging avant la mise en production. Une règle mal écrite peut rediriger tout le site vers la page d’accueil — j’ai vu ce scénario deux fois.
7. Audit des données structurées (Schema.org). Documentez tous les types de schema en place sur l’ancien site : Organization, BreadcrumbList, Article, FAQPage, LocalBusiness. Vérifiez que le nouveau site les reprend identiquement, ou améliore leur implémentation. Un schema manquant n’est pas une urgence — mais une régression sur les rich results peut faire chuter le CTR même si le ranking tient.
8. Vérification du nouveau sitemap XML. Le nouveau sitemap doit exister en staging avant le lancement, avec toutes les URLs finales et aucune URL d’ancien slug. Vérifiez qu’il ne dépasse pas 50 000 entrées par fichier, qu’il est référencé dans le fichier robots.txt, et que les balises <lastmod> sont dynamiques.
9. Configuration du fichier robots.txt de staging. En environnement de staging, le robots.txt doit bloquer tout crawl (Disallow: /). Vérifiez que ce fichier sera automatiquement remplacé lors du déploiement en production — c’est une erreur classique : le staging bloqué devient prod bloquée, Google n’indexe plus rien.
10. Mise en place du monitoring de disponibilité. Configurez UptimeRobot ou StatusCake pour surveiller l’URL racine, les 5 pages les plus stratégiques, et l’endpoint de l’API si applicable. Fréquence : toutes les 60 secondes. Alertes par SMS et email. Le jour J, toute indisponibilité supérieure à 5 minutes déclenche un diagnostic immédiat.
11. Revue des balises canoniques. Dans le nouveau site, chaque page doit pointer sa propre URL en canonical (<link rel="canonical" href="...">). Vérifiez qu’aucune page ne pointe par erreur vers une URL de l’ancien domaine ou vers une URL de staging.
12. Sauvegarde complète de l’ancien site. Base de données, fichiers, configuration serveur. Stockez cette sauvegarde hors de l’hébergement principal. Si le rollback devient nécessaire, vous avez besoin d’un état stable à restaurer en moins de 30 minutes.

Le jour J — 8 points heure par heure

Le jour de la mise en production est une fenêtre à risque maximal. Organisez votre équipe autour d’un protocole précis, avec un responsable technique joignable en temps réel.

13. Lancement en dehors des heures de pointe. Privilégiez un mardi ou mercredi entre 22h et 2h du matin (heure de Casablanca ou de Paris selon votre audience). Le trafic organique est à son plus bas, les erreurs ont moins d’impact sur les conversions, et votre équipe est disponible pour monitorer jusqu’à l’aube.
14. Déploiement des redirections avant la mise en ligne du nouveau site. Les règles de redirection doivent être actives avant que le nouveau contenu soit accessible. Inversement, si vous activez d’abord le nouveau site, des crawlers peuvent indexer des erreurs 404 pendant la fenêtre de transition.
15. Vérification du robots.txt en production. Dès que le nouveau site est en ligne, chargez https://votredomaine.com/robots.txt dans un navigateur. Confirmez que Disallow: / est absent. C’est la première chose à vérifier — avant même de regarder le design.
16. Test de 20 redirections critiques. Ouvrez votre liste des 20 URLs les plus stratégiques (celles que vous avez identifiées à l’étape 3). Vérifiez manuellement que chacune retourne un 301 vers la bonne destination — pas un 302, pas une redirection en chaîne, pas un 200 avec contenu vide.
17. Soumission du sitemap dans GSC. Connectez-vous à Google Search Console, section Sitemaps. Supprimez l’ancien sitemap si son URL a changé. Soumettez le nouveau. Google ne le recrawlera pas immédiatement, mais cette action signale le changement d’architecture.
18. Crawl léger post-lancement. Lancez un crawl Screaming Frog limité aux 500 premières URLs (profondeur 2) pour détecter les 404 résiduels et les boucles de redirection. Ne cherchez pas l’exhaustivité — cherchez les erreurs sur vos pages prioritaires.
19. Annotation dans GA4 et GSC. Créez une annotation dans GA4 avec la date et l’heure exacte du lancement. Dans GSC, notez la date dans votre suivi manuel. Ces repères sont indispensables pour interpréter correctement les courbes de trafic les semaines suivantes.
20. Surveillance active pendant les 6 premières heures. Gardez ouverts simultanément : GA4 en temps réel, GSC couverture d’index (actualisation lente, mais consultez quand même), UptimeRobot, et votre outil de monitoring de redirections. Toute anomalie détectée dans ce laps de temps se corrige facilement — après 24h, Google commence à mémoriser les nouvelles URLs.

J+1 à J+7 — 5 points de monitoring critique

La première semaine après une migration est la période la plus sensible. Le bot Googlebot recrawle progressivement le site — chaque heure compte.

21. Lecture quotidienne du rapport de couverture GSC. Dans GSC, onglet Indexation, sous-section Pages : surveillez l’évolution des « pages indexées », des « redirections » et des « erreurs ». Une hausse brutale des erreurs 404 signale un problème dans votre plan de redirections. Documentez les chiffres chaque matin à heure fixe.
22. Crawl complet J+3. Lancez un crawl Screaming Frog exhaustif au troisième jour. Exportez toutes les URLs en 404 et en redirection chaîne. Comparez avec votre fichier de mapping — toute URL manquante doit recevoir une règle de redirection dans les 12 heures.
23. Vérification du trafic organique dans GA4. Comparez les sessions organiques J+1 à J+7 avec la même semaine N-1 et N-4. Une baisse inférieure à 15 % est normale (fluctuation de recrawl). Entre 15 % et 30 % : investiguer les pages touchées. Au-delà de 30 % : évaluer le rollback partiel.
24. Contrôle des positions sur les 30 mots-clés principaux. Utilisez GSC Performance ou votre outil de rank tracking pour suivre les positions sur vos mots-clés cibles. Des chutes de plus de 10 positions sur plusieurs mots-clés simultanément indiquent un problème de signal — vérifiez les balises meta robots, les canoniques et les données structurées.
25. Réponse aux erreurs de crawl dans la Search Console. GSC rapporte les erreurs que Googlebot a rencontrées lors de ses tentatives de crawl. Pour chaque URL listée en erreur, décidez : redirection 301 vers l’équivalent, ou 410 si la page est volontairement supprimée. Ne laissez pas les erreurs s’accumuler sans décision.

J+30 à J+90 — 5 points de récupération

Un mois après la migration, Google a recrawlé la majorité de vos pages. La phase de récupération commence : c’est le moment de pousser les signaux positifs.

26. Audit du budget de crawl. Dans GSC, rapport de statistiques d’exploration, vérifiez que Googlebot n’épuise pas son budget sur des URLs de pagination, des URLs avec paramètres, ou des doublons techniques. Bloquez ces ressources via robots.txt ou paramètres GSC pour concentrer le crawl sur vos pages stratégiques.
27. Relance du maillage interne. Passé le recrawl initial, ajoutez des liens internes contextuels depuis vos pages les plus authoritative vers les pages qui ont perdu des positions. Un lien interne bien placé accélère la réévaluation par Google plus efficacement que tout autre levier on-page.
28. Mise à jour des backlinks externes obsolètes. Contactez les sites qui lient encore vers vos anciennes URLs (identifiées via Ahrefs « broken backlinks »). Demandez la mise à jour du lien vers la nouvelle URL — une redirection 301 transmet bien l’équité, mais un lien direct vers la nouvelle URL est toujours préférable.
29. Optimisation des pages qui stagnent. Après J+45, identifiez les pages qui avaient un bon trafic avant migration mais qui n’ont pas récupéré. Conduisez un audit SEO technique ciblé sur ces URLs : vitesse, Core Web Vitals, contenu, signal E-E-A-T. La migration a souvent révélé des faiblesses préexistantes.
30. Rapport comparatif J+90 vs baseline. À 90 jours, comparez vos métriques actuelles avec votre export GSC d’avant migration : impressions, clics, positions moyennes. Ce rapport détermine si la migration est un succès, si elle nécessite des actions correctives complémentaires, ou si un audit SEO approfondi s’impose.

Critères de rollback objectifs

Le rollback est une décision difficile — mais elle doit être prise rapidement quand les signaux l’imposent. Voici les seuils que j’applique :

• Perte de trafic organique supérieure à 40 % sur 7 jours consécutifs par rapport à la période équivalente N-1, sans explication saisonnière documentée.
• Augmentation des erreurs 404 supérieure à 500 URLs sans plan de correction opérationnel dans les 24 heures.
• Blocage total du crawl détecté via GSC (robots.txt mal configuré, meta robots noindex sur l’ensemble du site).
• Perte de plus de 20 positions sur au moins 5 mots-clés commerciaux dans les 72 heures post-lancement.
• Indisponibilité du site supérieure à 2 heures pendant les heures ouvrables, sans date de résolution précise.

Si l’un de ces seuils est atteint : restaurez la sauvegarde de l’étape 12, vérifiez que le DNS est redirigé vers l’ancien serveur, et planifiez une deuxième tentative de migration avec corrections.

Outils nécessaires

Une migration SEO sans outils adaptés revient à naviguer sans carte. Voici les indispensables :

• Screaming Frog SEO Spider — crawl pré et post-migration, détection des 404, chaînes de redirections, balises manquantes. Version payante recommandée (crawl illimité).
• Google Search Console — suivi de l’indexation, erreurs de crawl, performances organiques, soumission du sitemap. Gratuit, indispensable.
• GA4 — trafic organique par page d’entrée, annotations de migration, comparaisons de périodes. Configurez une propriété dédiée si vous migrez de domaine.
• Redirect Mapper / Bulk Redirect Checker — validation en masse de vos règles de redirection avant et après déploiement. Des outils comme httpstatus.io ou Redirect Checker permettent de tester 100 URLs en quelques secondes.
• Ahrefs ou SEMrush — analyse des backlinks entrants, identification des pages à fort capital de liens, suivi de positions post-migration.
• UptimeRobot — surveillance de disponibilité en temps réel. Indispensable les 48 premières heures post-lancement.

Cas type — migration WordPress vers Webflow

WordPress vers Webflow est l’une des migrations les plus fréquentes que j’accompagne en 2025-2026. Elle comporte plusieurs pièges spécifiques.

Le problème des slugs. WordPress permet des slugs avec ou sans extension (/blog/mon-article/ et /blog/mon-article coexistent parfois). Webflow génère des URLs sans slash final par défaut. Vérifiez que vos règles de redirection couvrent les deux variantes, avec et sans trailing slash.

La perte des données structurées Yoast/Rank Math. Yoast et Rank Math génèrent automatiquement les schema JSON-LD (Article, BreadcrumbList, WebSite). Webflow ne le fait pas nativement. Vous devrez soit coder les schema manuellement dans les balises <head> de chaque template, soit utiliser un outil tiers comme Schema App.

Les performances Core Web Vitals. Webflow optimise souvent mieux les images que WordPress (WebP automatique, lazy loading natif). Mais les animations Webflow et les interactions JavaScript peuvent dégrader le LCP si elles ne sont pas configurées correctement. Mesurez les Core Web Vitals dans PageSpeed Insights avant et après.

La gestion du multilingue. Si votre site WordPress utilise WPML ou Polylang, Webflow ne dispose pas d’équivalent natif aussi mature. Les balises hreflang devront être gérées manuellement ou via Weglot — ce qui représente un risque de cannibalisation si les URLs alternatives ne sont pas correctement configurées.

Erreurs spécifiques au contexte marocain

Travailler sur des sites hébergés au Maroc ou ciblant une audience marocaine introduit des spécificités que la documentation internationale ne couvre pas.

Hébergeurs à latence élevée. Plusieurs hébergeurs marocains courants présentent des TTFB (Time To First Byte) supérieurs à 800 ms sur le territoire national — et des temps de réponse bien plus longs depuis l’Europe. Lors d’une migration, si vous changez d’hébergeur, mesurez les Core Web Vitals depuis Casablanca, Rabat et Paris avant de valider le déploiement. Une migration qui améliore le design mais dégrade les performances est une migration à risque.

Yoast vs Rank Math lors du changement de CMS. Si vous migrez de WordPress avec Yoast vers un nouveau CMS, exportez vos métadonnées SEO (title, description, noindex, canonical, schema) via le fichier d’export Yoast avant de désinstaller quoi que ce soit. Ces données ne se récupèrent pas après coup. Rank Math propose un outil d’import Yoast — utilisez-le si vous restez sur WordPress mais changez de plugin SEO dans le cadre de la refonte.

Sites bilingues arabe-français. Les migrations de sites bilingues sont doublement complexes : chaque URL a un équivalent dans l’autre langue, et les balises hreflang doivent être mises à jour dans les deux sens. Un oubli sur les hreflang crée des conflits de canonicalisation que Google peut mettre plusieurs mois à résoudre. Utilisez la documentation officielle Google sur l’internationalisation comme référence pendant votre implémentation.

Changement de domaine (.ma → .com ou inverse). Un changement de domaine est la migration la plus risquée qui soit — c’est une migration d’URL, d’autorité de domaine, et potentiellement de géociblage simultanément. Si vous passez d’un .ma à un .com, configurez le géociblage dans GSC pour le Maroc sur le nouveau domaine, et utilisez le rapport de changement d’adresse Google Search Console pour signaler explicitement le changement.

FAQ migration SEO

Combien de temps faut-il pour récupérer son trafic après une migration ?

En moyenne, entre 3 et 6 mois pour une migration bien préparée avec un plan de redirections complet. Les sites avec un fort capital de backlinks récupèrent plus vite. Si la migration s’est accompagnée d’une amélioration du contenu et des performances techniques, il est fréquent de dépasser le niveau de trafic d’avant migration à 6 mois.

Faut-il prévenir Google d’une migration ?

Oui, via deux actions dans Google Search Console : la soumission du nouveau sitemap XML et, si le domaine change, l’outil « Changement d’adresse » (disponible dans Paramètres GSC). Google ne garantit pas de délai de traitement, mais ces signaux accélèrent la prise en compte des changements d’architecture.

Une redirection 301 transmet-elle vraiment tout le PageRank ?

Google a confirmé que les redirections 301 transmettent la quasi-totalité de l’équité de lien — John Mueller a évoqué une perte négligeable. En pratique, l’impact d’une 301 bien configurée est minime. Le vrai danger vient des redirections en chaîne (301→301→301) qui diluent le signal à chaque saut : limitez à un maximum de deux sauts par chaîne.

Peut-on migrer sans perte de trafic du tout ?

Techniquement oui, mais c’est rare. Une légère baisse de 5 à 15 % dans les deux premières semaines est normale : Google recrawle le site et réévalue les signaux. Ce qui est évitable, c’est la perte prolongée au-delà de 30 jours — elle traduit presque toujours une erreur dans le plan de redirections ou les balises canoniques.

Quand choisir entre une refonte partielle et une migration complète ?

La refonte partielle — changement de design sans modification des URLs ni du CMS — est de loin la moins risquée pour le SEO. Optez pour une migration complète uniquement quand la dette technique ou le changement d’architecture est inévitable. Si vous hésitez, un audit SEO technique préalable vous donnera une vision claire de ce qui peut être préservé.

Quelle est la différence entre migration SEO et refonte SEO ?

Une migration SEO implique un changement d’infrastructure : domaine, CMS, technologie, ou architecture d’URLs. Une refonte SEO désigne la reconstruction du contenu et de l’architecture de l’information, avec ou sans changement technique. Les deux peuvent se combiner — et c’est là que le risque est maximal.

Conclusion

Une migration SEO réussie n’est pas un coup de chance. C’est le résultat d’une préparation méthodique, d’une exécution précise le jour J, et d’un monitoring rigoureux pendant les 90 jours suivants. Ces 30 points couvrent l’intégralité du protocole que j’applique sur mes missions — de la PME marocaine au site e-commerce international.

Si vous préparez une migration et que vous souhaitez un regard externe sur votre plan, je propose un service d’accompagnement complet : de l’audit SEO technique préalable au suivi post-lancement, en passant par la validation du mapping et des redirections. Chaque projet est différent — les risques aussi.

Vous lancez une migration dans les prochaines semaines ? Contactez-moi sur WhatsApp pour qu’on passe en revue votre checklist ensemble — avant que le problème n’arrive.

Parler de ma migration sur WhatsApp