Corriger les problèmes SEO après une migration WordPress : commencez par la vérité des URL

TL ; DR : Votre migration WordPress n’a sans doute pas « cassé le SEO ». Elle a coupé le chemin entre anciennes URL, nouvelles URL, redirections, balises canoniques, sitemaps, liens internes et, désormais, citations d’IA. Le correctif commence donc par la cohérence des URL, pas par un nouveau contrôle de plugins.

La migration n’a pas tué votre SEO. Ce sont les URL brisées qui l’ont fait.

La plupart des gens diagnostiquent les problèmes de wordpress migration seo par le mauvais bout. Ils se demandent si WordPress, le nouveau thème, l’hébergeur ou le plugin SEO a provoqué la chute. L’un de ces éléments est parfois en cause, généralement parce qu’il a rompu la continuité des URL.

Chez mindnow, j’ai vu des migrations WordPress où le contenu était intact mais où le classement chutait quand 600 anciennes URL étaient redirigées discretement vers la page d’accueil. Je vérifie cela avant même d’ouvrir seojuice.io ou vadimkravcenko.com.

Les gains les plus rapides sont souvent ennuyeux : ancienne URL, nouvelle URL, code HTTP, canonique, indexabilité, présence dans le sitemap et liens internes. Dans cet ordre — pas les titres, pas le schéma, pas Core Web Vitals.

Joost de Valk, fondateur de Yoast SEO, résume les migrations de domaine réussies : « 90 % de préparation, 10 % d’exécution. » La formule reste valable après un lancement raté : si la préparation n’a pas eu lieu avant la bascule, la réparation n’est qu’une préparation différée.

La mission consiste à prouver que Google peut toujours relier l’ancienne demande aux nouvelles destinations. S’il n’y parvient pas, réécrire le contenu relève du théâtre.

Avant toute chose, qualifiez la chute

Toutes les baisses de trafic post-migration n’ont pas la même origine. Un changement d’hébergeur, de domaine, de permaliens, de thème, d’import CMS ou de plugin SEO peuvent produire le même graphique : sessions organiques en baisse, stress généralisé.

La première fourche de diagnostic est simple : Google a-t-il perdu l’URL, s’est-il méfié de la nouvelle URL ou a-t-il mal compris le lien entre les deux ?

Ne réécrivez pas de contenu avant de savoir si Google peut atteindre, comprendre et faire confiance à la nouvelle URL. Un article avec une balise noindex n’a pas besoin d’un meilleur titre. Une catégorie produit canonique vers l’ancien domaine n’a pas besoin de plus de texte. Une landing page redirigée vers la page d’accueil n’a pas besoin de balisage schema.

Classez d’abord. Réparez ensuite.

Reconstruisez la cartographie des URL, même si la migration est passée

John Mueller a donné la version la plus claire de ce conseil lors d’un SEO Office Hours de Google, repris par Search Engine Journal :

« Le plus important est vraiment de suivre les URL individuelles, afin d’avoir une cartographie claire entre ce qui existait et ce qui doit exister. »

Les « URL individuelles » comptent dans WordPress. Il ne s’agit pas seulement des articles et pages. WordPress crée des surfaces via le thème, les plugins, les archives, la gestion des médias, les filtres et d’anciens permaliens. Si vous n’avez migré que le menu visible, vous avez probablement raté la moitié du site.

Surfaces d’URL WordPress souvent oubliées

• Articles et pages
• URL produits WooCommerce, catégories produit et base /shop
• Catégories, étiquettes et taxonomies personnalisées
• Archives auteur
• Archives par date si elles étaient indexables
• Pages de pièces jointes et URL médias
• Archives de types de contenu personnalisés
• Archives paginées
• Flux RSS
• anciens permaliens ?p=123 (encore actifs sur des vieilles installs)
• Variantes avec et sans slash final
• Variantes HTTP / HTTPS
• Variantes www / sans www
• Anciennes URL de staging ou d’hébergement temporaire divulguées

