Comment éviter le contenu inindexable involontaire en SEO technique

Un client m'appelle en panique, un mardi matin. Sa page de catégorie principale, celle qui lui rapportait 40 % de son trafic organique, a disparu des résultats Google. Pas pénalisée : absente. Aucun avertissement dans la Search Console, aucun message manuel. Juste… plus rien.

On a mis deux jours à comprendre. Et la cause est tellement bête que j'en ai presque ri. Presque.

Le problème ? Une balise noindex laissée en place par un développeur lors d'une mise en production, six mois plus tôt. Le genre d'erreur qu'on appelle pudiquement du « contenu inindexable involontaire ». Sauf qu'il n'y a rien de pudique là-dedans : c'est de l'argent qui part en fumée pendant que vous dormez.

Comment une page devient inindexable sans que vous le vouliez

Il faut d'abord poser un truc simple, parce que la confusion vient souvent de là. Explorer, indexer et classer sont trois étapes distinctes. Et Google les franchit dans cet ordre.

Des robots explorent constamment le web pour découvrir des pages. Une fois découverte, une URL passe en file d'attente, puis Googlebot la visite, la lit, et décide de l'ajouter à son index. C'est seulement à partir de ce moment qu'elle peut apparaître dans une recherche. Une page peut donc être explorée mais jamais indexée. C'est le fameux statut « explorée, actuellement non indexée ».

Là où ça se corse, c'est quand une instruction demande à Google de ne PAS indexer. Et l'ironie, c'est qu'il existe deux façons de formuler cette demande. Une qui marche. Une qui produit l'effet inverse de celui espéré.

Les deux visages du noindex

La directive noindex peut prendre deux formes. La balise meta dans le <head> de la page :

<meta name="robots" content="noindex, nofollow">

Ou l'en-tête HTTP X-Robots-Tag, envoyé par le serveur. Le second est plus discret — on ne le voit pas en affichant le code source — et c'est précisément pour ça qu'il cause tant de dégâts chez ceux qui ne connaissent pas son existence.

Une précision qui a son importance : nofollow et noindex ne font pas la même chose. Le premier empêche de suivre les liens sortants de la page. Le second empêche l'indexation de la page elle-même. On les colle souvent ensemble par réflexe, alors qu'ils répondent à des besoins différents.

Bon, et maintenant le vrai sujet. Celui qui explique 80 % des cas que je traite.

Le piège robots.txt qui empêche la désindexation

Voici la scène. Un site a une page de démo interne, ou un PDF confidentiel, ou une ancienne landing page devenue inutile. L'équipe technique veut la sortir de l'index. Réflexe : on met un Disallow dans le robots.txt.

Grosse erreur. Et je pèse mes mots.

Parce qu'un Disallow dans le robots.txt dit à Googlebot : ne visite pas cette URL. Or, pour lire une balise noindex, il faut… visiter la page. Vous voyez le problème ? Googlebot ne peut pas voir l'instruction qui lui demande de ne pas indexer, parce qu'une autre instruction lui interdit de venir la lire.

Résultat : la page reste indexée. Parfois pendant des années. Avec son titre, son extrait, tout. J'ai vu un site de e-commerce garder des pages de soldes obsolètes dans les résultats pendant plus de 18 mois pour cette exact raison.

Dans quel ordre procéder

La séquence correcte, celle que j'applique désormais systématiquement :

1. Retirer le blocage robots.txt sur l'URL concernée. Sans cette étape, tout ce qui suit ne sert à rien.
2. Vérifier que la page renvoie bien un code 200 (pas un 404, pas une redirection).
3. Placer la balise noindex dans le <head> — ou laisser Googlebot voir l'en-tête HTTP.
4. Attendre. Puis vérifier.

L'ordre n'est pas négociable. J'ai perdu des semaines à comprendre ça, au début. Je posais le noindex, j'attendais, rien ne bougeait, je recommençais. Le robots.txt bloquait tout, et je ne le voyais même pas.

Où se trouve la balise noindex, et comment la diagnostiquer

Trois emplacements possibles. Par ordre de fréquence dans mes audits :

