"Exclue par la balise noindex" : voulu ou erreur ? (Search Console)
Dans le rapport « Indexation des pages » de la Google Search Console, « Exclue par la balise noindex » est l'un des statuts les plus limpides : Google a trouvé une instruction de ne pas indexer la page, et il l'a suivie. La plupart du temps, c'est exactement ce que vous vouliez — pages de connexion, de panier, archives de tags.
Le problème surgit quand l'instruction n'était pas la vôtre. Comment repérer, parmi des centaines de noindex légitimes, la page stratégique désindexée par erreur ? Pourquoi un noindex reste-t-il actif alors que vous ne le trouvez nulle part dans le code de la page ? Et que faire quand Google ne voit même pas le noindex que vous venez de retirer ?
Trois questions où ce statut, d'apparence trivial, devient nettement moins simple.
Que signifie « Exclue par la balise noindex » ?
Ce statut signifie que la page porte une directive noindex — dans une balise meta ou dans un en-tête HTTP — et que Google l'a respectée : il a exploré la page, mais ne l'a pas ajoutée à son index. C'est une exclusion volontaire au niveau de la page, et dans la plupart des cas elle est intentionnelle.
À la différence d'un blocage robots.txt, qui empêche l'exploration, le noindex laisse Google crawler la page : il lit son contenu, voit l'instruction de ne pas l'indexer, et s'y conforme. C'est d'ailleurs la méthode que Google recommande pour tenir une page hors de l'index.
La page n'est donc pas « cassée ». Elle obéit à une consigne. Toute la question est de savoir si cette consigne est bien la vôtre.
Voulu ou accidentel ? Cela dépend de votre intention
Il n'y a pas de réponse unique : tout dépend de ce que vous attendiez de la page. Deux cas, deux décisions opposées. Tant que vous ne les avez pas distingués, vous ne pouvez pas appliquer la bonne correction.
Cas A : le noindex est voulu, tout va bien. Pages de connexion, de compte, de panier et de confirmation de commande, résultats de recherche interne, archives de tags ou de dates à faible valeur, flux RSS, pages de remerciement… Vous les avez mises en noindex exprès pour qu'elles n'apparaissent pas dans Google. Les voir listées en « Exclue par la balise noindex » est le résultat attendu. Il n'y a rien à corriger.
Cas B : une page utile est en noindex par erreur. Une page que vous vouliez indexée porte un noindex que vous n'avez pas voulu : un réglage hérité d'une préproduction, un noindex appliqué à tout un gabarit, un plugin mal configuré. Tant qu'il est là, la page ne sera jamais indexée. Ici, l'objectif est de retirer le noindex — encore faut-il le trouver.
Le tri entre A et B est tout le travail. Et avant de corriger le cas B, il faut savoir d'où vient réellement le noindex.
D'où vient le noindex : balise meta ou en-tête HTTP
Un noindex peut être posé à deux endroits, et c'est la source de l'erreur la plus tenace sur ce statut. Le premier est la balise meta, dans le <head> de la page :
<meta name="robots" content="noindex">
Le second est un en-tête HTTP X-Robots-Tag, renvoyé par le serveur avec la page :
X-Robots-Tag: noindex
Les deux ont le même effet pour Google. Mais le second est invisible dans le code source de la page : vous ouvrez le HTML, vous ne trouvez aucune balise noindex, vous concluez qu'il n'y en a pas. C'est faux. L'instruction est dans la réponse du serveur, pas dans le HTML.
C'est le piège classique : vous retirez une balise meta qui n'existe pas, vous attendez, et rien ne change. Pour le déjouer, il faut inspecter la réponse HTTP de la page (les en-têtes), pas seulement son code source. L'outil d'inspection d'URL de la Search Console indique, lui, si Google a vu un noindex — mais une URL à la fois.
Pourquoi une page utile se retrouve en noindex (cas B)
Quand une page que vous vouliez indexer porte un noindex, c'est presque toujours un réglage involontaire. Les causes les plus fréquentes :
- Un reste de préproduction. Pendant le développement, le site entier est souvent en
noindex. Si le réglage n'est pas levé à la mise en production, des pages utiles restent exclues. Sur WordPress, c'est la case « Demander aux moteurs de recherche de ne pas indexer ce site ». - Un
noindexappliqué à tout un gabarit. Un réglage par type de contenu (catégories, pages auteur, un modèle de page) peut désindexer une famille entière d'URLs en bloc, dont certaines que vous vouliez garder. - Un plugin ou un thème. Une extension SEO mal configurée, ou un thème qui injecte ses propres balises, peut poser un
noindexà votre insu. - Un en-tête serveur ou CDN. Une règle
X-Robots-Tagau niveau du serveur, d'un reverse proxy ou d'un CDN, invisible dans le HTML (voir la section précédente). - Une migration. Lors d'un changement de CMS ou de domaine, des directives
noindexse transfèrent ou se recréent sur des pages qui ne devaient pas en avoir.
Le point commun : une consigne noindex est active là où vous n'en vouliez pas. Reste à trouver où, et sur quelles pages.
Le piège : robots.txt et noindex ne se combinent pas
Avant de corriger, un cas particulier mérite l'attention, parce qu'il bloque silencieusement la moitié des tentatives de correction : si une page est bloquée par le robots.txt, Google ne verra jamais son noindex.
La logique est implacable : le noindex est dans la page (ou dans sa réponse HTTP) ; or le robots.txt empêche Google de crawler la page. Sans crawl, pas de lecture de l'instruction. Google le précise explicitement : pour qu'un noindex soit pris en compte, la page ne doit pas être bloquée par le robots.txt.
Conséquence dans les deux sens : si vous voulez désindexer une page, ne la bloquez pas au crawl en même temps — laissez Google la lire pour voir le noindex. Et si vous voulez indexer une page qui porte un noindex involontaire, vérifiez aussi qu'elle n'est pas, en plus, bloquée par le robots.txt. Le sujet est détaillé dans « Bloquée par le fichier robots.txt ».
Maintenant que vous connaissez les causes et les sources possibles, identifiez précisément quelles pages sont concernées — avant de décider quoi corriger.
Identifier les pages concernées sur la liste que vous analysez
C'est là que la Search Console montre sa limite : son outil d'inspection d'URL ne traite qu'une seule URL à la fois. Pour savoir, page par page, laquelle porte un noindex, d'où il vient (meta ou en-tête HTTP) et si la page comptait pour vous, vous inspectez, vous lisez, vous passez à la suivante. Sur quelques pages, c'est jouable. Sur des centaines, repérer la page stratégique désindexée par erreur devient impraticable.
C'est le mur qu'IndexProbe fait sauter. IndexProbe est la version en masse de l'outil d'inspection d'URL de Google : il interroge l'API officielle de la Search Console pour inspecter, en une seule analyse, la liste d'URLs que vous lui fournissez (import CSV, sitemap, copier-coller). Pour chaque page, il affiche son statut d'indexation, son statut noindex et sa source — balise meta ou en-tête HTTP X-Robots-Tag, le segment d'URL et les liens internes reçus.
Ce que vous en tirez dépend de la liste que vous apportez. IndexProbe n'explore pas votre site pour découvrir des URLs : il inspecte celles que vous lui donnez, et celles-là seulement.
- Une sélection de pages stratégiques (vos pages clés, votre sitemap des pages à indexer). Toute page importante qui ressort en
noindexest un cas B immédiat : une page que vous vouliez indexer, exclue par erreur. Vous la repérez sans rien présumer du reste du site. - Un export complet de vos URLs (sitemap entier, export de crawl…). La segmentation par type de pages montre alors où le noindex se concentre — un gabarit entier exclu en bloc ressort aussitôt — et la source (meta vs en-tête HTTP) vous dit où aller corriger.
Voir la source du noindex — balise meta ou en-tête HTTP — à l'échelle, aucun autre outil ne le donne.
💡 Vous voulez savoir lesquelles de vos URLs sont en noindex, d'où vient l'instruction et si une page stratégique est concernée ? IndexProbe inspecte votre liste d'URLs et vous donne la réponse en une analyse. Tester IndexProbe en accès anticipé →
Corriger selon le cas
Une fois vos pages triées, la correction dépend du cas. Ne mélangez pas les deux : la bonne action pour une page utile est l'opposé de « ne touchez à rien ».
Retirer un noindex involontaire (cas B)
L'objectif est de supprimer la directive noindex là où elle se trouve réellement.
- Trouvez la source. Inspectez l'URL et regardez si le
noindexvient de la balise meta (visible dans le HTML) ou de l'en-tête HTTPX-Robots-Tag(visible seulement dans la réponse du serveur). - Retirez-la au bon endroit. Une balise meta se retire dans le contenu, le gabarit ou le réglage SEO de la page ; un en-tête
X-Robots-Tagse retire dans la configuration du serveur, du proxy ou du CDN. - Vérifiez l'absence de blocage
robots.txtsur la page : sinon Google ne reverra jamais la page débloquée du noindex. - Demandez une réinspection dans la Search Console, puis laissez à Google le temps de recrawler et de réindexer.
Laisser un noindex voulu (cas A)
Pour les pages que vous vouliez exclure, il n'y a rien à corriger : le statut est le résultat attendu. Profitez-en pour vérifier qu'un réglage par gabarit n'attrape pas, au passage, une page que vous vouliez garder.
Selon votre CMS
- WordPress. Vérifiez d'abord Réglages → Lecture : la case « Demander aux moteurs de recherche de ne pas indexer ce site » pose un
noindexglobal, à décocher en production. Pour le réglage page par page ou par type de contenu, utilisez Yoast SEO, Rank Math ou All in One SEO. - Shopify. Les pages de panier et de compte sont en
noindexpar défaut. Pour ajuster unnoindexsur un modèle, passez par les balises du thème (theme.liquid/ templates) ; évitez de désindexer un type de page entier sans le vouloir.
« Exclue par noindex » vs « Bloquée par robots.txt » vs « Indexée malgré le blocage »
Trois statuts de la Search Console se ressemblent et se règlent très différemment. La grille de lecture :
| Statut GSC | D'où vient l'exclusion | Page indexée ? | Action |
|---|---|---|---|
| Exclue par la balise 'noindex' | directive noindex (meta ou en-tête HTTP) |
Non | Rien si voulu ; retirer le noindex si page utile |
| Bloquée par le fichier robots.txt | robots.txt (crawl interdit) |
Non | Rien si voulu ; débloquer si page utile piégée |
| Indexée malgré le blocage par robots.txt | robots.txt, mais URL trouvée ailleurs |
Oui | Débloquer puis noindex pour désindexer |
Les trois ont une logique différente : le premier exclut au niveau de la page (Google a lu la consigne), le deuxième empêche le crawl, le troisième révèle que le blocage n'a pas suffi. Les confondre, c'est appliquer la mauvaise correction. Voir « Bloquée par le fichier robots.txt » et « Indexée malgré le blocage ».
Vérifier que la correction a fonctionné
Après avoir retiré le noindex de vos pages du cas B, confirmez à l'échelle que Google a recrawlé. Réinspectez vos URLs et comparez deux analyses dans le temps : les pages que vous avez corrigées doivent quitter le statut « Exclue par la balise noindex », puis basculer en indexées.
C'est la boucle complète : comprendre que le noindex est souvent voulu, trier A/B, trouver la vraie source (meta ou en-tête), corriger, vérifier.
Questions fréquentes
« Exclue par la balise noindex », est-ce grave ?
Pas en soi. Dans la majorité des cas, c'est un noindex volontaire qui fait son travail : connexion, panier, archives de tags. Cela ne devient un problème que si une page que vous vouliez indexer porte un noindex par erreur.
Pourquoi ma page est-elle en noindex alors que je n'ai rien mis ?
Le noindex peut venir d'un réglage CMS appliqué à tout un gabarit, d'un plugin, d'un reste de préproduction, ou d'un en-tête HTTP X-Robots-Tag posé au niveau du serveur — invisible dans le code source de la page. Inspectez la réponse HTTP, pas seulement le HTML.
Comment retirer un noindex ?
Trouvez d'abord sa source : balise meta dans le <head>, ou en-tête HTTP X-Robots-Tag. Retirez-la au bon endroit (contenu/gabarit/réglage SEO pour la meta ; configuration serveur/CDN pour l'en-tête), vérifiez qu'aucun blocage robots.txt n'empêche le recrawl, puis demandez une réinspection.
Pourquoi mon noindex ne disparaît-il pas après l'avoir retiré ?
Deux causes fréquentes : soit le noindex venait en réalité d'un en-tête HTTP que vous n'avez pas modifié (vous avez retiré une balise meta inexistante), soit la page est bloquée par le robots.txt et Google ne peut pas la recrawler pour constater le changement.
Faut-il utiliser noindex ou robots.txt ?
Le noindex empêche l'indexation (la page peut être crawlée mais n'apparaît pas dans les résultats) : c'est l'outil pour retirer une page de l'index. Le robots.txt empêche le crawl (utile pour économiser le budget de crawl). Les deux ne se combinent pas : un noindex sur une page bloquée au crawl ne sera jamais vu.
Comment vérifier ce statut sur un grand nombre d'URLs ? L'inspecteur d'URL de la Search Console ne traite qu'une URL à la fois. Pour trier à l'échelle, un outil comme IndexProbe inspecte la liste d'URLs que vous lui fournissez (CSV, sitemap) et affiche, pour chacune, le statut d'indexation, le statut noindex et sa source (meta ou en-tête HTTP).
Arrêtez de chercher un noindex que vous ne voyez pas. IndexProbe se branche sur l'API officielle de la Search Console et inspecte votre liste d'URLs en une seule analyse : statut d'indexation, statut noindex et sa source (balise meta ou en-tête HTTP), par segment. Vous séparez en quelques minutes les exclusions voulues des pages utiles désindexées par erreur, et vous vérifiez vos corrections d'une analyse à l'autre.