Une migration WordPress sans perdre SEO, ce n’est pas une question de chance. C’est une question de méthode. La plupart des chutes de trafic arrivent pour des raisons simples : URLs qui changent sans redirections, pages passées en noindex, canonicals incohérents, sitemap non à jour, ou erreurs 404 qui explosent après la mise en ligne.
Dans cet article, vous avez un calendrier opérationnel sur 14 jours, avec des points de contrôle concrets (crawl, Google Search Console, logs serveur, redirections, indexation) et des KPI de validation pour savoir, chaque jour, si la migration est sous contrôle.
Pourquoi une migration WordPress fait perdre du SEO (et comment l’éviter)
Google n’indexe pas un “site”. Il indexe des URLs et comprend des relations (contenu, liens internes, canonicals, redirections). Une migration casse souvent ces repères.
Les causes les plus fréquentes :
- Changement d’URL (nouveau thème, nouvelle structure, changement de domaine) sans plan de redirection SEO.
- Redirections 301 WordPress incomplètes, en chaîne, ou vers la mauvaise page.
- Noindex laissé en préproduction ou via un plugin.
- Canonical WordPress qui pointe vers l’ancien domaine, ou vers des URLs non redirigées.
- Robots.txt WordPress trop restrictif, ou sitemap absent.
- Performances en baisse (Core Web Vitals), qui ralentissent le crawl et dégradent l’expérience.
L’objectif n’est pas “zéro variation”. L’objectif est d’éviter les erreurs évitables et de détecter vite ce qui dérape.
Avant J1 : le prérequis indispensable pour ne pas migrer à l’aveugle
Avant de toucher à quoi que ce soit, vous devez figer une photo du site actuel. Sans ça, impossible de vérifier si la refonte WordPress sans perdre le SEO est réussie.
À préparer :
- Accès à Google Search Console (propriété vérifiée) et au serveur / hébergeur.
- Export des pages importantes (celles qui apportent du trafic, des leads, des ventes).
- Un crawl “avant” (liste des URLs indexables, titles, meta descriptions, canonicals, codes HTTP).
- Un point de référence sur l’indexation (pages valides, exclues, erreurs) dans GSC.
KPI de validation (sans chiffres imposés) : vous avez une liste d’URLs de référence, un crawl exporté, et un état GSC clair (indexation + erreurs). Si vous ne pouvez pas comparer “avant / après”, vous pilotez à l’intuition.
Besoin d’un plan de migration sur mesure ? Je peux vous aider à sécuriser trafic, indexation et redirections, avec une méthode claire et des contrôles concrets. Pour voir comment je travaille côté SEO, vous pouvez passer par la page référencement naturel.
Ce que je vérifie pour vous
- Crawl avant/après (codes HTTP, indexabilité, canonicals, pagination)
- Mapping URL et plan de redirections
- Paramétrage Google Search Console (et suivi des signaux)
- Analyse des logs serveur SEO (crawl Googlebot, erreurs, redirections)
- Gestion des 404 et des soft 404
- Sitemap XML WordPress et robots.txt
Jours 1 à 3 : préparer l’inventaire des URL et le plan de redirections 301
Le cœur d’une migration WordPress SEO, c’est le mapping : chaque URL importante doit avoir une destination logique. Pas “toutes vers l’accueil”. Pas “à peu près”.
Jour 1 : inventaire des URLs et priorisation
Faites un inventaire complet :
- URLs indexables (pages, articles, catégories si utiles)
- URLs qui génèrent du trafic (via GSC)
- URLs qui convertissent (formulaires, pages service, pages contact)
KPI de validation : vous avez une liste priorisée (top pages SEO + pages business). Signal d’alerte : vous ne savez pas quelles pages “ne doivent pas bouger”.
Jour 2 : construire le plan de redirection SEO
Créez un tableau simple : Ancienne URL → Nouvelle URL → Type (301) → Commentaire. L’objectif : une redirection unique, directe, vers la page la plus proche en intention.
Cas typiques :
- Changement d’URL WordPress (slug, catégories, structure) : rediriger chaque ancienne page vers sa nouvelle version.
- Migration vers nouveau thème WordPress : attention aux pages supprimées ou renommées.
- Changement de domaine WordPress : redirection globale + exceptions (pages supprimées).
KPI de validation : le mapping couvre toutes les URLs critiques. Signal d’alerte : beaucoup d’anciennes URLs n’ont “pas d’équivalent”. Dans ce cas, décider : recréer, fusionner, ou rediriger vers la page la plus pertinente.
Si vous voulez un avis rapide sur vos priorités (quelles URLs mapper en premier, quelles pages ne pas toucher), vous pouvez vous appuyer sur mon service SEO.
Jour 3 : implémentation et tests des redirections 301
Implémentez les redirections au bon endroit (selon votre stack) : règles serveur, plugin, ou configuration d’hébergeur. Le point clé : éviter les chaînes (301 → 301 → 200) et les boucles.
Mini-checklist actionnable (tests de redirections) :
- Chaque ancienne URL importante renvoie bien en 301 vers la nouvelle URL
- La nouvelle URL renvoie en 200 (pas 404, pas 500)
- Aucune redirection en chaîne (une seule étape)
- Les versions http/https et www/non-www sont cohérentes
KPI de validation : les URLs prioritaires ont un chemin propre “ancienne → 301 → nouvelle (200)”. Signal d’alerte : redirections multiples, ou redirections vers des pages non pertinentes.
Jours 4 à 6 : sécuriser le contenu et les réglages SEO (titles, canonicals, robots, sitemap)
Une refonte casse souvent des détails “invisibles” qui comptent beaucoup : balises, canonicals, indexabilité, sitemap.
Jour 4 : contenu + balises (title, meta description)
Vérifiez que les pages importantes gardent :
- Un title unique, proche de l’intention
- Une meta description propre (même si ce n’est pas un facteur direct, ça joue sur le clic)
- Un seul H1 pertinent
KPI de validation : pas de titles dupliqués en masse, pas de pages importantes avec des titles génériques. Signal d’alerte : un thème qui remplace les titles par le nom du site partout.
Jour 5 : canonicals et cohérence des versions
Le canonical WordPress doit pointer vers l’URL finale (celle qui doit être indexée). Après migration, les erreurs classiques :
- Canonical qui pointe vers l’ancienne URL (ou l’ancien domaine)
- Canonical en http alors que le site est en https
- Canonical vers une URL qui redirige
KPI de validation : sur les pages clés, le canonical correspond à l’URL finale en 200. Signal d’alerte : canonicals incohérents sur des pages stratégiques.
Jour 6 : robots.txt et sitemap XML WordPress
Deux fichiers simples, mais critiques :
- robots.txt WordPress : ne bloquez pas par erreur /wp-content/ utile, ou des répertoires qui contiennent des pages.
- sitemap XML WordPress : il doit lister les URLs finales, pas les anciennes, et exclure les pages non indexables.
KPI de validation : le sitemap contient les bonnes URLs, et GSC peut le lire sans erreur. Signal d’alerte : sitemap qui renvoie des 404, ou qui liste des URLs redirigées.
Jours 7 à 9 : tester en préproduction comme Google (crawl, performances, noindex, maillage)
Avant la mise en ligne, testez comme un robot et comme un utilisateur. Une préproduction sert à ça : détecter les problèmes quand c’est encore facile à corriger.
Jour 7 : crawl avant après migration (comparaison)
Faites un crawl de la préproduction (si possible) et comparez avec le crawl “avant”. Vous cherchez :
- Pages qui passent en noindex
- Pages qui renvoient 404/500
- Maillage interne cassé (liens vers anciennes URLs)
KPI de validation : les pages clés sont crawlables et indexables. Signal d’alerte : beaucoup de liens internes pointent vers des URLs qui vont rediriger (ou pire : 404).
Jour 8 : performances et Core Web Vitals après refonte
Une migration (thème, builder, hébergeur) change souvent le poids des pages. Surveillez :
- Temps de chargement perçu (pages lourdes, images non optimisées)
- Scripts inutiles ajoutés par le thème/plugins
- Cache et compression côté serveur
KPI de validation : les pages business restent rapides et stables. Signal d’alerte : un thème qui multiplie les scripts et dégrade l’expérience.
Jour 9 : noindex, maillage interne, données structurées (si présentes)
Avant la bascule :
- Vérifiez qu’aucune option “Décourager les moteurs” n’est activée.
- Contrôlez le maillage interne : menus, footer, liens contextuels.
- Si vous aviez des données structurées, vérifiez qu’elles sont toujours là.
KPI de validation : pas de noindex global, et les pages clés sont accessibles en 2–3 clics. Signal d’alerte : pages service orphelines, ou liens internes massivement cassés.
Jour 10 : mise en ligne sans panique (checklist minute par minute)
Le jour J, le risque vient surtout des oublis. L’idée : une séquence courte, contrôlée, et vérifiable.
Checklist de mise en ligne
- Mettre à jour DNS / domaine / HTTPS si concerné (selon votre cas)
- Vérifier la version canonique (https, www/non-www) et forcer la cohérence
- Activer les redirections 301 (plan complet)
- Contrôler robots.txt et sitemap
- Faire un test rapide : 10–20 URLs critiques (ancienne → 301 → nouvelle en 200)
- Vérifier qu’il n’y a pas de noindex global
KPI de validation : les pages stratégiques s’ouvrent, se chargent correctement, et les anciennes URLs redirigent proprement. Signal d’alerte : 404 sur des pages importantes, ou redirections vers des pages non pertinentes.
Si vous êtes en plein jour J et que vous voulez une lecture rapide des risques (redirections, indexation, erreurs), je peux vous orienter via la page maintenance WordPress (utile aussi en période de refonte).
Jours 11 à 14 : suivi post-migration au quotidien (GSC, logs, indexation, 404) et quoi corriger
Après la mise en ligne, Google doit recrawler, comprendre les redirections, et réindexer. Votre rôle : repérer vite les erreurs qui bloquent ce processus.
Jour 11 : Google Search Console migration (premiers signaux)
Dans GSC, surveillez :
- Couverture / Indexation : erreurs, pages exclues, “Explorée mais non indexée”
- Sitemaps : lecture OK, URLs prises en compte
- Améliorations (si vous en aviez) : alertes nouvelles
KPI de validation : pas d’explosion d’erreurs critiques, sitemap accepté. Signal d’alerte : hausse rapide des 404, ou URLs importantes qui sortent de l’index.
Jour 12 : logs serveur SEO (comprendre le crawl)
Les logs serveur SEO permettent de voir ce que Googlebot fait vraiment :
- Quelles URLs il visite
- Quels codes HTTP il reçoit (200, 301, 404, 500)
- Si des zones importantes sont peu crawlées
KPI de validation : Googlebot accède aux pages importantes et reçoit des réponses propres. Signal d’alerte : beaucoup de 404/500 vus par Googlebot, ou crawl concentré sur des URLs inutiles.
Jour 13 : gestion des erreurs 404 et soft 404
Les 404 ne sont pas toujours “mauvaises”. Elles deviennent un problème quand elles concernent des URLs qui avaient du trafic, des backlinks, ou des liens internes.
Actions :
- Corriger les liens internes qui pointent vers des 404
- Ajouter des redirections pour les anciennes URLs oubliées
- Vérifier les soft 404 (pages vides, pages proches d’une 404)
KPI de validation : les 404 restantes sont expliquées (pages volontairement supprimées) et ne concernent pas des pages business. Signal d’alerte : 404 sur catégories, pages service, articles piliers.
Jour 14 : indexation après migration et stabilisation
Votre objectif : vérifier que Google comprend la nouvelle structure.
- Contrôler des URLs clés dans GSC (inspection d’URL)
- Vérifier que les pages finales sont indexables et canoniques
- Relancer un crawl “après” et comparer avec “avant”
KPI de validation : les pages importantes sont bien accessibles, indexables, et progressivement prises en compte. Signal d’alerte : pages clés non indexées alors qu’elles sont bien maillées et dans le sitemap.
Si vous voulez que je vous dise quoi corriger en priorité (en fonction de vos signaux GSC, logs et 404), vous pouvez aussi regarder mes services de création/refonte de site et SEO.
Erreurs fréquentes pendant une migration WordPress (et comment les rattraper)
- Rediriger tout vers la page d’accueil : reprenez le mapping URL par URL, au moins pour les pages qui avaient du trafic et des liens.
- Oublier les médias et anciennes URLs d’images : si elles étaient référencées, prévoyez des redirections ou conservez la structure.
- Changer trop de choses à la fois (domaine + structure + contenu + design) : si possible, découpez. Sinon, renforcez les contrôles (crawl/logs/GSC) et documentez chaque changement.
- Bloquer le crawl (robots/noindex) : vérifiez immédiatement robots.txt, réglages WordPress, et les meta robots.
- Canonicals incohérents : corrigez les templates SEO (plugin, thème) pour pointer vers les URLs finales en 200.
- Maillage interne non mis à jour : remplacez les liens vers anciennes URLs pour limiter les redirections et accélérer la compréhension par Google.
FAQ : redirections, changement de domaine, HTTPS, durée de stabilisation SEO
Faut-il tout rediriger en 301 lors d’une migration WordPress ?
Redirigez en 301 toutes les anciennes URLs qui avaient une valeur : trafic, backlinks, liens internes, pages business. Les pages supprimées sans équivalent peuvent rester en 404, mais il faut s’assurer qu’elles ne sont pas importantes (sinon, créez une page de remplacement ou redirigez vers la plus pertinente).
Que faire en cas de changement de domaine WordPress ?
Préparez une redirection 301 domaine à domaine (ancienne URL → nouvelle URL), conservez les chemins quand c’est possible, et vérifiez canonicals, sitemap et propriétés GSC. Le suivi post-migration (indexation, erreurs, logs) devient encore plus important.
Une migration HTTPS WordPress peut-elle faire chuter le SEO ?
Oui si la cohérence n’est pas parfaite : mélange http/https, canonicals en http, ressources bloquées, redirections en chaîne. Une fois le HTTPS forcé proprement et les signaux alignés (sitemap, canonicals, maillage), la situation se stabilise.
Combien de temps pour stabiliser le SEO après une refonte ?
Il n’y a pas de durée universelle. Cela dépend de la taille du site, de la fréquence de crawl, du volume de changements et de la qualité des redirections. Le bon réflexe : suivre chaque jour les signaux (GSC, logs, 404, crawl) et corriger vite ce qui bloque.
Une migration réussie se valide surtout sur 3 points : redirections propres, indexation maîtrisée, et erreurs/crawl sous contrôle. Si vous voulez que je m’en occupe, vous pouvez demander un devis via ma page référencement naturel.
