Perte de positions après une migration WordPress : comment réagir ?

Vous avez migré votre site WordPress, les redirections sont en place, le robots.txt est propre, et pourtant les positions descendent. Avant de réécrire du contenu ou d’incriminer l’algorithme, il y a un contrôle que presque aucun guide de migration ne mentionne : vérifier si l’URL technique de votre hébergeur, ou votre sous-domaine de préproduction, s’est retrouvé indexé pendant la bascule. C’est souvent la cause, et elle est invisible dans les rapports de redirection.

Migration propre et positions en baisse : la contradiction apparente

Une migration WordPress recouvre trois opérations très différentes du point de vue du référencement. Le simple changement d’hébergeur garde les URL identiques : le risque SEO est théoriquement nul, sauf accident de configuration. Le changement de domaine impose une redirection de chaque ancienne URL vers sa jumelle sur le nouveau nom. La refonte avec restructuration de l’arborescence combine les deux et ajoute des URL qui changent de forme, parfois par centaines.

Sur ce dernier scénario, le plus risqué, faire cadrer la reprise des URL et le plan de redirection par un spécialiste des migrations WordPress en amont évite l’essentiel des pertes. Quand le mal est fait, la démarche reste la même.

Dans les trois cas, une baisse de positions pendant deux à quatre semaines après la bascule reste dans la norme. Google le formule ainsi dans sa documentation sur les changements d’adresse : « quelques semaines peuvent être nécessaires à la migration de la majorité des pages d’un site de petite à moyenne taille », avec une fluctuation temporaire du classement. Ce qui n’est pas normal, c’est une chute qui s’installe, qui s’aggrave après la troisième semaine, ou qui touche des pages dont l’URL n’a pas bougé d’un caractère.

Quand la migration a été menée proprement et que la baisse persiste, la tentation est de sauter directement sur le contenu ou sur l’autorité du domaine. C’est prendre le problème par la fin. Dans la majorité des cas que j’ai vus, la cause est un défaut technique précis, pas une réévaluation qualitative de Google. Et le défaut le plus fréquent n’est pas dans les redirections.

Le contrôle que les guides zappent : l’URL technique a-t-elle été indexée ?

Soyons précis : pendant une migration, votre site existe simultanément à deux endroits. L’ancien, sur son domaine. Et le nouveau, qui répond déjà sur une adresse technique avant que le DNS ne pointe vers lui. Cette adresse technique est le point aveugle.

Comment le duplicata se crée pendant la bascule

La plupart des hébergeurs mutualisés attribuent à chaque compte une URL provisoire du type premium123.votre-hebergeur.com, clientXYZ.o2switch.net ou une adresse IP directe. Certains constructeurs de migration créent aussi un sous-domaine staging. ou preprod. pour la recette. Sur ces adresses, votre site répond en HTTP 200, avec l’intégralité du contenu, souvent sans noindex et sans blocage robots.txt, parce que personne n’a pensé à les protéger. Si un lien traine quelque part, si Googlebot a déjà vu cette adresse lors d’une précédente recette, ou si l’hébergeur l’expose publiquement, elle finit dans l’index. Vous obtenez alors un duplicata intégral de votre site, sur une adresse qui ne redirige nulle part.

Le résultat est un double préjudice. Google répartit ses signaux entre deux copies au lieu d’une, et le budget d’exploration se dilue sur des pages qui n’ont aucune raison d’exister. Sur un site à forte concurrence, cela suffit à faire reculer les pages stratégiques de plusieurs positions, sans qu’aucun rapport de redirection ne signale quoi que ce soit : les redirections, elles, sont parfaites.

Le détecter en cinq minutes

Trois vérifications suffisent. D’abord, tapez dans Google site:premium123.votre-hebergeur.com en remplaçant par l’adresse technique réelle de votre compte, visible dans le panneau de votre hébergeur. Testez aussi le sous-domaine de préproduction s’il en existe un. Ensuite, ouvrez la liste des propriétés de votre compte Search Console : une propriété fantome pour un sous-domaine ou une adresse oubliée y apparaît parfois, avec des impressions. Enfin, inspectez une de vos pages importantes dans Search Console et regardez l’URL canonique sélectionnée par Google : si elle pointe vers l’adresse technique plutôt que vers votre domaine, le duplicata a pris le dessus.

Le corriger

La correction dépend de ce que vous trouvez. Si l’adresse technique n’est plus utile, le plus propre est de la faire répondre en HTTP 410 ou de rediriger l’ensemble en 301 vers le domaine définitif, au niveau du serveur. Si vous en avez encore besoin pour la recette, protégez-la par mot de passe (authentification HTTP, code 401) : Googlebot ne franchit pas cette barrière, et les pages déjà indexées sortent de l’index en quelques semaines. Évitez le simple noindex laissé seul sur une adresse encore accessible : il fonctionne, mais plus lentement, et il laisse la porte ouverte à une réindexation si la balise saute lors d’une mise à jour. Une fois l’adresse assainie, demandez la réindexation de vos pages canoniques via l’inspection d’URL.

Le contrôle des redirections, fait correctement

Une fois l’adresse technique écartée, revenez aux redirections, mais avec les bons tests. « Les redirections sont en place » ne veut pas dire « les redirections sont correctes ».

Repérer les 302 involontaires et les chaînes

