Récemment, John Mueller de Google a répondu à une interrogation portant sur des messages fantômes de **noindex** affichés dans **Google Search Console**. Selon lui, ces rapports peuvent bien correspondre à une réalité : des pages peuvent indiquer à Google de ne pas les indexer, alors même que le propriétaire du site ne voit aucune trace de ce signal dans le code HTML public.
Que signifie un signal noindex dans Google Search Console ?
La directive **noindex** insérée dans une balise méta robots ou transmise via un en-tête HTTP est l’un des rares moyens directs dont dispose un propriétaire de site pour empêcher l’indexation par **Googlebot**. C’est un ordre que Google respecte généralement, à la différence d’autres suggestions moins explicites.
Pourtant, il arrive que **Google Search Console** affiche l’erreur « Submitted URL marked ‘noindex’ » (URL soumise marquée ‘noindex’) dans les rapports d’indexation. Ce message traduit une contradiction apparente :
- La page a été communiquée à Google via un **Sitemap**, ce qui indique l’intention d’être indexée.
- La même page envoie à Google un signal de non-indexation (**noindex**), ce qui empêche son inclusion dans l’index.
Autrement dit, **Google Search Console** indique qu’une page empêche son propre indexation alors que l’éditeur ou le SEO ne constate aucun élément dans le code HTML qui justifie cette situation.
La personne ayant soulevé le problème a publié la question sur Bluesky :
« Depuis quatre mois, notre site affiche une erreur **noindex** (dans la balise méta ‘robots’) qui ne disparaît pas de **Google Search Console**. Aucun **noindex** n’est présent sur le site ni dans le fichier robots.txt. Nous avons vérifié cela… Quelle peut être l’origine de cette erreur ? »
Quand le noindex n’apparaît que pour Google
John Mueller a expliqué qu’il a déjà rencontré des cas où un **noindex** était effectivement renvoyé, mais uniquement visible par Google. Autrement dit, certaines configurations serveur ou intermédiaires peuvent renvoyer une directive de non-indexation à l’agent de Google sans qu’elle soit perceptible depuis la version publique du site consultée par l’éditeur.
« Dans les cas que j’ai observés, il y avait bel et bien un **noindex**, parfois envoyé uniquement à Google (ce qui complique le débogage). »
Mueller n’a pas détaillé toutes les mécaniques possibles, mais plusieurs pistes de diagnostic permettent d’identifier la source de ce signal caché.
Procédure pour diagnostiquer un noindex « fantôme »
Il existe plusieurs facteurs techniques qui peuvent conduire à l’affichage d’un **noindex** uniquement pour Google :
- Mise en cache serveur d’anciens en-têtes HTTP contenant un **noindex** ;
- Règles spécifiques au niveau d’un CDN ou d’un pare-feu d’application web (WAF) qui renvoient des en-têtes différents selon l’IP ou l’user-agent ;
- Scripts côté serveur ou configurations conditionnelles affichant des balises ou en-têtes différents selon la source de la requête ;
- Erreurs humaines (déploiement temporaire d’un **noindex** non nettoyé) dont les résidus persistent dans des caches.
Pourquoi des caches ou des CDN peuvent masquer la cause
Si une page a déjà renvoyé un **noindex** et que cette réponse a été mise en cache par un plugin de cache serveur ou par un service de distribution de contenu comme **Cloudflare**, il est possible que Google (qui crawle fréquemment) reçoive encore l’ancienne réponse, tandis que l’éditeur, visitant le site via un navigateur ou en purgeant certains caches, voit une version à jour sans **noindex**. Les caches peuvent conserver des en-têtes HTTP, y compris la directive de robots s’ils étaient présents au moment de la mise en cache.
Comment vérifier les en-têtes HTTP
Contrôler les **en-têtes HTTP** envoyés par le serveur est une étape simple et essentielle. Plusieurs outils en ligne permettent d’examiner les en-têtes renvoyés par une URL, par exemple KeyCDN et SecurityHeaders :
En observant la réponse du serveur, recherchez explicitement des en-têtes ou des balises contenant **noindex** (par exemple l’en-tête HTTP « X-Robots-Tag » ou la balise meta robots dans le HTML renvoyé). Si vous constatez que certains outils retournent un code d’état différent (par exemple un 520), cela peut indiquer qu’un intermédiaire bloque ou altère la réponse.
Exemple : code réponse 520 renvoyé par Cloudflare
Un code de réponse 520 correspond à une erreur renvoyée par **Cloudflare** lorsqu’il bloque une requête ou rencontre une anomalie côté origine/serveur. Voici une capture d’écran d’un 520 :
En contraste, voici une capture d’écran montrant une réponse 200 :
Capture écran : réponse 200
Si un contrôleur HTTP retourne parfois une réponse 520 et parfois une 200 selon l’outil utilisé, cela révèle que le comportement du réseau ou du CDN varie en fonction du point d’accès. Il est donc utile de tester l’URL depuis plusieurs services afin de détecter une incohérence.
Faire inspecter la page par Google depuis l’adresse IP de Google
Lorsque la page renvoie un contenu différent à Google qu’aux visiteurs humains, la méthode la plus fiable consiste à demander à Google d’examiner la page en utilisant un de ses propres robots depuis une IP appartenant à Google. Un outil pratique pour cela est le Rich Results Test de Google.
En soumettant l’URL au Rich Results Test, Google lance une requête à partir d’une adresse IP de ses data centers. L’outil fournit ensuite :
- La réponse HTTP complète reçue par Google ;
- Un rendu ou instantané de la page tel que vu par le robot ;
- Une indication sur la présence d’erreurs liées aux balises structurées et, si la page est bloquée, une mention explicite (par exemple « Page not eligible » ou « Crawl failed ») et le détail « Robots meta tag: noindex ».
Nota : le Rich Results Test n’utilise pas nécessairement la chaîne user-agent exacte de **Googlebot** ; il se présente souvent avec l’identifiant « Google-InspectionTool/1.0 ». Néanmoins, comme la requête provient d’une adresse IP Google officielle, tout filtrage basé sur l’IP sera détecté par cette méthode.
Quand le blocage cible l’agent utilisateur (User Agent)
Si une configuration serveur ou un script renvoie un **noindex** uniquement lorsque l’agent utilisateur indique qu’il s’agit de **Googlebot**, il faut vérifier la réponse en mimant cet agent. Plusieurs approches permettent de simuler la chaîne de l’agent :
- Utiliser une extension de navigateur qui modifie le user-agent, par exemple le User Agent Switcher pour Chrome ;
- Configurer des outils d’audit comme Screaming Frog pour s’identifier explicitement en tant que **Googlebot** ;
- Faire des requêtes HTTP programmées (curl, wget) en spécifiant le header « User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html) ».
Ces méthodes permettent d’observer si la page renvoie des en-têtes ou un HTML différent selon l’agent. Voici une capture d’écran montrant l’extension de changement d’agent :
Capture écran : changement d’agent dans Chrome
Étapes détaillées de diagnostic
Voici une démarche systématique à suivre lorsque Google Search Console indique un problème “Submitted URL marked ‘noindex’” et que le **noindex** n’est pas visible au premier examen :
1) Vérifier l’historique et les changements récents
Consultez les logs de déploiement, les commits, ou toute modification récente apportée aux modèles de page, aux plugins de cache ou à la configuration du CDN. Un déploiement antérieur ayant accidentellement ajouté un **noindex** peut laisser des traces dans des caches.
2) Examiner les en-têtes depuis plusieurs points d’accès
Utilisez différents checkers d’en-têtes (par ex. KeyCDN, SecurityHeaders.com, ainsi que des requêtes curl depuis serveurs distants) afin d’identifier toute variation des réponses. Recherchez :
- Un en-tête « X-Robots-Tag » contenant **noindex** ;
- La présence d’une balise <meta name= »robots »> avec la valeur **noindex** dans le HTML rendu ;
- Des codes HTTP non standards (520, 503, 403) susceptibles d’indiquer qu’un intermédiaire bloque ou modifie la réponse.
3) Tester la page via le Rich Results Test de Google
Saisissez l’URL dans le Rich Results Test. Si l’outil renvoie un message d’échec ou une mention de la balise « Robots meta tag: noindex », cela confirme que Google reçoit bien la directive, même si vous ne la voyez pas côté éditeur.
4) Mimer le comportement de Googlebot
Configurez un agent utilisateur égal à **Googlebot** avec un outil d’exploration (Screaming Frog, curl, ou navigateur modifié) et comparez la réponse avec celle obtenue en tant qu’utilisateur normal. Si la réponse varie, cela indique une logique conditionnelle côté serveur.
5) Inspecter les règles du CDN et du pare-feu
Examinez la configuration de votre CDN (notamment **Cloudflare** si vous l’utilisez) et du WAF pour détecter des règles qui pourraient renvoyer des en-têtes différents selon l’IP, la géolocalisation, l’UA, ou d’autres paramètres. Purgez les caches pertinents (cache applicatif, cache CDN) et réessayez les tests.
6) Vérifier les caches applicatifs et les modules serveur
Beaucoup de plugins de cache CMS ou des modules serveur conservent des en-têtes. Purgez ces caches et, si possible, désactivez temporairement le plugin ou module pour vérifier si le comportement persiste.
7) Consulter les logs serveur
Les journaux d’accès et d’erreurs au niveau serveur peuvent révéler des différences de traitement. Recherchez les requêtes effectuées par les IP de Google et comparez les réponses réelles renvoyées par l’origine.
Cas particuliers et exemples concrets
Voici quelques scénarios réels qui expliquent souvent l’apparition d’un **noindex** invisible :
Cache d’en-têtes après une correction
Un développeur corrige une page en retirant la balise **noindex**, mais un cache serveur ayant stocké la réponse antérieure continue à renvoyer l’en-tête « X-Robots-Tag: noindex ». Google, qui crawle régulièrement, reçoit donc encore le signal de non-indexation tant que le cache n’est pas purgé ou expiré.
Règles conditionnelles côté serveur
Des scripts PHP, des règles .htaccess, ou une logique d’application peuvent insérer dynamiquement une balise méta robots ou un en-tête « X-Robots-Tag » selon certaines conditions (session, cookie, origine de la requête, user-agent). Si ces conditions ciblent involontairement les bots, Google peut voir une version différente du HTML.
Blocage via le CDN ou le WAF
Un CDN peut appliquer des règles visant à bloquer le crawl excessif et, au lieu de renvoyer une simple erreur, il peut renvoyer une réponse qui inclut une directive **noindex**. De plus, des erreurs comme le 520 signalent que le CDN a rencontré un problème en interagissant avec l’origine.
Que faire si vous identifiez un noindex caché ?
Une fois la source identifiée : corrigez la configuration (purgez les caches, retirez la logique conditionnelle qui ajoute le **noindex**, ajustez les règles CDN/WAF) et vérifiez ensuite que Google voit bien la version mise à jour en utilisant à nouveau le Rich Results Test et en surveillant les rapports de **Google Search Console**. Notez qu’il peut y avoir un délai entre la correction et la levée de l’avertissement dans la console, car Google doit recrawler la page et mettre à jour son indexation.
Questions fréquentes et conseils supplémentaires
Voici des réponses concises à des préoccupations courantes liées à ce type de problème :
- Si je ne trouve pas de noindex dans mon HTML, dois-je m’inquiéter ?
Pas nécessairement, mais il faut vérifier les en-têtes HTTP, le comportement du CDN, et simuler l’accès depuis les IP Google et avec l’agent **Googlebot**.
- Combien de temps pour que l’erreur disparaisse de Google Search Console ?
Après correction, le délai dépend de la fréquence de crawl de la page et du moment où Google recrawle et réindexe. Utiliser la fonctionnalité d’inspection d’URL dans la console peut accélérer l’analyse, mais l’effet dans les rapports peut prendre du temps.
- Est-ce que l’utilisation d’un CDN comme Cloudflare augmente le risque de comportements différents pour Google ?
Un CDN ajoute une couche intermédiaire susceptible d’altérer les réponses selon les règles configurées. Bien configuré, un CDN n’entraîne pas de différence, mais des règles inadaptées ou des caches d’en-têtes peuvent provoquer des surprises.
- Dois-je craindre que Google ignore d’autres directives si un noindex apparaît par erreur ?
Un **noindex** efficace empêchera l’indexation de la page; d’autres directives seront prises en compte selon les règles habituelles. L’essentiel est d’identifier et de corriger toute source involontaire de **noindex**.
Conclusion : rester méthodique face aux erreurs « fantômes »
Les messages indiquant qu’une URL soumise est marquée « noindex » dans **Google Search Console** peuvent être frustrants, surtout lorsque l’éditeur ne voit rien d’anormal dans le code. Toutefois, avec une démarche méthodique — inspection des en-têtes HTTP, tests via le Rich Results Test, simulation du comportement de Googlebot et vérification des caches/CDN/WAF — il est possible de localiser la cause et de la corriger.
Privilégiez l’analyse pas à pas : identifiez si le **noindex** est renvoyé au niveau HTML ou via un en-tête, testez depuis plusieurs points d’accès, vérifiez la configuration du CDN et purgeant les caches, puis validez via les outils Google. Cette approche réduit considérablement le temps passé à diagnostiquer des erreurs qui paraissent au départ “fantômes”.
Image en vedette par Shutterstock/AYO Production