Partez des preuves, pas des souvenirs. Exportez les pages d’atterrissage depuis l’analytics. Exportez les pages principales depuis Google Search Console. Crawler le site actuel. Récupérez tout crawl pré-migration, s’il existe. Ajoutez les URL issues de backlinks si vous y avez accès. Fusionnez ensuite le tout dans une cartographie ancien → nouveau.

Oui, c’est la partie tableur — c’est aussi là que commencent la plupart des récupérations (les audits que j’ai récupérés chez mindnow ramenaient toujours à une colonne manquante dans la feuille précédente). Utilisez des colonnes pour ancienne URL, nouvelle URL, statut HTTP, cible de redirection, cible canonique, indexabilité, présence dans le sitemap et remarques. S’il n’existe aucune destination équivalente, dites-le. Ne le cachez pas derrière un fallback vers la page d’accueil.

Pour les sites volumineux, priorisez les URL avec backlinks, revenus, clics organiques, conversions ou citations IA. Une archive de tag morte de 2017 peut attendre. Une catégorie produit qui générait des ventes non-marquées, non.

Réparez les redirections avant de toucher aux titres, contenus ou schémas

La documentation officielle de Google sur les déménagements de site stipule :

« Conservez les redirections le plus longtemps possible, au moins un an en général. »

Cette ligne devrait être affichée au-dessus de chaque checklist de migration WordPress. Les redirections disparaissent de façon banale : suppression du bloc .htaccess, désactivation d’un plugin de redirection après nettoyage, migration d’hébergeur qui efface les règles Nginx, règles Cloudflare remplacées, ancien domaine expiré, domaine de staging supprimé. Personne ne remarque avant que Search Console ne ressemble à une scène de crime.

Une redirection n’est utile que si la destination répond à la même intention. Ancien article vers nouvel article équivalent. Ancien produit vers produit équivalent. Ancienne catégorie vers catégorie équivalente. Ancienne page service vers la page service survivante la plus proche. Si la destination est hors sujet, le 301 technique ne préserve pas la valeur SEO.

Si vous cherchez un processus, suivez celui-ci :

1. Crawler la liste des anciennes URL et relever tous les codes HTTP.
2. Marquer toute chaîne 3xx de plus d’un saut.
3. Marquer toute ancienne URL qui finit sur la page d’accueil.
4. Vérifier que la destination finale est indexable.
5. Confirmer que la page finale se canonicalise vers elle-même ou vers le canonique prévu.
6. Déplacer les redirections à forte valeur hors des plugins fragiles et vers le serveur ou l’edge quand c’est possible.

Si vous utilisez un plugin, exportez ses règles avant toute modification. Redirection, Rank Math, Yoast Premium et les panneaux de redirection côté hébergeur fonctionnent tous. Le problème est souvent la propriété : personne ne sait quelle couche est maîtresse.

La redirection vers la page d’accueil n’est pas un filet de sécurité

Google prévient qu’un grand nombre de redirections vers une destination non pertinente (la page d’accueil, par exemple) peut être traité comme un soft 404. C’est fréquent sous WordPress : un admin voit des centaines de 404 dans un plugin et crée un fallback global vers /. Le tableau de bord paraît plus propre ; le trafic, moins.

La solution est plus lente mais plus sûre : faire correspondre chaque ancienne URL à la destination équivalente la plus proche. S’il n’y a pas d’équivalent, retourner un vrai 404 ou 410. Laissez mourir honnêtement les URL mortes. Préservez les pages importantes avec des redirections une-à-une.

C’est particulièrement douloureux pour l’e-commerce. Un produit arrêté mérite peut-être une redirection vers son remplaçant ou vers la catégorie parente. Un produit supprimé sans équivalent mérite un 410. Le rediriger vers la page d’accueil n’apprend rien à Google.

Surveillez la fenêtre de 180 jours du Changement d’adresse

