Comment identifier les pages SEO en baisse de wordpress avec la Search Console ?

Niveau de lectureIntermédiaire

CMS / OutilWordPress, Google Search Console

Temps de lecture9 min

Une page qui décroche ne le crie jamais : elle perd quelques clics par-ci, quelques impressions par-là, jusqu’à ce que le total mensuel révèle un trou qu’on n’a pas vu venir. Search Console donne tous les signaux nécessaires pour repérer ce type de baisse avant qu’elle ne devienne un problème de fond, à condition de savoir où regarder. Et sur WordPress, une cause bien réelle échappe presque toujours au premier diagnostic. Ce guide complète notre guide complet de Google Search Console pour WordPress sur ce cas d’usage précis.

Sommaire

Repérer les pages en baisse dans le rapport Performances
Les causes classiques, par ordre de fréquence
La cause que les audits de contenu ratent presque toujours
Prioriser les corrections par impact
Quand agir, quand patienter
Questions fréquentes
Un diagnostic avant un plan d’action

Repérer les pages en baisse dans le rapport Performances

Menu Performances, activez la comparaison de périodes (28 derniers jours contre les 28 précédents pour une alerte rapide, 3 mois contre 3 mois pour une tendance plus stable, année sur année si votre activité est saisonnière). Passez ensuite sur l’onglet Pages et triez par la colonne de variation de clics : les lignes en rouge, en tête de tri, sont vos pages en décrochage.

Écartez d’emblée les pages à très faible volume avant de tirer une conclusion : une page qui passe de 3 à 1 clic affiche une baisse de 66 % qui ne veut rien dire statistiquement. Concentrez l’analyse sur les pages qui pesaient déjà un volume significatif. Pour l’interprétation détaillée de chaque métrique (clics, impressions, CTR, position), notre guide sur l’analyse des requêtes SEO WordPress entre dans le détail, on ne le reprend pas ici.

Une fois la page identifiée, cliquez dessus pour filtrer le tableau Requêtes sur elle seule : c’est là que se voit SI la baisse touche toutes ses requêtes uniformément (signe d’un problème global, technique ou d’autorité) ou seulement certaines (signe d’un décalage d’intention de recherche sur ces termes précis).

Les causes classiques, par ordre de fréquence

Avant de chercher l’exotique, éliminez le courant. Sur la majorité des pages WordPress en baisse, une de ces six causes explique le décrochage.

Cause	Comment la repérer
Contenu périmé	Dates, prix, exemples ou captures d’écran dépassés visibles à la relecture
Concurrence améliorée	Comparez le premier résultat actuel à votre page : structure, FAQ, profondeur
Changement d’intention	Le type de résultat dominant a changé (vidéo, comparatif, local, réponse directe)
Cannibalisation interne	Deux URL du site apparaissent sur la même requête dans le rapport filtré
Maillage interne affaibli	Souvent après une refonte de menu ou la suppression d’un widget de mise en avant
Saisonnalité	Comparez la courbe sur Google Trends, requête par requête, sur 5 ans si possible

Une mise à jour algorithmique de Google reste une cause possible, mais rarement la première à vérifier : elle se reconnaît à un décrochage groupé, sur plusieurs pages en même temps, aligné sur une date de mise à jour confirmée dans l’historique officiel des mises à jour de classement. Une chute isolée sur une seule page, elle, pointe presque toujours vers une des six causes du tableau ci-dessus.

Un dernier réflexe avant de creuser le contenu : vérifiez que la page n’est pas simplement repassée en attente d’exploration. Une baisse de clics accompagnée d’une chute tout aussi nette des impressions peut trahir un problème d’indexation plutôt qu’un problème de classement, notre guide sur le statut « explorée, non indexée » détaille ce cas de figure distinct.

La cause que les audits de contenu ratent presque toujours

