Quand un site WordPress n'apparaît pas sur Google, la réponse classique tient en trois gestes : régénérer le sitemap, installer un plugin SEO, demander l'indexation. Parfois cela suffit. Quand cela ne suffit pas, on recommence les mêmes gestes, faute de savoir où chercher. Le piège est là : multiplier les actions alors que la Google Search Console a déjà rendu son verdict. Son rapport « Indexation des pages » attribue un motif précis à chaque URL écartée, et sur WordPress, ces motifs renvoient presque toujours à une poignée de réglages identifiables : une case cochée dans Réglages > Lecture qui laisse tout le site en « Exclue par la balise noindex », un interrupteur de plugin qui décide du sort de familles entières de pages, des archives générées en série que Google explore puis écarte. Quel réglage produit quel statut ? Lesquels sont normaux, lesquels signalent une erreur ? Et comment vérifier, au-delà de quelques URLs inspectées à la main, ce que Google a décidé pour tout le site ?
Pourquoi vos pages WordPress n'apparaissent pas sur Google
Une page WordPress absente de Google est soit inconnue de Google, soit connue mais écartée de l'index. Le rapport « Indexation des pages » de la Search Console distingue les deux cas et affiche le motif exact : balise noindex, blocage robots.txt, page jugée sans intérêt propre, doublon. Ce motif est le point de départ du diagnostic.
Cette lecture change l'ordre des opérations. Les guides d'indexation WordPress déroulent presque tous la même liste : créer un compte Search Console, soumettre le sitemap, vérifier le robots.txt, installer Yoast ou Rank Math. Ces étapes sont utiles, mais elles décrivent un site en bonne santé qui attend son tour. Elles ne disent rien du site dont les pages sont déjà connues de Google et pourtant écartées, motif à l'appui. Or ce motif désigne directement le réglage à examiner : inutile de refaire le sitemap quand le rapport indique une balise noindex.
WordPress ajoute une particularité que les conseils génériques ignorent : la plateforme crée des pages en série sans que vous les rédigiez jamais. Chaque étiquette posée sur un article engendre une page d'archive, chaque auteur a la sienne, chaque mois de publication aussi, et chaque média peut avoir sa page de pièce jointe. Google explore tout cela, rend un verdict par URL, et sa documentation prévient d'ailleurs qu'il ne faut pas s'attendre à une indexation intégrale : « Don't expect every URL on your site to be indexed ». La question n'est donc pas d'obtenir 100 % de pages indexées, mais de vérifier que la frontière entre l'indexé et le non-indexé passe exactement là où vous l'avez décidé.
Explorer vs indexer : ce que le rapport « Indexation des pages » affiche
Google traite chaque URL en deux temps. L'exploration d'abord : Googlebot télécharge la page et lit son contenu. L'indexation ensuite : Google décide si cette page mérite une entrée dans son index. Une page peut être explorée sans être indexée, et chaque étape a ses statuts dans le rapport « Indexation des pages » (rubrique Indexation > Pages de la Search Console).
Sur un site WordPress, quelques statuts reviennent plus souvent que les autres. « Détectée, actuellement non indexée » : Google connaît l'URL mais ne l'a pas encore explorée. « Explorée, actuellement non indexée » : Google a lu la page et ne l'a pas retenue. « Exclue par la balise noindex » : la page porte une instruction explicite de non-indexation, et Google l'a respectée. S'y ajoutent les blocages robots.txt et les statuts de doublons, quand plusieurs URLs servent le même contenu. D'autres motifs existent ; ceux-là forment l'essentiel du paysage sur la plupart des sites WordPress.
Pour une URL donnée, l'outil d'inspection d'URL de la Search Console fournit le détail complet : le statut, la canonique que Google a retenue et la date du dernier passage de Googlebot. C'est l'outil de référence du diagnostic, avec une limite connue : il traite une URL à la fois.
Chaque piège WordPress a son statut : la grille de lecture
Les réglages et les automatismes de WordPress laissent chacun une empreinte reconnaissable dans le rapport d'indexation. Voici les correspondances les plus fréquentes ; une même famille de pages peut recevoir d'autres statuts selon la configuration.
| Piège WordPress | Statut le plus fréquent | Lecture |
|---|---|---|
| Case « Demander aux moteurs de recherche de ne pas indexer ce site » restée cochée | « Exclue par la balise noindex » sur tout le site | Erreur presque certaine |
| noindex de plugin SEO sur les étiquettes ou archives | « Exclue par la balise noindex » sur ces familles | Normal si c'est voulu |
| Étiquettes et archives laissées indexables mais pauvres | « Explorée, actuellement non indexée », doublons | Arbitrage à rendre |
| Pages de pièces jointes | « Soft 404 », doublons | Héritage à rediriger |
Pagination des archives (/page/2/) |
« Explorée, actuellement non indexée » | Normal le plus souvent |
| Site récent ou volumineux | « Détectée, actuellement non indexée » | Attente de crawl |
| Plugin de sécurité, staging, règles héritées | « Bloquée par le fichier robots.txt » | À vérifier |
La case « Demander aux moteurs de recherche de ne pas indexer ce site »
Elle se trouve dans Réglages > Lecture, section « Visibilité par les moteurs de recherche ». Depuis WordPress 5.3, cocher cette case insère une balise <meta name="robots" content="noindex,nofollow"> sur toutes les pages du site (les versions antérieures passaient par une règle Disallow: / dans le robots.txt virtuel). Côté Search Console, le résultat est sans ambiguïté : les pages basculent en « Exclue par la balise noindex », URL après URL, au rythme des passages de Googlebot.
Le scénario type est connu de tous les praticiens : la case a été cochée à juste titre pendant le développement ou une refonte, puis la mise en production s'est faite sans la décocher. Le site fonctionne, les visiteurs directs ne remarquent rien, et l'index se vide en silence pendant des semaines. La documentation WordPress précise par ailleurs que cette case est une demande adressée aux moteurs, pas un blocage d'accès (« it is up to search engines to honor your request ») : les pages restent accessibles, elles sont simplement retirées des résultats au fil des recrawls. C'est ce qui rend le problème si discret.
Étiquettes, catégories et archives : les pages que WordPress crée pour vous
Un article publié avec cinq étiquettes crée cinq pages d'archive, dont certaines ne listeront jamais qu'une entrée. Les archives d'auteur et de date suivent la même mécanique. Ces pages ne sont pas des défauts : ce sont des fonctionnalités de navigation. Mais chacune est une URL que Google découvre et juge.
Deux cas de figure dominent. Si le plugin SEO les met en noindex, elles se rangent en bloc dans « Exclue par la balise noindex » : un choix courant et parfaitement sain, tant qu'il est volontaire. Si elles restent indexables, Google tranche lui-même : les archives pauvres finissent en « Explorée, actuellement non indexée », et celles qui répètent les mêmes extraits peuvent glisser vers les statuts de doublons, comme « Page en double sans URL canonique ». Sur un blog audité en masse, ces familles générées concentrent la quasi-totalité de ces deux statuts ; les articles eux-mêmes n'en portent presque jamais.
L'arbitrage mérite d'être rendu famille par famille. Une page de catégorie travaillée, avec un texte d'introduction et une vraie demande de recherche, a sa place dans l'index. Une étiquette posée une fois n'y apportera rien. L'objectif n'est pas de tout indexer ni de tout exclure, mais de décider, puis de vérifier que le rapport reflète cette décision.
Pièces jointes et pagination : l'héritage des réglages par défaut
Historiquement, WordPress créait une page dédiée pour chaque média téléversé : la page de pièce jointe, une URL quasi vide autour d'une image. Google les traite comme ce qu'elles sont : des coquilles vides. Verdict habituel : « Soft 404 » ou statut de doublon. WordPress 6.4 a désactivé ces pages sur les nouvelles installations, et Yoast comme Rank Math savent rediriger l'URL de pièce jointe vers le fichier lui-même. Sur un site ancien, des centaines de ces pages peuvent pourtant encore encombrer le rapport.
La pagination des archives (/page/2/, /page/3/) relève d'une autre logique : ces pages servent de sommaire intermédiaire, et leur statut le plus fréquent, « Explorée, actuellement non indexée », est le plus souvent normal. La grille complète des verdicts de pagination, statuts d'alarme compris, fait l'objet d'un article dédié.
Site récent ou volumineux : l'attente de crawl
« Détectée, actuellement non indexée » signifie que Google connaît l'URL sans l'avoir encore explorée. Sur un site lancé il y a deux semaines, ce statut est la norme, pas une anomalie : la documentation Google annonce elle-même un délai d'une semaine ou plus avant les premiers crawls d'un nouveau site (« It can take a week or so for Google to start crawling and indexing a new page or site »), et le remplissage de l'index s'étale bien au-delà.
Le même statut change de sens sur un site établi et volumineux. Quand des articles récents s'accumulent en « Détectée » pendant des semaines, Googlebot dépense probablement son budget de crawl ailleurs, souvent sur les familles générées : étiquettes, archives, variantes d'URL créées par le thème. Le diagnostic passe alors par la question du maillage et du volume d'URLs que le site expose au crawl.
Robots.txt : plugins de sécurité, staging et blocages hérités
« Bloquée par le fichier robots.txt » sur des pages qui devraient être indexées a presque toujours une cause mécanique : un plugin de sécurité ou de maintenance qui a réécrit le fichier, un robots.txt de staging (Disallow: /) recopié en production, ou une règle historique jamais réévaluée.
Le piège est plus retors qu'il n'y paraît, car le robots.txt bloque l'exploration, pas l'indexation. La documentation Google est explicite : pour qu'une balise noindex agisse, la page ne doit pas être bloquée par le robots.txt (« For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file »), sinon Googlebot ne verra jamais l'instruction, et l'URL peut rester dans les résultats. Bloquer par robots.txt une page qu'on voulait désindexer produit ainsi l'effet inverse, jusqu'au statut paradoxal « Indexée malgré le blocage par robots.txt ». Les cas d'usage légitimes du fichier sont détaillés dans notre article sur le statut « Bloquée par le fichier robots.txt ».
Yoast et Rank Math : ce que leurs réglages produisent côté Google
Sur la plupart des sites WordPress, ce n'est pas le cœur du CMS qui pilote l'indexation, mais le plugin SEO. Yoast et Rank Math fonctionnent sur le même principe : dans leurs réglages d'apparence dans la recherche, chaque type de contenu et chaque taxonomie dispose d'un interrupteur du type « Afficher les étiquettes dans les résultats de recherche ? ». Répondre non pose une balise noindex sur toute la famille, et chaque page concernée rejoindra « Exclue par la balise noindex » dans le rapport.
Cette architecture fait à la fois la force et le risque de ces plugins. Un seul interrupteur gouverne des centaines d'URLs : noindexer les étiquettes d'un blog en une action est un confort réel. Mais le même interrupteur, basculé sur la mauvaise famille, retire de l'index des pages qui rapportaient du trafic. Les circonstances classiques : un import de réglages, un changement de thème ou de plugin SEO, une refonte où les options ont été reprises de mémoire. La différence entre le noindex voulu et le noindex subi ne se voit pas dans l'interface du plugin ; elle se voit dans le rapport, quand une famille entière change de statut.
Il faut ajouter trois nuances que les tutoriels de plugins n'abordent pas. D'abord, le plugin écrit la balise, mais il ne rend pas le verdict : la Search Console reste la seule à dire ce que Google a fait de l'instruction. Ensuite, la balise réellement servie peut différer de celle que le plugin croit poser : un thème ou une extension qui insère sa propre meta robots peut entrer en conflit avec celle du plugin SEO. Le HTML rendu et le rapport d'indexation font foi, pas l'écran de réglages. Enfin, les sitemaps générés par ces plugins excluent normalement les familles noindexées : un sitemap qui liste des URLs en noindex envoie à Google des signaux contradictoires, et ce genre d'incohérence se repère précisément en croisant la liste du sitemap avec les statuts.
💡 Un interrupteur de plugin s'applique à des familles entières d'URLs, mais le verdict tombe URL par URL. Personne ne vérifie 2 000 étiquettes à la main dans l'inspecteur. Découvrir IndexProbe en accès anticipé →
Identifier les pages concernées sur l'ensemble de vos URLs WordPress
L'inspection d'URL donne le verdict exact d'une page ; le rapport « Indexation des pages » donne des volumes par motif. Entre les deux, il manque l'essentiel pour un site WordPress : la vue par famille. Le rapport ne se filtre pas selon vos patterns d'URL, impossible d'y isoler « toutes mes pages /tag/ » ou « toutes mes archives d'auteur » pour voir leur répartition de statuts.
La méthode qui fonctionne consiste à inspecter en masse une liste d'URLs que vous maîtrisez. Cette liste existe déjà : c'est le sitemap généré par votre plugin SEO, un export de vos contenus, ou une sélection constituée depuis la Search Console par pattern d'URL (une expression régulière sur /tag/, /author/, /page/). C'est exactement ce que permet IndexProbe : vous lui confiez cette liste, ou vous la constituez depuis votre GSC, et il interroge l'API officielle d'inspection pour chaque URL. Vous obtenez le statut d'indexation, la canonique retenue par Google et la date du dernier crawl, pour chaque page, dans un tableau filtrable.
Avec une segmentation par famille (générée par IA ou définie à la main : articles, pages, catégories, étiquettes, archives, pièces jointes), la lecture devient immédiate. Un site WordPress en bonne santé montre une physionomie caractéristique : un bloc indexé porté par les articles et les pages, un bloc « Exclue par la balise noindex » et « Explorée, actuellement non indexée » porté par les familles générées. Cet équilibre n'a rien d'inquiétant. Ce qui doit alerter, c'est un déplacement de frontière : des catégories stratégiques qui apparaissent dans le bloc noindex, des articles qui glissent vers « Explorée, actuellement non indexée », un site entier aligné sur un seul statut.
Corriger selon le statut
Une fois la répartition connue, chaque verdict appelle sa correction, et certaines situations n'en appellent aucune.
Tout le site en « Exclue par la balise noindex » : décocher la case dans Réglages > Lecture, puis accélérer le retour des pages stratégiques en demandant leur indexation, comme détaillé dans notre guide pour soumettre son site à Google. Le reste du site reviendra au rythme des recrawls, les pages fréquemment explorées d'abord.
Une famille utile en « Exclue par la balise noindex » : rebasculer l'interrupteur correspondant dans Yoast ou Rank Math, puis contrôler la balise réellement rendue dans le HTML, caches purgés. Si la famille était aussi absente du sitemap, sa réintégration donnera à Google une raison supplémentaire de repasser.
Des archives en « Explorée, actuellement non indexée » : décider avant de corriger. Une catégorie qui vise une vraie requête mérite d'être enrichie (texte d'introduction, maillage depuis les articles) ; une étiquette sans demande de recherche mérite plutôt un noindex assumé. Ce statut sur des pages sans ambition n'est pas un problème à résoudre, c'est un fonctionnement normal.
Des pièces jointes en « Soft 404 » ou en doublon : activer la redirection des URLs de pièces jointes vers le fichier dans le plugin SEO. Les statuts s'éteindront à mesure que Google constatera les redirections.
Des articles récents en « Détectée, actuellement non indexée » : sur un site jeune, laisser du temps. Sur un site établi, réduire ce qui gaspille le crawl (familles générées inutiles, variantes d'URL) et renforcer le maillage vers les contenus en attente.
Des pages utiles en « Bloquée par le fichier robots.txt » : retirer la règle en cause, en gardant l'ordre des opérations à l'esprit. Si l'objectif final est la désindexation, le noindex doit être lisible, donc le blocage robots.txt doit être levé d'abord.
Vérifier que la correction a fonctionné
Un réglage corrigé ne change rien dans la Search Console tant que Googlebot n'est pas repassé sur les pages concernées. Ce délai se compte en jours pour les pages vivantes, en semaines pour les archives peu explorées. La vérification se fait donc en deux temps : contrôler tout de suite la balise rendue dans le HTML, puis confirmer plus tard que le verdict de Google a basculé.
Pour ce second temps, la méthode est la même que pour le diagnostic : relancer l'analyse sur la même liste d'URLs et comparer. Après un noindex subi corrigé, la famille concernée doit refluer de « Exclue par la balise noindex » vers l'indexation au fil des semaines ; après une redirection des pièces jointes, les « Soft 404 » doivent s'éteindre. La vue Comparaison d'IndexProbe met les deux analyses face à face, statut par statut, et la relance planifiée avec e-mail de synthèse transforme cette vérification en surveillance : un interrupteur rebasculé par une mise à jour de plugin se repère au changement de verdict, avant la baisse de trafic.
La démarche complète : lire le verdict actuel de Google sur chaque famille de pages WordPress, corriger le réglage que ce verdict désigne, puis vérifier qu'il a changé. Essayez IndexProbe en accès anticipé pour lire ces verdicts sur l'ensemble de vos URLs WordPress, en une seule analyse.
Questions fréquentes
Combien de temps faut-il à Google pour indexer un site WordPress ?
La documentation Google évoque une semaine ou plus avant les premiers crawls d'un nouveau site, et l'indexation s'étale ensuite sur des semaines. Aucun réglage ne garantit un délai : soumettre le sitemap et demander l'indexation des pages clés accélère la découverte, pas la décision.
Faut-il indexer les étiquettes et les catégories WordPress ?
Cela se décide famille par famille, selon la demande de recherche. Une catégorie travaillée qui vise une requête réelle a sa place dans l'index ; une étiquette posée au fil de l'eau n'y apporte généralement rien et se met en noindex sans regret. L'essentiel est que le rapport d'indexation reflète votre décision, pas un réglage par défaut.
La case « Demander aux moteurs de recherche de ne pas indexer ce site » bloque-t-elle immédiatement tout le site ?
Non. C'est une demande, pas un blocage : le site reste accessible, et les pages déjà indexées sortent des résultats progressivement, au rythme des passages de Googlebot qui découvrent la balise noindex. C'est précisément cette lenteur qui rend une case oubliée si difficile à repérer sans lire les statuts.
Un plugin SEO suffit-il à faire indexer mon site WordPress ?
Non. Yoast, Rank Math et leurs équivalents facilitent le travail de Google (sitemap, balises propres, canoniques) et vous donnent la main sur le noindex par famille. Mais la décision d'indexer reste celle de Google, et un plugin mal réglé peut aussi retirer de l'index des pages utiles. Le rapport « Indexation des pages » reste le seul endroit où se lit le résultat.
Pourquoi mes pages WordPress restent-elles en « Explorée, actuellement non indexée » ?
Google les a lues et ne leur a pas trouvé d'intérêt propre pour une recherche. Sur les archives, les étiquettes et la pagination, c'est le fonctionnement attendu. Sur des articles ou des pages travaillées, ce statut invite à examiner la qualité, la redondance interne et le maillage. La priorité s'établit en regardant quelles familles concentrent le statut.
Comment vérifier ce que Google a réellement indexé sur mon site WordPress ?
Pour une URL : l'outil d'inspection de la Search Console, qui donne le statut officiel, la canonique retenue et le dernier crawl. Pour l'ensemble du site : inspecter en masse la liste de vos URLs (sitemap, export ou sélection par pattern depuis la GSC) et lire la répartition des statuts par famille. Cette vue d'ensemble révèle les réglages dont l'effet réel ne correspond plus à l'intention.