Google demande des redirections permanentes : « utilisez des redirections HTTP permanentes si possible, telles que 301 et 308 ». Or beaucoup de configurations WordPress produisent des 302 sans le vouloir : une extension de redirection mal réglée, un module de l’hébergeur, ou une règle HTTPS qui s’empile sur une règle de domaine. Une 302 est comprise comme temporaire : elle ne transfère pas l’autorité de la page. Passez vos URL principales dans un testeur d’en-têtes HTTP et vérifiez que chaque saut renvoie bien un code 301, en une seule étape. Google tolère jusqu’à dix sauts dans une chaîne mais recommande d’en rester sous cinq : une ancienne URL qui passe par HTTP, puis par www, puis par la nouvelle structure, c’est déjà trois sauts pour rien.

L’ancien site doit disparaître, pas rester en 200

Après un changement de domaine, l’ancien nom doit servir uniquement des redirections. S’il continue de répondre en 200 avec le contenu complet, parce que l’installation WordPress d’origine tourne encore, vous avez recréé le problème du duplicata, cette fois sur un domaine que Google connaît déjà bien. Vérifiez qu’une poignée d’anciennes URL, y compris la page d’accueil, renvoient un 301 vers la cible exacte et non vers la racine du nouveau domaine. Google conseille de conserver ces redirections « aussi longtemps que possible, généralement au moins un an ». Sur une refonte qui a aussi changé de thème, ce nettoyage se combine avec les points détaillés dans notre article sur la perte de trafic après un changement de thème.

Search Console : les rapports à ouvrir dans l’ordre

Search Console est l’outil qui tranche entre « fluctuation normale » et « problème installé ». Quatre rapports, dans cet ordre.

L’outil de changement d’adresse. Après un changement de domaine, envoyez la demande depuis la propriété de l’ancien site. Elle indique à Google que la migration est volontaire et accélère le transfert. Elle ne s’applique pas à un simple passage en HTTPS.

Le rapport d’indexation des pages. Surveillez la courbe des pages indexées sur les deux propriétés : l’ancienne doit décroître pendant que la nouvelle monte. Une nouvelle propriété qui stagne à zéro, ou une explosion de pages « détectée, actuellement non indexée », signale un blocage.

Les sitemaps. Soumettez le sitemap du nouveau site, et gardez temporairement l’ancien : il aide Google à découvrir les redirections. Supprimez l’ancien une fois la migration digérée. Vérifiez que le sitemap généré par Yoast ou Rank Math pointe bien vers les URL du nouveau domaine et non vers un cache de l’ancien.

Les statistiques d’exploration. Un pic d’erreurs serveur ou de 404 après la bascule vous dit où regarder. Google explore davantage juste après une migration : si l’hébergement ne suit pas, l’exploration ralentit et le transfert avec elle. Pour un diagnostic plus large de la chute, notre guide sur la méthode de diagnostic d’une chute brutale de trafic reprend la démarche pas à pas.

Combien de temps c’est normal, et quand ça ne l’est plus

Il faut distinguer deux horloges. La réévaluation de l’accessibilité, c’est-à-dire le fait que Google constate les redirections et commence à suivre les nouvelles URL, prend de 24 à 48 heures pour les pages les plus visitées. La reconstitution du classement, elle, demande plusieurs cycles d’exploration et d’évaluation : compter deux à quatre semaines pour un site de petite taille, davantage pour un gros catalogue.

Passez ces délais au crible de trois questions. La baisse touche-t-elle uniquement des URL qui ont changé de forme, ou aussi des pages inchangées ? Dans le second cas, cherchez une cause globale : robots.txt, duplicata, performance serveur. La baisse se stabilise-t-elle ou s’aggrave-t-elle semaine après semaine ? Une aggravation après la troisième semaine n’est plus une fluctuation. Les pages perdues sont-elles crawlées ? Si l’inspection d’URL montre un dernier passage de Googlebot antérieur à la migration, le problème est un blocage d’exploration, pas un déclassement.

Votre plan de contrôle post-migration en 7 points

1. Chercher le duplicata sur l’adresse techniqueRequête site: sur l’URL provisoire de l’hébergeur et sur tout sous-domaine de préproduction, plus la liste des propriétés Search Console.
2. Assainir cette adresseMot de passe (401), redirection 301 vers le domaine ou réponse 410 selon qu’elle sert encore ou non.
3. Tester les codes de redirectionChaque URL principale renvoie un 301 unique, jamais une 302, jamais une chaîne de plus de deux sauts.
4. Confirmer que l’ancien site ne répond plus en 200Page d’accueil et pages clés de l’ancien domaine redirigées vers leur cible exacte, pas vers la racine.
5. Envoyer la demande de changement d’adresseDepuis la propriété de l’ancien domaine, si le nom a changé.
6. Soumettre le nouveau sitemapVérifier qu’il liste les bonnes URL, garder l’ancien quelques semaines, puis le retirer.
7. Suivre indexation et exploration pendant un moisCourbe des pages indexées sur les deux propriétés, pics d’erreurs serveur, date de dernier crawl des pages perdues.

Réagir sans surréagir

Une perte de positions après une migration WordPress se traite dans l’ordre : d’abord les causes techniques silencieuses, l’adresse technique indexée en tête de liste, ensuite les redirections, ensuite les délais. Le contenu ne vient qu’après, une fois que vous avez la certitude que Google voit une seule version propre de votre site. La plupart des récupérations que j’ai menées après une migration n’ont demandé aucune réécriture : juste un duplicata à faire disparaître et deux ou trois redirections à corriger. Si la baisse résiste à ces contrôles au-delà d’un mois, un audit technique ciblé s’impose avant d’engager quoi que ce soit sur le fond.