URL marquée "noindex" dans Search Console : corriger ou laisser

« URL marquée "noindex" » signifie que Google a exploré la page, y a trouvé une instruction lui demandant de ne pas l'indexer, et l'a suivie. Sur la plupart des sites, cet état est justifié pour la majorité des URL concernées : les pages de commande, de compte et de résultats de recherche interne sont faites pour rester hors de Google. Il devient un problème lorsqu'une page que vous voulez voir dans les résultats figure dans la liste, ou lorsque votre propre sitemap XML envoie une page qui demande par ailleurs à Google de ne pas l'indexer.

Ce que signifie cet état, et ses anciens libellés

La documentation de Google sur le Rapport sur l'indexation des pages (consultée en octobre 2026) cite « URL marquée "noindex" » (en anglais : « URL marked 'noindex' ») parmi les raisons pour lesquelles une page n'est pas indexée, et la décrit en une ligne : « Lorsque Google a essayé d'indexer la page, il a rencontré une directive "noindex" et ne l'a donc pas indexée. » La même documentation précise que si vous ne voulez pas que la page soit indexée, il n'y a rien à changer ; dans le cas contraire, supprimez la directive.

La directive peut parvenir à Google par 2 voies :

• Dans le HTML, sous forme de balise meta robots : <meta name="robots" content="noindex">, ou d'une version réservée à Google : <meta name="googlebot" content="noindex">.
• Dans la réponse HTTP, sous forme d'en-tête : X-Robots-Tag: noindex. Google accepte aussi la valeur none, qu'il traite comme noindex, nofollow. L'en-tête peut viser un seul robot, comme dans X-Robots-Tag: googlebot: noindex.

Google ne peut obéir qu'à une règle qu'il peut lire. Une page bloquée par robots.txt n'est jamais récupérée : un noindex placé dessus n'est donc jamais vu. Il s'agit alors d'un autre état, traité dans le guide robots.txt et accès à l'exploration.

Si vous avez cherché « Exclue par la balise "noindex" », vous avez affaire au même état sous son ancien nom. Avant que Google ne réorganise le rapport en 2022, il figurait dans un groupe « Excluded » sous le libellé « Exclue par la balise "noindex" », et une erreur distincte, « URL envoyée désignée comme "noindex" », concernait les pages en noindex envoyées par un sitemap. La page d'aide de Google sur la nouvelle catégorisation des problèmes indique que chaque erreur portant sur une URL « envoyée » a été fusionnée avec son équivalent exclu en un seul problème.

Est-ce un problème ? Corriger, laisser ou surveiller

Déterminez à quoi sert chaque URL avant de modifier quoi que ce soit.

flowchart TD
    A["URL marquée 'noindex'"] --> B{"Cette page doit-elle apparaître dans Google ?"}
    B -->|non| C{"Est-elle listée dans votre sitemap XML ?"}
    C -->|non| D["La laisser. L'état est justifié."]
    C -->|oui| E["La retirer du sitemap"]
    B -->|oui| F{"Le test en ligne affiche-t-il encore noindex ?"}
    F -->|non| G["Déjà corrigé. Demander une indexation et attendre une nouvelle exploration."]
    F -->|oui| H{"Où a-t-il été détecté ?"}
    H -->|balise meta robots| I["Corriger le template, le réglage du CMS ou l'extension"]
    H -->|en-tête X-Robots-Tag| J["Corriger la règle du serveur, du CDN ou de l'hébergeur"]

D'où vient le noindex

1. Il a été placé volontairement. Les pages sans intérêt pour la recherche, les pages privées et les vues en double sont mises en noindex à dessein. Sur un site sain, la plupart des URL de ce rapport relèvent de ce cas.

2. Un réglage de préproduction a survécu à la mise en ligne. Un site construit derrière un noindex le conserve lorsque le template, le fichier d'environnement ou l'option du thème arrive en production sans modification. Les pages disparaissent de Google au fil des nouvelles explorations, sans que les visiteurs ne remarquent rien.

3. Un interrupteur global du CMS. WordPress propose une case à cocher dans Réglages > Lecture : « Demander aux moteurs de recherche de ne pas indexer ce site ». La documentation de WordPress indique que depuis la version 5.3, cette option ajoute une balise meta robots noindex,nofollow dans le head des pages du site ; les versions actuelles l'écrivent avec des apostrophes : <meta name='robots' content='noindex, nofollow' />. Une case restée cochée sur une copie de préproduction et transportée en production lors d'un import de base de données suffit.