• Dans le <head> de la page — visible via « afficher le code source ».
• Dans un en-tête HTTP X-Robots-Tag — invisible sans les outils de développement ou une commande cURL.
• Dans un fichier robots.txt mal configuré qui désindexe un dossier entier par accident (Disallow: / au lieu de Disallow: /admin/, le classique).

La Search Console reste votre meilleur allié pour trancher. Le rapport « Pages » sous « Indexation » liste les URL exclues avec leur motif exact. Et l'inspection d'URL vous donne l'état réel d'une page précise, avec le test en direct qui affiche ce que Googlebot voit vraiment au moment où vous le lancez.

Ce test en direct est sous-estimé. Il montre le code rendu, pas le code source brut. Donc si votre noindex est injecté par JavaScript, vous le verrez là — et pas forcément ailleurs.

Comparatif des méthodes de blocage

Méthode	Empêche l'indexation ?	Empêche l'exploration ?	Visible en code source
Balise meta noindex	Oui	Non	Oui
En-tête X-Robots-Tag	Oui	Non	Non
Disallow (robots.txt)	Non	Oui	Non (autre fichier)
Mot de passe / page protégée	Oui	Partiel	Non

Ce tableau résume à lui seul pourquoi le robots.txt est un faux ami. Il empêche l'exploration, pas l'indexation. Ce sont deux choses différentes, et les confondre coûte cher.

Quand la désindexation devient un cauchemar

Un détail que personne ne mentionne jamais assez : le retour en arrière.

Retirer un noindex, c'est facile. Récupérer sa position d'avant, non. Sur un site que j'ai suivi, une page produit désindexée pendant deux mois a mis onze semaines à revenir dans le top 10 de sa requête principale. Onze semaines à regarder une courbe plate en se demandant si on n'avait pas définitivement perdu le bénéfice de deux ans de travail.

Google doit rescanner la page, la réintégrer, puis recalculer son positionnement dans un contexte concurrentiel qui a bougé entre-temps. Vos concurrents ont continué à publier pendant que vous étiez invisible.

Ma règle, du coup : ne jamais mettre un noindex « temporairement, juste pour tester ». Ou alors avec une date de rappel notée quelque part, et un ticket ouvert. Parce que le temporaire qui devient permanent, c'est le scénario le plus courant que je rencontre.

Questions fréquentes

Où se trouve la balise noindex ?

Elle se trouve à trois endroits possibles. Dans le <head> du code HTML de la page (la forme la plus courante), dans un en-tête HTTP X-Robots-Tag envoyé par le serveur (invisible sans outil de développement), ou dans le fichier robots.txt à la racine du site — mais dans ce dernier cas, il s'agit d'une directive Disallow et non d'un véritable noindex. Pour la repérer sur une page précise, l'inspection d'URL de la Search Console reste le moyen le plus fiable.

Que signifie « noindex, nofollow » ?

Ce sont deux directives combinées. noindex demande aux moteurs de recherche de ne pas référencer la page dans leurs résultats. nofollow leur demande de ne pas suivre les liens qu'elle contient. Les deux peuvent s'utiliser séparément, mais on les associe souvent pour retirer complètement une page de l'écosystème d'exploration.

Ce que je vérifie désormais systématiquement

Trois contrôles, à chaque mise en production. Ça prend dix minutes, ça m'a évité au moins quatre incidents depuis.

D'abord, un grep sur le mot « noindex » dans tout le dépôt avant de déployer. L'outil met deux secondes. Il attrape les balises oubliées dans un template.

Ensuite, l'inspection d'URL sur les cinq pages les plus stratégiques du site, une fois par mois. Pas toutes les pages — les cinq qui rapportent. Celles dont la disparition vous ferait vraiment mal.

Et enfin, un suivi du nombre de pages indexées dans la Search Console. Une baisse brutale sur une semaine, sans raison apparente, c'est presque toujours une balise qui s'est glissée quelque part. Le signal arrive avant que le trafic ne s'effondre — si on le regarde.

Le vrai enseignement de cette histoire, celui que je répète à chaque audit : une page accessible à vos visiteurs n'est pas une page visible par Google. Ce sont deux mondes séparés. Et la frontière entre les deux tient parfois à une seule ligne de code que personne n'a relue.