L’outil Changement d’adresse de Google Search Console aide Google à traiter un déménagement de site, mais ne remplace pas les redirections. L’aide précise que l’outil traite les signaux pendant 180 jours ; pas indéfiniment.

Au-delà, Google ne considère plus les anciens et nouveaux sites comme liés si l’ancien est toujours accessible. Leçon pratique : les redirections doivent survivre à la fenêtre de 180 jours. Si l’ancien hébergement est coupé au cinquième mois, vous créez une falaise.

Vérifiez les réglages WordPress qui bloquent silencieusement la reprise

WordPress casse rarement une page à la fois. Il casse des templates. Diagnostiquez par type de page, pas par échantillonnage aléatoire.

Commencez par le réglage évident, toujours dévastateur : Réglages → Lecture → Demander aux moteurs de recherche de ne pas indexer ce site. Les sites de staging l’activent souvent. Un lancement précipité peut le faire passer en production. Idem pour des règles noindex de plugin copiées depuis le staging.

Puis contrôlez les canoniques. Une refonte de thème ou un import de plugin peuvent laisser des balises canoniques pointant vers l’ancien domaine, l’hôte temporaire ou la mauvaise langue. Inspectez le HTML rendu, pas seulement le champ du plugin. Le cache peut servir d’anciennes balises alors que l’admin paraît corrigé.

Ayez la même méfiance envers les sitemaps. Les plugins SEO WordPress les répartissent par type de contenu et taxonomie. Après migration, vous pouvez avoir des URL d’articles propres dans un sitemap et des URL de catégories sur l’ancien domaine dans un autre. Soumettez l’index du sitemap puis ouvrez manuellement chaque sous-sitemap.

Robots.txt est un autre tueur silencieux. Bloquer /wp-content/ peut empêcher Google de charger CSS, JavaScript ou images nécessaires à la compréhension de la page. Bloquer un chemin de template peut pénaliser tout un groupe. Bloquer tout le site arrive encore après un lancement depuis le staging — vu plus d’une fois.

Les permaliens sont pires car ils ressemblent à une décision éditoriale. Passer de /%postname%/ à /blog/%postname%/ sans redirections crée une migration d’URL dans la migration. Changer les bases de catégories, retirer les slashs finaux ou modifier les bases produits WooCommerce a le même effet.

Vérifiez aussi l’ordre des règles de redirection, les règles CDN, la sortie des plugins multilingues, les cibles hreflang, les URL de filtres WooCommerce, le comportement des pages pièce jointe, la pagination, le fil d’Ariane et les archives de types personnalisés. Un template défaillant peut étouffer des centaines d’URL.

Si cela ressemble à une checklist d’audit technique SEO, tant mieux. La reprise post-migration est un audit technique avec une date et une liste de suspects.

Récupérez les pages qui ont disparu de l’index Google

Choisissez une page précieuse qui a perdu du trafic. Pas vingt. Une.

Inspectez d’abord l’ancienne URL : renvoie-t-elle un 301 ? Y a-t-il une chaîne ? Atterrit-elle sur la bonne nouvelle URL ? La destination se charge-t-elle pour Googlebot ? Puis inspectez la nouvelle URL : code HTTP, canonique, directives robots, HTML rendu, liens internes, présence dans le sitemap, date de dernier crawl.

Utilisez l’Inspection d’URL de Search Console en mode « en direct », pas seulement la version indexée. La version indexée montre ce que Google a stocké. Le test en direct montre ce que Google peut récupérer maintenant.

Puis généralisez par template. Si un article migré a une mauvaise canonique, tous les articles migrés l’ont peut-être. Si une catégorie produit est en noindex, toutes le sont peut-être. Si une archive auteur redevient indexable, chaque archive auteur peut recréer du contenu thin.

La validation Search Console est lente (jours à semaines). Le meilleur signal précoce est le comportement de crawl. Consultez les logs serveur si vous les avez : les anciennes URL redirigées sont-elles toujours sollicitées ? Les requêtes Googlebot atteignent-elles les destinations finales ? Les 404 diminuent-elles pour les anciennes URL de valeur ?