Angle technique WordPressAvant de retravailler le contenu d’une page qui décroche, vérifiez qu’elle est encore réellement indexable. WordPress peut se retirer du jeu tout seul, en silence, par quatre voies distinctes.

C’est le point que ni les guides généralistes sur les baisses SEO, ni la documentation officielle de Google sur le sujet, ne relient à WordPress spécifiquement. Un noindex peut apparaître par quatre mécanismes indépendants, et une équipe qui ne vérifie que le premier passe à côté des trois autres :

1. Le réglage Lecture du back-office

La case « Décourager les moteurs de recherche d’indexer ce site » (Réglages puis Lecture) écrit la valeur blog_public = 0 dans la table des options WordPress. Cette valeur influence à la fois la balise meta robots générée et, selon le plugin SEO installé, l’en-tête HTTP correspondant.

2. La balise meta robots au niveau de la page

Un plugin SEO (Yoast, Rank Math) permet de passer une page ou un article en noindex individuellement, indépendamment du réglage global. Une case cochée par erreur sur une seule fiche produit ou un seul article suffit à le sortir de l’index sans toucher au reste du site.

3. L’en-tête HTTP X-Robots-Tag

Des extensions de maintenance, de mode « bientôt disponible » ou de sécurité peuvent poser un en-tête X-Robots-Tag: noindex au niveau serveur, invisible dans le code source affiché par le navigateur puisqu’il ne figure pas dans le <head> HTML. Seule une inspection des en-têtes de réponse le révèle.

4. Le scénario de migration qui fait tout basculer d’un coup

C’est le cas le plus coûteux : un environnement de préproduction (staging) a, par construction, ce réglage blog_public = 0 activé pour ne pas se faire indexer pendant les tests. Lors d’une migration vers la production avec un plugin de copie de base de données, ce réglage est importé tel quel avec le reste de la table d’options. Le site part en ligne, tout semble normal visuellement, mais chaque page nouvellement publiée ou republiée porte un noindex invisible, jusqu’à ce que quelqu’un pense à revérifier ce réglage précis.

Vérification rapide en une ligne, si vous avez accès à WP-CLI sur votre hébergement : wp option get blog_public. Une réponse à 0 confirme le problème, corrigé par wp option update blog_public 1. Sans accès CLI, l’inspection d’URL de Search Console (bouton Tester l’URL active) affiche directement si Google voit un noindex sur la page testée, quelle que soit la source des quatre citées plus haut. Une fois le noindex retiré, la page ne réapparaît pas instantanément : elle repasse par les statuts classiques du rapport d’indexation, ce que détaille notre guide d’interprétation du rapport d’indexation.

Ce mécanisme explique aussi pourquoi deux audits menés à quelques semaines d’écart peuvent donner des diagnostics contradictoires sur la même page : l’un capté pendant la fenêtre de noindex, l’autre après correction. Documentez systématiquement la date et l’heure de vos vérifications d’indexabilité, elles font partie du diagnostic autant que le résultat lui-même.

Deux causes du tableau méritent un mot de plus, parce qu’elles se confondent souvent l’une avec l’autre. Le changement d’intention de recherche n’est pas une baisse de qualité de votre page : Google a simplement constaté que les internautes qui tapent cette requête préfèrent désormais un format différent (une vidéo, un comparatif, une réponse directe en tête de résultats). Retravailler le texte sans changer le format ne suffit généralement pas. La cannibalisation, elle, est souvent une conséquence indirecte d’une bonne intention : deux articles publiés à des mois d’écart sur un sujet proche, sans qu’aucun des deux ne cite l’autre, finissent par se neutraliser mutuellement aux yeux de Google plutôt que de se renforcer.

Prioriser les corrections par impact

