Perte de positions après une mise à jour WordPress : que faire ?

Une mise à jour WordPress qui casse le SEO n’est pas toujours une affaire de plugin incompatible ou de conflit de code. Avant de chercher du côté technique, il existe un test de trente secondes que la plupart des guides ignorent complètement : vérifier si la mise à jour n’a pas silencieusement réactivé une case que personne n’a jamais cochée volontairement. Voici comment diagnostiquer, corriger et éviter que ça recommence.

Le réflexe des 30 secondes avant toute investigation

Avant de rouvrir un ticket de support, de comparer des changelogs ou de suspecter une pénalité Google, allez dans Réglages puis Lecture de votre tableau de bord WordPress. Une seule case vous intéresse : « Décourager les moteurs de recherche d’indexer ce site ». Si elle est cochée alors que vous ne l’avez jamais activée, vous venez de trouver la cause en moins d’une minute.

Cette option correspond à un simple champ en base de données, blog_public, que WordPress consulte pour décider d’injecter ou non une balise noindex sur l’ensemble du site. Sur le forum officiel support.wordpress.org, plusieurs utilisateurs rapportent le même phénomène déroutant : la case revient cochée toute seule, sans qu’ils l’aient touchée. L’un d’eux décrit une réapparition « environ une fois toutes les deux semaines », un autre confirme qu’« une fois décochée, elle se recoche automatiquement ». Les modérateurs pointent systématiquement du doigt les plugins et thèmes actifs, un plugin SEO étant explicitement cité comme suspect potentiel dans un des fils. Aucune cause unique n’a été confirmée publiquement à ce jour, et le sujet reste non résolu sur le forum, ce qui n’enlève rien à l’intérêt du test : il coûte trente secondes et élimine d’emblée la piste la plus radicale, celle qui explique une désindexation totale plutôt qu’une perte de positions partielle.

Ce test n’est volontairement mentionné dans aucun des guides généralistes sur le sujet : ils partent tous du principe que la case a été décochée une fois pour toutes et n’y revient jamais. Or c’est précisément le genre de réglage qu’une mise à jour de plugin peut réinitialiser à sa valeur par défaut sans prévenir, surtout si le plugin gère lui-même l’indexation (SEO, cache, sécurité, multilingue). Si la case est décochée, passez au diagnostic complet ci-dessous : la cause est ailleurs.

Isoler ce qui a vraiment changé

Core, plugin ou thème : la distinction qui change tout

« Une mise à jour WordPress » recouvre trois réalités très différentes, et elles n’appellent pas le même diagnostic. Une mise à jour du cœur WordPress touche rarement le SEO directement, sauf changement majeur de version (PHP requis, structure de permaliens). Une mise à jour de plugin est la cause la plus fréquente : un plugin SEO qui change sa gestion des balises canonicals, un plugin de cache qui se met à servir une version obsolète, un plugin de sécurité qui bloque soudainement les robots légitimes. Une mise à jour de thème est la plus sournoise, parce qu’elle touche simultanément la structure HTML, les balises de titre, le maillage interne et parfois des données structurées invisibles à l’œil nu.

Dater précisément la mise à jour côté serveur

Si les mises à jour automatiques sont activées (comportement par défaut pour les mises à jour mineures depuis WordPress 5.5, et optionnel pour les plugins/thèmes), elles s’exécutent la nuit via le cron interne wp_maybe_auto_update, sans laisser de trace dans un historique visible. Deux sources fiables permettent de dater l’événement après coup : les e-mails de rapport d’auto-update que WordPress envoie par défaut à l’administrateur (à chercher dans les archives, pas seulement la boîte de réception récente), et l’horodatage des fichiers du plugin ou du thème concerné sur le serveur, consultable via le gestionnaire de fichiers de l’hébergeur ou en SSH avec ls -la --time-style=full-iso dans le dossier wp-content/plugins/<nom> ou wp-content/themes/<nom>. Comparez cette date à celle du début de la chute observée dans Search Console : un écart de quelques heures à un jour confirme le lien de cause à effet, un écart de plusieurs jours doit faire chercher ailleurs.