Les classements reviennent généralement par groupe. Si les catégories produits réparées sont de nouveau crawlées et que les impressions reviennent, appliquez la même correction au reste des catégories. Ne changez pas d’autres éléments tant que la première correction est en cours de traitement.

Les citations IA ajoutent désormais un second problème de migration

Joost de Valk l’a formulé nettement :

« Il n’existe pas de formulaire de changement d’adresse pour un modèle entraîné un an avant votre déménagement. »

Google peut crawler les redirections. Search Console peut traiter un déménagement. Les LLM et moteurs de réponse IA peuvent encore stocker d’anciens noms d’hôte ou URL dans les données d’entraînement, les index de recherche, ceux de partenaires ou des couches de citations en cache. Un 301 propre aide Google mais ne réécrit pas chaque citation enregistrée ailleurs.

Pas de magie : maintenez les redirections. Laissez les anciennes URL pointer vers la meilleure nouvelle correspondance. Mettez à jour les profils à forte autorité, les pages source canoniques, le schéma d’organisation, les références sameAs, les sitemaps XML et les liens internes. Quand c’est possible, actualisez les citations sur les plateformes couramment ingérées par les systèmes d’IA.

Cela compte plus pour WordPress qu’on ne l’admet (je me suis trompé des années). Beaucoup de migrations reposent sur des plugins ou règles d’hébergeur nettoyés après trois mois. Si les citations IA pointent toujours vers les anciennes URL, ces redirections sont le pont. Supprimez le pont et la citation devient une impasse.

Pour le nettoyage annexe, lisez les guides SEOJuice sur les chaînes de redirection et 301, les bonnes pratiques de sitemap XML et les erreurs de balise canonique.

Un plan de réparation sur 14 jours pour le SEO après migration WordPress

On peut récupérer d’une migration chaotique sans tout réparer d’un coup. L’ordre compte plus que la pile d’outils.

Jour 0 à 1 : colmater l’hémorragie

• Vérifier la propriété de l’ancien domaine, de l’ancien hébergeur, du DNS, du CDN et des propriétés Search Console.
• Rétablir le contrôle des redirections avant de modifier le contenu.
• Désactiver les redirections fourre-tout vers la page d’accueil.
• Supprimer les balises noindex et blocages robots accidentels.
• Soumettre des index de sitemap propres pour le nouveau site.
• Tester manuellement un échantillon d’anciennes URL à forte valeur.

Si vous ne contrôlez plus l’ancien domaine, la reprise devient vite plus dure. Récupérez-le avant de discuter des balises title.

Jour 2 à 4 : reconstruire la cartographie

• Créer la table ancien → nouvel URL.
• Prioriser les URL avec backlinks, clics organiques, revenus, conversions et citations IA.
• Séparer par type : articles, pages, produits, catégories, tags, médias, archives, flux.
• Corriger les redirections par lots, en commençant par les groupes à plus forte valeur.
• Retester chaque lot après déploiement.

Ne faites pas confiance à « toutes les redirections ont été importées ». Crawler la liste.

Jour 5 à 7 : réparer les templates

• Auditer les canoniques par type de page.
• Vérifier directives robots et règles noindex.
• Revoir titres, headings, schéma, fil d’Ariane, liens internes.
• Contrôler pagination et templates d’archive.
• Confirmer les cibles hreflang multilingues si besoin.
• Tester catégories, produits et filtres WooCommerce.

C’est aussi là qu’un audit technique SEO WordPress prend tout son sens. Vous cherchez des échecs de template, pas des anomalies isolées.

Jour 8 à 14 : prouver la reprise

• Surveiller la couverture Search Console et les statistiques de crawl.
• Consulter les logs pour l’activité Googlebot sur les redirections héritées.
• Suivre les classements par groupe d’URL, pas seulement par mot-clé.
• Comparer les pages d’atterrissage analytics avant/après réparation.
• Tenir un journal de chaque modification de redirection, template et sitemap.

