Poser une balise noindex en production, c’est signer un arrêt de mort à retardement. Le jour J, rien ne bouge : la page répond, elle s’affiche, et les visiteurs continuent d’arriver depuis Google comme si de rien n’était. Puis les semaines passent, et le trafic s’effondre d’un coup, sans prévenir. Entre-temps, on a oublié la balise, on a publié autre chose, on a cherché la panne ailleurs. Comprendre ce décalage, c’est la seule façon d’éviter de perdre des semaines de visibilité avant de réagir.
La balise noindex, ce qu’elle fait vraiment
Une balise noindex est une instruction donnée aux robots d’indexation. Elle leur dit : explore cette page si tu veux, mais ne la garde pas dans ton index. La nuance compte, parce que beaucoup la confondent avec une interdiction d’exploration. Le robots.txt bloque le crawl ; le noindex bloque l’inscription dans les résultats.
Ce ne sont pas les mêmes outils. Google précise noir sur blanc qu’on ne peut pas déclarer une règle noindex dans un fichier robots.txt, car le robot ne lirait jamais l’instruction. Si vous cherchez à approfondir ces distinctions, referencement-dom.com détaille les cas où chaque méthode s’applique.
La règle s’écrit de deux manières. Soit dans le code de la page, avec <meta name="robots" content="noindex"> glissé dans la section <head>. Soit dans les en-têtes HTTP renvoyés par le serveur, ce qui demande une configuration côté back-end mais produit exactement le même effet. Pour ne viser que les robots de Google, on remplace « robots » par « googlebot » dans l’attribut name. Et si l’on veut aussi couper le suivi des liens sortants, on ajoute nofollow dans le même content.
Pourquoi on pose volontairement une balise noindex
Il y a de bonnes raisons. Une page de remerciement après commande n’a rien à faire dans les résultats. Des résultats de recherche internes, des filtres à combinaisons infinies, des archives de tags vides : tout ça dilue le budget de crawl.
Google s’épuise alors sur des pages sans valeur au lieu d’explorer vos vrais contenus. Un stagiaire qui duplique un environnement de test sur un sous-domaine oubliera souvent la protection, et c’est là que les ennuis commencent.
Sur WordPress, la case la plus dangereuse se cache dans Réglages puis Lecture, sous le libellé « Demander aux moteurs de recherche de ne pas indexer ce site ». Un clic, et tout le site passe en noindex. Elle sert quand on travaille sur une préproduction ouverte au public. Sauf qu’on l’oublie au moment de basculer en ligne. Franchement, ce cas représente la majorité des incidents que je vois passer.
Le décalage entre la pose et la chute
Voilà le point que presque personne n’explique. Google ne recrawle pas votre page à la seconde où vous modifiez son code. Il repasse quand il repasse, selon la fréquence qu’il a décidée, votre autorité, la fraîcheur de votre contenu.
Une fois qu’il a vu le noindex, il retire l’URL de son index lors d’une mise à jour suivante, parfois plusieurs jours après. Et c’est seulement à ce moment que les impressions commencent à chuter dans la Search Console.
Puis vient la troisième étape, la plus sournoise. Même sortie de l’index, la page garde pendant un temps des signaux hérités : les liens internes qui pointent vers elle, les mentions externes, l’historique de clics. Google ne purge pas tout d’un coup. Sur ce point, voir aussi notre article sur destinations externalisation contenu seo 2026.
Le trafic résiduel continue de couler pendant des semaines. Cela donne l’illusion que tout va bien alors que la page est déjà condamnée. On détecte donc l’incident trop tard, quand la chute est franche et que le mal est fait.
Reconnaître les signaux avant la catastrophe
Le statut « Détectée actuellement non indexée » dans la Search Console est le premier avertissement sérieux. Il ne signifie pas que la page a disparu, il indique que Google l’a bien vue mais a décidé de ne pas la garder. Si vous voyez ce message sur une page qui générait du trafic, vérifiez immédiatement son code source.
- La balise
<meta name="robots">dans le<head>du HTML, visible avec un simple affichage du code source. - Un en-tête HTTP de type X-Robots-Tag, souvent posé par le serveur ou un plugin et invisible dans la page.
- La case fatidique des réglages WordPress est-elle cochée ?
- Le sitemap déclare-t-il encore l’URL, alors que la page est bloquée ?
- Un plugin SEO a-t-il été mis à jour juste avant la chute, changeant ses réglages par défaut ?
Les logs serveur complètent le tableau. En filtrant les requêtes du robot Googlebot sur les URL concernées, on voit si le crawl est récent ou ancien. Si Googlebot n’est pas repassé depuis des semaines, le noindex n’a peut-être pas encore produit son effet complet.
Il reste alors une fenêtre pour agir. Pour demander explicitement aux moteurs de ne pas indexer une page, l’outil de suppression temporaire de la Search Console fonctionne aussi, mais il masque le problème au lieu de le corriger.
Réparer, puis accélérer la réindexation
La correction elle-même prend cinq minutes : on retire la balise ou on décoche la case, on vide le cache, on s’assure que la page se charge avec un contenu normal. Le plus dur commence après. Google doit recrawler, réinscrire la page, puis reconstruire le passage depuis les résultats. Comptez plusieurs semaines, parfois plus, pour retrouver le niveau de trafic d’avant.
On peut raccourcir ce délai. Demander une inspection d’URL dans la Search Console accélère le traitement, surtout si la page fait partie d’un site que Google visite régulièrement. Renforcer les liens internes vers la page concernée aide aussi à signaler qu’elle compte à nouveau. Et si plusieurs pages sont touchées, il faut toutes les passer en revue : une balise noindex oubliée sur une seule URL d’une catégorie suffit à faire plonger toute la section.
Le vrai coût d’une balise oubliée
Ce qui rend le noindex dangereux, ce n’est pas la balise elle-même : c’est le silence qui l’entoure pendant des semaines. On ne perd pas du trafic le jour où l’on fait l’erreur, on le perd quand on a cessé d’y penser.
Une simple vérification du code source au moment d’une mise en production, ou un contrôle mensuel des statuts d’indexation dans la Search Console, suffit à éviter la plupart de ces accidents. La question n’est pas de savoir si votre site peut perdre son indexation, mais combien de temps il vous faudra pour vous en apercevoir.
