Mon site WordPress perd ses positions Google : causes et solutions

Vous constatez une baisse et le premier réflexe, c’est de chercher ce que vous avez changé. Bonne nouvelle : la plupart du temps, la cause est technique et se corrige en quelques heures. Mais il existe un cas que la quasi-totalité des guides oublie, celui où vous n’avez RIEN touché : WordPress, lui, a continué de se mettre à jour tout seul.

D’abord, qu’est-ce qui a vraiment baissé

Avant de chercher une cause, encore faut-il savoir précisément ce qui a bougé, parce que « perdre ses positions », « perdre du trafic » et « disparaître de Google » sont trois situations différentes qui appellent des diagnostics différents. Confondre les trois fait perdre un temps précieux à corriger le mauvais problème.

Vérifier que le site est toujours indexé

Tapez site:votredomaine.fr dans la barre de recherche Google, sans espace après les deux-points. Si des résultats de votre site apparaissent encore, il n’est pas désindexé : c’est un problème de classement, pas de présence dans l’index. Complétez avec Search Console, dans le rapport Pages (Indexation) : comparez le nombre de pages indexées avant et après la date où vous avez remarqué le problème. Une chute brutale du nombre de pages indexées oriente vers une cause technique (noindex, robots.txt, sécurité) ; un nombre de pages indexées stable oriente vers un problème de classement pur.

Perte de position vs perte de trafic

Une requête peut perdre du volume de recherche (saisonnalité, actualité qui retombe, intérêt du public qui baisse) sans que votre page ait perdu la moindre position : le trafic baisse, le classement reste identique. À l’inverse, une page peut reculer de la position 3 à la position 8 sans que le trafic s’effondre, si la requête concernée génère peu de volume. Dans Search Console, comparez systématiquement la position moyenne ET les impressions avant de conclure : des impressions stables avec une position qui recule est un vrai signal de perte de classement, des impressions qui chutent avec une position stable pointe plutôt vers une baisse de la demande de recherche elle-même, hors de votre contrôle.

Les causes techniques les plus fréquentes

Ce sont les causes les plus courantes, et aussi les plus rapides à corriger une fois identifiées.

Balise noindex, robots.txt et redirections cassées

Vérifiez Réglages > Lecture dans wp-admin : la case « Décourager les moteurs de recherche d’indexer ce site » doit être décochée. Cette case, une fois cochée, ajoute une balise noindex sur l’ensemble du site et modifie le comportement du robots.txt virtuel de WordPress ; elle se retrouve cochée par accident après une restauration de sauvegarde, une synchronisation depuis un environnement de préproduction, ou une migration d’hébergeur qui a copié une table wp_options obsolète. Vérifiez ensuite votredomaine.fr/robots.txt à la recherche d’une ligne Disallow: / qui bloquerait l’exploration complète, et contrôlez vos redirections récentes (changement d’URL, passage HTTPS, refonte) à l’aide d’un crawler comme Screaming Frog pour repérer les chaînes de redirection ou les redirections vers des pages d’erreur.

Site inaccessible ou trop lent pour Googlebot

Une indisponibilité de quelques heures n’a généralement pas de conséquence durable, mais une indisponibilité prolongée (plusieurs jours) ou récurrente peut entraîner une désindexation progressive. Consultez le rapport Statistiques d’exploration de Search Console (Paramètres > Statistiques d’exploration) : un pic d’erreurs serveur (5xx) ou un temps de réponse moyen qui grimpe sur la période concernée indique que Googlebot lui-même a rencontré des difficultés à accéder au site, indépendamment de ce que voient vos visiteurs humains.

Les causes liées à Google : algorithme, pénalités, sécurité

Quand rien de technique ne ressort, la cause vient souvent d’une décision ou d’une réévaluation côté Google.

Mise à jour d’algorithme confirmée

Comparez la date de début de votre baisse à l’historique officiel des mises à jour publié par Google, et croisez avec des sites de veille spécialisés (comme Abondance en France) qui documentent chaque déploiement avec ses dates précises. Une baisse qui démarre pile sur la fenêtre de déploiement d’une mise à jour confirmée, sur plusieurs pages à la fois et sans action de votre part, pointe vers un reclassement algorithmique plutôt qu’un problème local à corriger dans l’urgence : `site:` continue de fonctionner normalement dans ce cas.

Action manuelle et problèmes de sécurité

Consultez Search Console, rubrique Sécurité et actions manuelles. Une action manuelle (liens artificiels, contenu généré en masse, techniques de dissimulation) s’accompagne toujours d’une notification explicite avec le motif exact ; dans l’immense majorité des cas, ce rapport est vide et cette piste peut être écartée rapidement. Vérifiez aussi Problèmes de sécurité : un site piraté qui sert du contenu de spam (contrefaçon, casino, pharmacie) à Googlebot tout en affichant un contenu normal aux visiteurs humains est une cause fréquente de désindexation brutale, et le symptôme n’est parfois visible que dans le code source ou les logs serveur, jamais à l’écran.

Attaque SEO négatif et backlinks toxiques

Un afflux soudain de liens entrants de très mauvaise qualité, visible dans le rapport de liens de Search Console ou un outil tiers (Ahrefs, Semrush), peut dans de rares cas déclencher une dévaluation automatique de type Penguin. Cette cause reste statistiquement rare pour un site de PME sans historique de netlinking agressif : ne vous précipitez pas sur un désaveu de liens en masse sans avoir d’abord écarté les causes plus probables listées plus haut, un désaveu mal ciblé peut faire plus de mal que de bien.

Le cas où personne n’a rien touché : les mises à jour automatiques invisibles