Corriger d’abord tout noindex accidentelC’est la seule cause de la liste qui, une fois corrigée, produit un effet direct dès la réexploration par Google, sans travail de contenu supplémentaire.
Rafraîchir le contenu sur les pages à fort volumePriorisez les pages qui pesaient un volume de clics significatif avant leur baisse : le potentiel de récupération y est le plus élevé.
Réparer le maillage interne affaibliSi la baisse suit une refonte de menu ou la suppression d’une mise en avant, réintégrez au moins un lien interne suivi depuis une page à forte autorité du site.
Clarifier une cannibalisationFusionnez les deux contenus concurrents, ou différenciez nettement leurs angles et retravaillez le maillage interne pour orienter clairement Google vers l’URL de référence.
Documenter les baisses saisonnièresNotez-les pour ne pas les retraiter inutilement l’an prochain à la même période, et concentrez l’effort sur les vraies anomalies.

Pour un audit qui croise systématiquement ces cinq points sur l’ensemble d’un site plutôt que page par page, un intégrateur WordPress SEO peut aller vérifier directement en base de données et au niveau serveur ce qu’un simple coup d’œil dans l’admin ne révèle pas.

Quand agir, quand patienter

Une variation sur deux ou trois jours ne veut jamais rien dire : le rapport Search Console est naturellement bruité au jour le jour. Attendez au minimum deux à trois semaines de recul avant de conclure à une tendance réelle, sauf en cas de chute brutale et immédiate qui accompagne un événement identifiable (migration, changement de thème, mise à jour de plugin majeure). Dans ce dernier cas, la vérification du noindex accidentel vue plus haut est le premier réflexe, avant toute autre hypothèse.

Questions fréquentes

Quelle période comparer pour être sûr qu’une baisse est réelle ?

28 jours contre les 28 précédents pour une alerte rapide, 3 mois contre 3 mois pour une tendance fiable, et une comparaison année sur année si l’activité est saisonnière. Ne concluez jamais sur deux ou trois jours d’observation.

Comment savoir si une baisse vient d’une mise à jour algorithmique Google ?

Elle touche généralement plusieurs pages en même temps, avec une date de décrochage qui coïncide avec une mise à jour confirmée dans l’historique officiel des mises à jour de classement de Google. Une baisse isolée sur une seule page pointe vers une cause propre à cette page.

Un noindex accidentel peut-il vraiment toucher tout un site WordPress d’un coup ?

Oui, via le réglage Lecture du back-office (blog_public à 0), souvent réactivé par erreur lors d’une migration depuis un environnement de préproduction. C’est la cause la plus radicale des quatre voies de noindex possibles sur WordPress, et la plus facile à corriger une fois identifiée.

Comment vérifier qu’une page n’est pas en noindex sans accès technique ?

Utilisez l’outil d’inspection d’URL de Search Console et cliquez sur Tester l’URL active : Google y indique directement si la page est indexable, quelle que soit la source du blocage (réglage global, balise par page, ou en-tête HTTP).

Faut-il retravailler le contenu avant de vérifier les causes techniques ?

Non, dans l’ordre inverse : un noindex non corrigé annule tout effort de contenu, puisque la page reste invisible pour Google quelle que soit sa qualité. Vérifiez toujours l’indexabilité en premier.

Un diagnostic avant un plan d’action

Retravailler le contenu d’une page qui décroche sans avoir vérifié son indexabilité technique revient à repeindre un mur qui prend l’eau. Sur WordPress, la vérification prend cinq minutes ; ignorer cette étape peut coûter des semaines de travail éditorial sur une page qui, techniquement, n’était plus dans la course.

À propos de l’auteur

Aymeric Maingé

Consultant SEO senior avec plus de 10 ans d’expérience, côté agence et annonceur. J’accompagne des sites WordPress, e-commerce et lead gen sur le diagnostic de performance organique, la correction technique et la priorisation des actions. Mon approche croise audit terrain, priorisation métier et recommandations actionnables pour les équipes marketing et IT. Votre prestataire SEO WordPress pour diagnostiquer une baisse de trafic et remettre vos pages stratégiques en ligne de mire.