Si le trafic progresse sur les groupes d’URL réparés, appliquez la même correction au reste. Si rien ne change, cessez les modifications aléatoires et revérifiez la cartographie.

Ce qu’il ne faut pas faire après une mauvaise migration WordPress

N’installez pas trois nouveaux plugins SEO. Vous créerez des canoniques en double, des sitemaps dupliqués et des règles de redirection sans propriétaire.

Ne redirigez pas chaque 404 vers la page d’accueil. Google a clairement indiqué que ces redirections massives peuvent être traitées comme des soft 404.

Ne changez pas encore la structure des permaliens parce que la nouvelle « a l’air plus propre ». Des URL propres ne servent à rien si elles bougent sans cesse.

Ne réécrivez pas le contenu avant de réparer accès, redirections, canoniques et indexabilité. La qualité du contenu ne compense pas un chemin brisé.

Ne supprimez pas les anciennes redirections parce que « Google a sûrement compris ». Les consignes de Google recommandent de les garder au moins un an.

Ne prenez pas le classement de la page d’accueil pour preuve que la migration va bien. Le trafic marque peut masquer l’effondrement d’un template. Contrôlez les pages d’atterrissage qui apportaient du trafic non-brand.

Si les anciennes URL ne peuvent pas expliquer où elles sont parties, Google n’a aucune raison de deviner.

FAQ

Combien de temps dure la reprise SEO après une migration WordPress ?

De petites corrections peuvent produire des changements de crawl et d’impressions en quelques jours. Le retour des classements prend plus de temps : Google doit recrawler les anciennes URL, traiter les redirections, mettre à jour les canoniques et regagner confiance dans le nouvel ensemble d’URL. Pour les grands sites, pensez en semaines, pas en heures.

Dois-je soumettre à nouveau mon sitemap après une migration WordPress ?

Oui, mais seulement quand le sitemap est propre. Soumettre un sitemap rempli d’URL de l’ancien domaine, de URL en noindex ou de canoniques incohérents complique le diagnostic. Ouvrez manuellement l’index et les sous-sitemaps avant de soumettre.

Les redirections 301 suffisent-elles pour conserver les classements ?

Elles sont nécessaires mais pas suffisantes. La destination doit être pertinente, indexable, liée en interne, correctement canonique et présente dans des sitemaps propres. Un 301 vers une page faible ou hors sujet peut quand même perdre du trafic.

Et si j’ai changé la structure des permaliens WordPress ?

Traitez-le comme une migration d’URL. Élaborez une cartographie de chaque ancien permalien vers la nouvelle destination. Incluez bases de catégories, comportement de slash final, bases produits, pagination et anciens fallbacks ?p=123 si encore résolus.

Puis-je supprimer l’ancien hébergeur après la migration ?

Uniquement si les redirections sont gérées ailleurs et testées. Beaucoup de sites perdent du trafic parce que l’ancien hébergeur était le seul endroit où existaient les redirections. Avant de décommissionner, crawler les anciennes URL et confirmer qu’elles se résolvent toujours correctement.

Conclusion : le playbook de réparation aurait dû être la checklist de lancement

La reprise d’une migration WordPress n’a rien de glamour : de la compta d’URL, une discipline de redirections, des vérifications de templates et de la patience. La même checklist qui répare la chute aurait dû exister avant le lancement.

Chez seojuice.io, la règle est la même : la continuité ennuyeuse des URL l’emporte sur le nettoyage héroïque. Utilisez cet article deux fois : d’abord pour réparer la migration actuelle, puis avant que la prochaine ne parte en production.

Besoin d’aide pour trouver la casse ?

Si votre migration WordPress a fait chuter le trafic organique et que la cause reste floue, commencez par la cartographie des URL et l’audit des redirections. SEOJuice peut transformer la panique en file d’attente de correctifs, puis en checklist de lancement pour la prochaine migration.