Voici ce qu’aucun des guides consultés ne traite, alors que c’est probablement la cause la plus frustrante à diagnostiquer : depuis WordPress 5.5, les mises à jour mineures du cœur s’installent automatiquement par défaut, et si l’auto-update est activé sur vos plugins et votre thème (souvent le cas par défaut chez les hébergeurs mutualisés, ou activé « pour la tranquillité »), votre site change de comportement sans que personne n’ait cliqué sur quoi que ce soit.

Pourquoi ces mises à jour échappent à votre historique de changements

Toutes les bonnes pratiques de prévention recommandent de tenir un historique des changements (qui, quand, quoi) pour pouvoir corréler une baisse à une action précise. Le problème : une mise à jour automatique de plugin n’apparaît dans AUCUN historique de ce type, parce qu’elle n’est pas déclenchée par un humain mais par le cron interne de WordPress (la fonction wp_maybe_auto_update), généralement exécuté la nuit, silencieusement, sans qu’aucune notification ne s’affiche dans wp-admin sauf si vous avez explicitement activé les emails de rapport de mise à jour. Un plugin SEO qui change sa façon de générer le sitemap, un plugin de cache qui modifie ses en-têtes HTTP, une extension WooCommerce qui altère son balisage de schéma produit, ou simplement un conflit introduit entre deux extensions après leur mise à jour respective : tout cela peut faire bouger le classement sans qu’aucune trace volontaire n’existe dans votre journal de bord.

Comment retrouver ce qui a changé malgré tout

La trace existe, mais ailleurs que dans votre mémoire. Dans wp-admin, Outils > Santé du site > Informations liste la version actuelle de chaque plugin actif : si votre hébergeur conserve des sauvegardes automatiques quotidiennes, restaurez (dans un environnement de test, jamais en production) une copie datant d’avant la baisse et comparez les numéros de version des extensions à ceux d’aujourd’hui. Les hébergeurs WordPress infogérés (WP Engine, Kinsta, SiteGround et équivalents) conservent souvent un journal d’auto-updates consultable dans leur panneau de contrôle, distinct de l’historique éditorial de WordPress. Une fois une extension suspecte identifiée, son changelog officiel sur le répertoire WordPress.org indique la date exacte de chaque version publiée : si cette date coïncide avec le début de votre baisse, vous tenez votre piste, en particulier pour les mises à jour majeures (changement du premier chiffre de version) qui modifient plus souvent le comportement que les correctifs mineurs.

La méthode de diagnostic, étape par étape

Comment comparer proprement avant/après

La méthode officielle recommandée par Google pour ce diagnostic mérite d’être suivie à la lettre plutôt qu’improvisée. Dans le rapport de performance Search Console, étendez la période à 16 mois (le maximum disponible) pour visualiser la tendance longue avant de zoomer sur l’incident. Utilisez ensuite l’onglet de comparaison pour confronter les trois derniers mois à la même période de l’année précédente : cette comparaison en glissement annuel neutralise la saisonnalité propre à votre activité, qu’un simple avant/après sur quelques semaines ne peut pas distinguer d’un vrai problème. Complétez avec Google Trends sur vos requêtes principales : une baisse qui se reproduit chaque année à la même période, visible sur plusieurs années d’historique Trends, n’a probablement rien à voir avec votre site.

Filtrez également par type de recherche (Web, Images, Actualités) séparément : une baisse qui ne touche que le trafic Image, par exemple, oriente vers une cause complètement différente (compression d’images, changement de format) qu’une baisse sur le Web générique. Dans la table des pages, triez par différence de clics pour identifier si la baisse est concentrée sur une poignée de pages stratégiques ou diffuse sur l’ensemble du site : une baisse concentrée sur 3 ou 4 pages oriente vers un problème local à ces pages, une baisse diffuse et homogène oriente vers une cause site-wide (algorithme, sécurité, technique globale).

Combien de temps pour récupérer ses positions

Le délai dépend directement de la cause identifiée, et les guides généralistes ont tendance à donner une seule fourchette pour toutes les situations, ce qui n’a pas de sens. Une balise noindex ou un robots.txt corrigé peut se refléter en quelques jours une fois qu’une nouvelle exploration a eu lieu (accélérable via l’outil d’inspection d’URL). Un piratage nettoyé, suivi d’une demande de réexamen, prend généralement une à plusieurs semaines : Google indique traiter les demandes sous quelques jours ouvrés, mais le retour effectif aux positions antérieures suit son propre calendrier, indépendant du traitement de la demande elle-même. Une migration de site, même bien exécutée, peut prendre plusieurs semaines avant que Google en prenne pleinement la mesure sur un site de taille moyenne. Un recul lié à une mise à jour d’algorithme ne se « corrige » pas au sens strict : il faut adapter le site à ce que la mise à jour valorise, puis attendre le prochain cycle de recrawl et de réévaluation, ce qui peut s’étaler sur plusieurs semaines à plusieurs mois selon l’ampleur des changements apportés.

Comment éviter que ça se reproduise

Si le diagnostic reste incertain malgré cette méthode, un audit technique WordPress permet de dérouler l’ensemble de ces vérifications en une seule passe structurée, y compris le contrôle des versions d’extensions et de leur impact réel sur le référencement.

Ce qu’il faut retenir

Une perte de positions sur WordPress a presque toujours une cause identifiable en suivant la méthode dans l’ordre : confirmer ce qui a vraiment bougé, écarter les causes techniques évidentes, vérifier le tableau de bord Google, puis, si rien ne ressort, se souvenir que WordPress continue de se mettre à jour tout seul même quand vous, vous n’avez rien touché. C’est souvent la piste la plus longue à envisager, et la seule que la plupart des guides oublient complètement.