4. Les réglages par défaut des extensions et des thèmes. Les extensions SEO et les thèmes gèrent souvent l'indexation par type de contenu : archives de tags, archives d'auteurs, pages de fichiers joints, listes paginées. Une mise à jour, un import de réglages ou un changement de valeur par défaut peut basculer tout un groupe d'URL en noindex d'un coup : c'est pourquoi le nombre a tendance à bondir plutôt qu'à progresser lentement.

5. Un en-tête X-Robots-Tag que personne ne voit. L'en-tête est défini au niveau du serveur web, du CDN ou de la plateforme d'hébergement : il n'apparaît donc jamais dans le code source de la page. Sources typiques : une règle d'en-tête écrite pour les PDF qui s'applique à tous les chemins, une règle de préproduction restée active sur l'hôte de production, ou une plateforme d'hébergement qui ajoute automatiquement X-Robots-Tag: noindex aux déploiements de prévisualisation. Si le code source de la page est propre et que Search Console signale toujours un noindex, vérifiez les en-têtes.

6. Un JavaScript qui tente de le retirer. Certaines applications monopages livrent noindex dans le HTML initial et le retirent en JavaScript après le chargement. La documentation de Google sur le SEO JavaScript avertit que lorsque Google voit un noindex, il peut ne pas effectuer le rendu ni exécuter le JavaScript : la suppression risque donc de ne jamais s'exécuter. Notre guide sur le rendu JavaScript traite l'écart plus général entre HTML servi et HTML rendu.

Le cas grave : des pages en noindex envoyées par votre sitemap

Un sitemap liste les URL que vous voulez voir indexées ; un noindex sur l'une d'elles dit le contraire. Google suit le noindex, et la contradiction révèle que vos propres systèmes ne sont pas d'accord sur la page.

Sur 29 sites externes dont SEOReport a récupéré les pages du sitemap entre mai et octobre 2026, 4 (14 %) listaient dans leur propre sitemap XML au moins une page marquée noindex. Le schéma observé : des pages de panier, de commande et de compte laissées dans le sitemap. Les pages d'accueil de ces mêmes audits étaient saines : aucune des 45 pages d'accueil externes auditées par SEOReport entre mai et octobre 2026 ne portait de noindex, ni dans une balise meta ni dans un en-tête X-Robots-Tag. Les problèmes de noindex qui méritent d'être trouvés se situent plus profondément dans le site.

Pour isoler ce sous-ensemble dans Search Console, ouvrez le Rapport sur l'indexation des pages et faites passer le filtre situé au-dessus du graphique de « Toutes les pages connues » à « Toutes les pages envoyées ». Une URL est considérée comme envoyée si un sitemap que vous avez envoyé, ou indiqué dans robots.txt, la contient, même si Google l'a aussi trouvée par des liens. Chaque URL qui reste sous « URL marquée "noindex" » avec ce filtre appelle une décision : retirer le noindex, ou retirer l'URL du sitemap. Notre guide des sitemaps XML explique comment limiter un sitemap généré aux URL indexables.

La même contradiction apparaît lorsqu'une balise canonique ou un lien de version linguistique pointe vers une page en noindex. L'analyse des conflits d'indexabilité traite ces combinaisons à l'échelle d'un site entier.

Comment confirmer la cause en jeu

Commencez par l'outil d'inspection d'URL. Dans la section consacrée à l'indexation des pages, le champ « Indexation autorisée ? » donne la raison, par exemple « "noindex" détecté dans la balise meta "robots" » ou « "noindex" détecté dans l'en-tête HTTP "X-Robots-Tag" ». Cette seule ligne vous indique s'il faut chercher dans le HTML ou dans la configuration du serveur.

Vérifiez la date. Le résultat par défaut correspond à la dernière version explorée par Google, et le champ « Dernière exploration » indique quand elle date. Si vous avez modifié la page après cette date, le résultat décrit l'ancienne page.

Lancez le test en ligne. Sélectionnez « Tester l'URL en ligne », puis « Afficher la page testée ». Le test en ligne montre le HTML et les en-têtes de réponse HTTP que Google reçoit maintenant, y compris des en-têtes que votre navigateur n'affiche jamais. Il ne vérifie ni les sitemaps ni les pages de provenance ; le résultat indexé couvre ces points.

Reproduisez-le depuis un terminal. Ces 2 commandes affichent l'en-tête et la balise meta de n'importe quelle URL. Le second motif accepte les guillemets simples et doubles, car WordPress écrit sa balise avec des apostrophes :

# Response headers only: look for x-robots-tag
curl -s -D - -o /dev/null https://www.example.com/pricing/ | grep -i "x-robots-tag"

# Robots meta tags in the HTML the server returns
curl -s https://www.example.com/pricing/ | grep -i -o -E "<meta[^>]*name=[\"']?(robots|googlebot)[\"' >][^>]*>"