Les causes qui reviennent le plus souvent

Passé le test de la case d’indexation, quatre familles de causes concentrent la grande majorité des cas observés après une mise à jour WordPress.

Un point souvent négligé : ces causes ne s’excluent pas mutuellement. Une mise à jour de thème mal maîtrisée peut casser à la fois la structure HTML et les temps de chargement, ce qui brouille le diagnostic si vous cherchez une cause unique.

Le protocole de diagnostic, dans l’ordre

1. Vérifiez l’indexabilité globaleCase « décourager les moteurs de recherche », puis balise noindex page par page dans l’inspection d’URL de Search Console.
2. Localisez la chute dans Search ConsoleRapport Performances, comparez les 90 derniers jours : la chute concerne-t-elle tout le site ou un template précis (fiches produit, articles, pages) ?
3. Comparez le code source avant/aprèsUtilisez web.archive.org sur une page représentative pour repérer une balise title, une canonical ou un Hn qui a changé de valeur.
4. Consultez le journal d’erreurs PHPUne erreur silencieuse (avertissement, notice) peut empêcher un plugin SEO de s’exécuter correctement sans faire planter la page.
5. Testez le rendu mobile et la vitessePageSpeed Insights ou l’outil de test mobile-friendly, en comparant si possible à une mesure antérieure à la mise à jour.

Corriger sans aggraver : rollback ou correctif ciblé

Quand revenir en arrière est la bonne décision

Si la cause identifiée est un plugin ou un thème précis et que la version précédente est disponible (WordPress conserve un historique de versions pour les extensions du répertoire officiel), un retour en arrière ciblé sur ce seul composant est souvent la solution la plus rapide et la plus sûre. Elle évite de courir après un correctif pendant que le site continue de perdre en visibilité.

Quand corriger en avançant est préférable

Si la mise à jour corrigeait par ailleurs une faille de sécurité ou un bug important, revenir en arrière n’est pas neutre. Dans ce cas, un correctif ciblé (réactiver manuellement le bon réglage, ajouter une redirection, restaurer une balise via un snippet de fonctions) permet de garder les bénéfices de la mise à jour sans subir sa régression SEO. Faites toujours ce test sur un environnement de préproduction avant de le pousser en production : c’est la seule façon de vérifier qu’un correctif ne déplace pas le problème ailleurs.

Combien de temps pour récupérer ses positions

Dans la pratique, une correction de balise noindex ou de canonical se répercute généralement plus vite (quelques jours à deux semaines) qu’une correction de performance ou de structure HTML, dont l’effet se mesure plutôt sur trois à six semaines. Pour vérifier que la correction a bien été prise en compte, ne vous fiez pas uniquement au trafic : utilisez l’inspection d’URL de Search Console sur quelques pages représentatives et demandez une nouvelle exploration une fois le correctif en ligne, plutôt que d’attendre passivement le prochain passage naturel de Googlebot.

Éviter que ça se reproduise

1. Testez sur un environnement de préproductionToute mise à jour de thème ou de plugin majeur mérite un passage en staging avant la production, en particulier pour les extensions qui touchent au SEO, au cache ou à la sécurité.
2. Échelonnez les mises à jour automatiquesDésactivez l’auto-update sur les plugins critiques (SEO, cache, sécurité) et gardez-le pour les extensions à faible impact, pour garder une trace claire de ce qui a changé.
3. Exportez régulièrement la configuration SEOLa plupart des plugins SEO proposent un export de réglages : conservez-en un après chaque changement important, il sert de point de comparaison en cas d’anomalie.
4. Surveillez la case d’indexabilitéAjoutez un contrôle mensuel simple de la case « décourager les moteurs de recherche », surtout après une mise à jour d’un plugin qui touche à l’indexation.