Une page qui rapporte de l’argent disparaît des résultats Google du jour au lendemain, et personne n’a touché au code. Le coupable est souvent un noindex posé des mois plus tôt, quelque part dans une redirection ou dans un en-tête serveur que l’inspection du navigateur ne montre jamais. On croit vérifier le HTML, on vérifie en réalité une version obsolète de la page. Résultat : la page reste invisible, et la perte se compte en semaines.
le noindex n’est pas toujours dans la balise meta
La plupart des contrôles s’arrêtent à l’onglet source du navigateur. On y cherche une balise meta robots, on ne la trouve pas, et on conclut que la page est indexable. C’est là que le raisonnement dérape. Une directive d’indexation peut arriver par un en-tête HTTP, et cet en-tête n’apparaît jamais dans le HTML affiché. Le guide technique de scoma-consulting.com insiste d’ailleurs sur ce point : on ne lit pas une page, on lit une réponse serveur.
Un noindex se cache à plusieurs endroits, et le plus fréquent n’est pas celui que l’on imagine. Une redirection permanente vers une URL qui porte l’en-tête, une règle ajoutée par un module de sécurité, un environnement de préproduction recopié en production. La directive se retrouve collée à l’adresse finale sans que personne ne l’ait posée volontairement sur cette page précise.
ce que les vérificateurs savent voir, et ce qu’ils ratent
Les outils spécialisés font mieux que l’œil humain, à condition de comprendre leur périmètre. Le Noindex Checker de Screpy suit jusqu’à cinq redirections avant d’examiner la réponse finale, ce qui évite de valider un noindex sur une vieille URL alors que la vraie page a changé d’adresse. Screpy applique les déclarations à l’adresse finale : si une ancienne fiche produit mène à une catégorie, les déclarations appartiennent à cette catégorie, pas à l’ancien HTML du produit.
Le vérificateur de SpeedyIndex couvre les balises HTML et les en-têtes serveur X-Robots-Tag, ce qui en fait un bon premier filtre. On peut y coller jusqu’à dix URL, une par ligne, pour vérifier leurs directives d’indexation en masse. Aucun de ces outils ne fait tout le travail à ta place, et c’est là que les angles morts se referment sur la page rentable.
- Screpy n’exécute pas JavaScript, donc une directive injectée côté client reste invisible.
- Le fichier robots.txt n’est pas consulté par Screpy.
- Et l’index Google ? Aucun de ces vérificateurs ne l’interroge vraiment.
- Pour un PDF, selon Screpy, les balises HTML ne s’appliquent pas.
La dernière ligne du tableau mérite qu’on s’y arrête. Une ressource non HTML échappe à la balise meta par nature, mais les en-têtes X-Robots-Tag peuvent toujours lui transmettre des instructions. Un catalogue PDF, un plan d’accès, une fiche tarifaire : autant de fichiers qui portent parfois un noindex sans que l’équipe technique l’ait décidé, et qui continuent d’attirer du trafic utile depuis une page bien référencée.
comment faire l’audit d’un site web sans se tromper de cible
Un audit sérieux part de l’URL réelle, pas du code source supposé. Concrètement, on colle l’adresse publique dans l’outil, on regarde la réponse finale, puis on vérifie les en-têtes de cette réponse. Si une ou deux redirections s’intercalent, c’est la dernière adresse qui porte les directives, et c’est elle qu’il faut examiner. Sauter cette étape revient à inspecter un formulaire de contact pendant que la page d’accueil est bloquée.
La méthode tient en quelques gestes qu’on peut répéter sur un parc entier. Ouvre les outils de développement, onglet réseau, recharge la page, puis sélectionne le premier document de la liste : les en-têtes s’affichent en clair. Cherche la ligne qui commence par X-Robots-Tag, et lis ce qu’elle contient. Si elle indique noindex, aucune balise meta trouvée ailleurs ne sauvera la page.
le contrôle qui part de l’URL, pas du navigateur
Pour un audit à grande échelle, il faut un outil qui envoie des requêtes et lit les réponses, pas un navigateur qui affiche du contenu. Un crawler qui suit les redirections et conserve les en-têtes donne une liste de pages à traiter, classée par type de blocage. C’est le seul moyen de repérer un noindex isolé sur une page parmi des milliers sans y passer des semaines. Sur ce point, voir aussi notre article sur sitemap maillage interne.
La question du gratuit revient souvent, et la réponse est nuancée. Des crawlers gratuits existent, avec des limites de pages ou de fonctionnalités qui suffisent pour un petit site. Pour un catalogue de plusieurs milliers d’URL, l’audit gratuit plafonne vite et laisse justement passer les cas isolés, ceux qui coûtent le plus cher. Un contrôle partiel rassure, et cette fausse sécurité est pire que pas de contrôle du tout.
empêcher l’indexation sans casser ses propres pages
Ne pas indexer une page est une opération simple, encore faut-il choisir le bon levier. La balise meta convient à une page HTML isolée qu’on maîtrise. L’en-tête X-Robots-Tag prend le relais dès qu’il s’agit d’un PDF, d’une image ou d’un fichier téléchargeable, puisque les balises HTML n’ont plus cours. Le fichier robots.txt bloque l’exploration, pas l’indexation, et confondre les deux mène droit au noindex fantôme.
Le piège classique arrive à l’étape du déploiement. Une règle de noindex posée sur un environnement de test se retrouve dans la configuration de production parce qu’un fichier a été recopié sans relecture. La page est rentable, elle a du contenu, des liens entrants, et elle ne s’affiche plus nulle part. Le repérage passe par une comparaison régulière entre la liste des pages qui génèrent du chiffre et celle des pages réellement indexables.
Le dernier point de contrôle est celui que l’on saute le plus souvent. Avant de valider une modification, on vérifie la page avec l’outil d’inspection d’URL, qui affiche la réponse telle que Google la reçoit. Un noindex résiduel s’y voit immédiatement, redirections suivies et en-têtes compris. Ce contrôle prend une minute et évite des semaines de trafic perdu.
les cas où la directive vient d’ailleurs
Il existe des situations où personne n’a touché à la page, et pourtant la directive apparaît. Un module de sécurité ajoute des en-têtes par défaut sur tous les fichiers d’un type donné. Un hébergeur applique une règle d’indexation à l’ensemble d’un répertoire après une migration. La page rentable est simplement logée au mauvais endroit, et elle hérite d’une consigne pensée pour de la préproduction.
La détection de ces cas passe par une lecture des en-têtes à intervalles réguliers, pas une seule fois après la mise en ligne. Un changement d’hébergeur, une mise à jour de plugin ou une bascule DNS peut modifier la réponse sans qu’aucun commit n’apparaisse dans le dépôt. Le suivi doit donc rester actif sur les pages qui génèrent du revenu, en priorité sur celles qui portent le plus de conversions.
reprendre le contrôle avant que la page ne coûte trop cher
Un noindex posé sur une page rentable ne fait pas de bruit. Il se glisse dans la redirection finale, dans un en-tête oublié, ou dans un fichier recopié trop vite. Le repérer demande de partir de l’adresse réelle, de suivre les redirections et de lire la réponse du serveur, pas seulement le HTML affiché. Une fois le bon réflexe installé, le contrôle devient une habitude, et la page coupable revient en ligne. Combien de temps une page peut-elle rester invisible avant que vous ne le remarquiez ?