Si aucune des deux commandes ne renvoie rien, le serveur n'a envoyé aucun noindex à curl. Si Search Console persiste, relancez les deux commandes en ajoutant -A "Googlebot" après curl -s : certains serveurs et CDN répondent différemment aux user-agents des robots d'exploration.

Lisez les résultats ensemble :

Corriger selon la cause, puis vérifier

• Interrupteur du CMS : décochez « Demander aux moteurs de recherche de ne pas indexer ce site » sur le site de production, et revérifiez-le après chaque copie de la préproduction vers la production.
• Réglage d'extension ou de thème : rendez de nouveau indexable le type de contenu ou l'archive, puis vérifiez sur 1 URL d'exemple que la balise a disparu du HTML renvoyé par le serveur.
• Template ou variable d'environnement : faites de la production le cas par défaut et du noindex l'exception, pour qu'un réglage manquant ne puisse jamais masquer le site en ligne.
• En-tête X-Robots-Tag : trouvez la règle au niveau du serveur web, du CDN ou de la plateforme d'hébergement et limitez-la aux chemins qui en ont besoin, comme les noms d'hôte de préproduction ou les fichiers PDF que vous ne voulez pas voir indexés.
• Suppression par JavaScript : retirez le noindex du HTML initial des pages que vous voulez voir indexées.
• Page volontairement exclue mais présente dans le sitemap : gardez le noindex et retirez l'URL du sitemap.

N'ajoutez pas de directive Disallow dans robots.txt pour une page que vous voulez faire disparaître. Elle masque le noindex à Google, et la page peut toujours apparaître dans les résultats de recherche.

Vérifiez ensuite dans cet ordre. D'abord, relancez le test en ligne et confirmez que « Indexation autorisée ? » affiche désormais « Oui ». Ensuite, utilisez « Demander une indexation » pour vos pages corrigées les plus importantes ; Search Console limite le nombre de ces demandes par jour, et la documentation de Google sur l'inspection d'URL indique que l'indexation prend généralement environ une journée, mais peut prendre beaucoup plus longtemps. Enfin, sélectionnez « Valider la correction » sur le problème dans le Rapport sur l'indexation des pages. La documentation de Google indique que la validation prend généralement jusqu'à 2 semaines environ, parfois beaucoup plus.

Une précaution : la validation revérifie les URL listées sous le problème, et Google interrompt une validation dès qu'il trouve une occurrence restante. Si la liste contient aussi des pages que vous laissez volontairement en noindex, la validation n'aboutira pas. Dans ce cas, suivez les URL corrigées une par une dans l'outil d'inspection d'URL et regardez-les passer à l'état indexé.

Search Console montre quelles URL Google a exclues et, 1 URL à la fois, où il a trouvé la règle. Un diagnostic SEOReport complet lit les pages listées dans votre sitemap et nomme chacune de celles dont la balise meta robots indique noindex, en précisant le nombre de pages examinées. Sur votre page d'accueil, il lit à la fois la balise meta et l'en-tête X-Robots-Tag, et vérifie si sa balise canonique pointe vers une page en noindex ; il signale aussi les liens de version linguistique qui pointent vers des pages en noindex. Vous obtenez ainsi 1 seule liste à trier entre noindex voulus et accidentels. Vérifier URL par URL pose le même problème d'échelle que celui décrit dans pourquoi une seule session d'IA ne peut pas auditer tout un site.

Questions fréquentes

Le noindex empêche-t-il Google d'explorer la page ?

Non. Google doit explorer la page pour lire la règle. Empêcher Google de récupérer une section relève de robots.txt, et cela ne doit pas être combiné à un noindex que Google doit pouvoir voir.

Combien de temps faut-il pour qu'une page revienne après le retrait du noindex ?

Rien ne change tant que Google n'a pas réexploré la page, et sa documentation indique qu'une page moins importante peut attendre des mois. « Demander une indexation » sollicite une nouvelle exploration pour 1 URL, mais ne garantit pas son indexation.

Pourquoi Search Console signale-t-il un noindex alors que le code source de ma page n'en contient pas ?

En général pour 1 de ces 3 raisons : le résultat provient d'une exploration antérieure à votre correction, le noindex arrive dans un en-tête X-Robots-Tag que le code source n'affiche pas, ou votre serveur ou CDN répond différemment au robot de Google qu'à votre navigateur. Le test en ligne tranche la question, car il montre le HTML et les en-têtes que Google reçoit maintenant.

Faut-il mettre en noindex les archives de tags, de catégories et d'auteurs ?

Seulement si elles n'apportent à l'internaute rien que les articles eux-mêmes n'offrent déjà. Décidez une fois par type d'archive, appliquez cette décision par 1 seul réglage, et gardez les archives en noindex hors du sitemap.