Robots.txt, noindex, canonical : choisir le bon levier

Robots.txt, indexation et canonical : trois problèmes différents

La confusion vient souvent d’un raccourci : « empêcher Google de voir une URL » serait équivalent à « empêcher cette URL d’apparaître dans Google ». Ce n’est pas le cas. Une stratégie SEO propre sépare au moins trois questions : un robot peut-il demander une ressource ; le moteur doit-il conserver cette ressource dans son index et l’afficher dans ses résultats ; parmi plusieurs URL identiques ou très semblables, laquelle doit représenter le contenu ? Robots.txt répond principalement à la première. La directive noindex répond à la deuxième. La balise rel=canonical répond à la troisième.

Cette distinction est structurante pour la performance SEO. Bloquer une zone très volumineuse peut réduire des requêtes d’exploration inutiles. Désindexer une page de confirmation de commande évite qu’elle soit proposée dans les résultats. Canonicaliser des URL de tri ou de suivi de campagne aide le moteur à choisir une version préférée et à regrouper les signaux associés aux doublons. Employer le mauvais outil peut au contraire produire une URL toujours visible sans contenu, une directive noindex que le robot ne peut jamais lire, ou une page utile retirée des résultats alors qu’elle devait seulement être dédoublonnée. Google rappelle explicitement que l’exploration et l’indexation sont deux opérations différentes. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/googlebot))

Il faut aussi éviter de transformer ces mécanismes en promesse de sécurité. Le protocole Robots Exclusion Protocol, normalisé par la RFC 9309 en septembre 2022, exprime des règles d’accès destinées aux crawlers ; il ne constitue pas un mécanisme d’autorisation. Le fichier expose en outre les chemins qu’il liste. Une zone réellement privée doit être protégée par un contrôle d’accès adapté, par exemple une authentification HTTP, et non par une simple règle robots.txt. ([rfc-editor.org](https://www.rfc-editor.org/rfc/rfc9309.html))

Robots.txt : un levier de crawl, non un bouton de désindexation

Le fichier robots.txt est servi à la racine d’un hôte : il est lié au protocole, au nom d’hôte et au port concernés. Il contient notamment des groupes associés à des user-agents, avec des règles allow et disallow. Chez Google, les chemins sont sensibles à la casse, et un disallow vide n’interdit rien. Google prend aussi en charge la déclaration d’un sitemap dans ce fichier, mais pas la directive crawl-delay. ([developers.google.com](https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec?hl=fr))

Son effet attendu est simple : demander à un crawler compatible de ne pas récupérer certains chemins. C’est donc un bon levier lorsqu’un site génère de nombreuses URL sans valeur de recherche, par exemple des filtres techniques, des espaces de prévisualisation, des paramètres internes ou des sections d’administration déjà protégées. Il peut également contribuer à ménager l’infrastructure lorsqu’un grand volume d’URL peu utile serait autrement exploré. Google recommande de ne bloquer que des ressources non critiques pour comprendre une page, car des ressources nécessaires au rendu ou à l’interprétation du contenu peuvent affecter l’indexation. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors?utm_source=openai))

Le compromis est majeur : si Googlebot ne peut pas récupérer le document, il ne peut pas lire une balise meta robots, un en-tête X-Robots-Tag ni une canonical contenus dans sa réponse. Google peut néanmoins connaître l’URL par des liens, des sitemaps ou d’autres signaux, puis l’afficher dans les résultats sans en avoir exploré le contenu ni généré d’extrait. La documentation Google indique précisément qu’une URL interdite dans robots.txt peut encore être indexée sans son contenu. C’est pourquoi robots.txt ne doit pas être utilisé pour obtenir une désindexation fiable. ([developers.google.com](https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec?hl=fr))

La disponibilité du fichier mérite elle aussi une surveillance. Pour Google, une réponse 4xx, à l’exception de 429, est traitée comme l’absence d’un robots.txt valide et l’exploration se poursuit sans restriction. En cas d’erreur serveur, Google cesse d’explorer pendant les 12 premières heures, peut utiliser une version précédemment récupérée pendant 30 jours, puis peut reprendre comme s’il n’y avait pas de restriction si le site reste accessible. Google met généralement robots.txt en cache pendant 24 heures et ignore le contenu au-delà de 500 kibioctets. Une règle de production ne doit donc pas reposer sur l’idée qu’une modification sera appliquée instantanément. ([developers.google.com](https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec?hl=fr))

Noindex : le bon levier pour sortir une page des résultats

La directive noindex demande aux moteurs de recherche de ne pas afficher une page, un média ou une ressource dans les résultats. Sur une page HTML, elle peut être envoyée dans une balise meta robots, par exemple sous la forme textuelle <meta name="robots" content="noindex">. Pour un PDF, une image, une vidéo ou toute autre ressource non HTML, l’équivalent adapté est l’en-tête HTTP X-Robots-Tag: noindex. Google accepte aussi cet en-tête pour les documents HTML. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag?hl=fr))

La condition décisive est parfois oubliée : le crawler doit pouvoir accéder à la réponse pour voir noindex. Google précise qu’il doit explorer la page pour lire les balises meta et les en-têtes HTTP. Si une règle robots.txt bloque l’URL, la directive noindex devient invisible pour Googlebot. Le montage « Disallow dans robots.txt plus noindex dans la page » est donc contradictoire quand l’objectif est de retirer la page de Google : il faut autoriser l’exploration, servir noindex, puis attendre une nouvelle visite du robot. Selon Google, ce nouveau passage peut prendre des mois pour une page peu importante ; l’outil d’inspection d’URL permet de demander une nouvelle exploration. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/block-indexing?rd=1&visit_id=639173061565117540-1865991663))

Noindex ne signifie pas nofollow. La première directive concerne la présence de la ressource dans les résultats. La seconde demande de ne pas suivre les liens présents sur la page. La combinaison none équivaut à noindex et nofollow chez Google. Dans une logique SEO, ajouter nofollow de manière systématique à une page noindex est rarement nécessaire : cela peut priver le moteur d’un chemin de découverte vers des pages importantes, alors que noindex suffit lorsque le seul but est d’écarter la page des résultats. Google précise également que plusieurs règles contradictoires sont interprétées selon la restriction la plus forte. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag?utm_source=openai))

D’autres directives ne règlent ni le crawl ni l’indexation au sens strict, mais la présentation dans les résultats. Nosnippet interdit l’extrait textuel et l’aperçu vidéo ; max-snippet limite la longueur d’extrait ; noimageindex agit sur l’indexation des images d’une page. Elles répondent à des objectifs d’affichage, pas à un besoin de désindexer une URL. Les comportements peuvent varier selon les moteurs : Google le signale explicitement pour les règles meta robots. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag?hl=fr&utm_source=openai))

Canonical : choisir une représentante, pas interdire une URL

La canonicalisation traite les doublons ou les pages très similaires. Une annotation rel=canonical indique au moteur l’URL que l’éditeur préfère voir représenter le contenu. Google classe rel=canonical parmi les signaux forts de canonicalisation, au même niveau que les redirections dans sa hiérarchie, tandis que la présence dans un sitemap est un signal faible. Ces signaux peuvent se renforcer lorsqu’ils sont cohérents, mais le moteur conserve la décision finale sur l’URL canonique retenue. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=fr&utm_source=openai))

Une canonical ne bloque donc pas le crawl par elle-même et n’est pas un ordre de suppression. Elle sert surtout à consolider les signaux des variantes, notamment les liens externes, vers une URL préférée. Cas classique : une même fiche produit est accessible par une URL propre, une URL avec paramètres de campagne et une URL issue de filtres. Si le contenu reste identique ou très proche et que les variantes doivent continuer à fonctionner pour les utilisateurs, une canonical des variantes vers la fiche propre est généralement plus appropriée que noindex ou robots.txt. Google recommande d’ailleurs de ne pas utiliser robots.txt pour la canonicalisation. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?utm_source=openai))

Lorsque l’ancienne URL doit disparaître au profit d’une nouvelle destination et que la redirection convient aussi aux utilisateurs, une redirection permanente est un meilleur signal opérationnel : elle envoie les visiteurs et les robots vers la destination. Google la présente comme un signal fort et recommande les redirections HTTP côté serveur pour l’effet le plus rapide. À l’inverse, une canonical est adaptée quand plusieurs URL doivent rester accessibles, par exemple des variantes techniques ou de tracking. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=fr&utm_source=openai))

La cohérence compte plus que l’empilement aveugle. Il faut éviter d’indiquer une URL dans le sitemap, une autre dans rel=canonical et une troisième dans les liens internes. Google conseille aussi une canonical auto-référencée sur l’URL préférée et des liens internes pointant vers cette même version. Pour les fichiers non HTML, l’annotation canonique peut être fournie par un en-tête HTTP Link avec rel=canonical. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?utm_source=openai))

Scénarios concrets : quel levier agit sur quoi ?

Scénario 1 : une page de résultat interne est utile à l’utilisateur connecté, mais ne doit pas être trouvée dans Google. Si la page reste publiquement accessible, noindex est le choix direct. Google peut la récupérer, lire l’instruction et retirer sa possibilité d’apparition. Si l’URL contient des liens utiles vers des produits ou des catégories, conserver le suivi des liens est souvent plus logique que lui ajouter nofollow. En revanche, si la page expose des données personnelles, noindex ne suffit pas : il faut supprimer l’accès public par authentification ou contrôle d’accès. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/block-indexing?rd=1&visit_id=639173061565117540-1865991663))

Scénario 2 : un catalogue crée des millions de combinaisons de filtres. Il faut d’abord décider lesquelles ont une demande de recherche, un contenu distinct et une vraie utilité. Les combinaisons sans valeur peuvent être limitées côté produit et, lorsque l’enjeu est surtout d’éviter des requêtes de crawl inutiles, bloquées par robots.txt. Mais si certaines de ces URL sont déjà indexées et doivent disparaître des résultats, un blocage robots.txt seul est insuffisant : il faut temporairement laisser Google les explorer avec noindex, ou choisir une autre réponse serveur adaptée au cas. Le compromis est clair : noindex obtient la désindexation mais suppose des visites de crawl ; robots.txt évite ces visites mais ne garantit pas le retrait des URL connues. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/block-indexing?rd=1&visit_id=639173061565117540-1865991663))

Scénario 3 : les paramètres de campagne affichent exactement la même page que l’URL propre. La priorité est de consolider, pas de cacher. Une canonical vers l’URL propre, des liens internes cohérents et l’URL propre dans le sitemap alignent les signaux. Bloquer les paramètres dans robots.txt empêcherait Google de lire la canonical sur les variantes ; appliquer noindex aux variantes risquerait de traiter un problème de doublons comme une exclusion complète. Google déconseille précisément noindex pour empêcher la sélection d’une page canonique au sein d’un même site. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=fr&utm_source=openai))

Scénario 4 : un document PDF doit rester disponible au téléchargement, mais pas dans les résultats. Une meta robots ne peut pas être placée dans un PDF. L’en-tête X-Robots-Tag: noindex est le levier approprié, à condition que le fichier reste accessible au crawler. Si le besoin est plutôt de désigner une version HTML ou PDF préférée parmi des documents équivalents, l’en-tête Link avec rel=canonical correspond au problème de déduplication. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag?hl=fr))

Scénario 5 : une ancienne page a été remplacée définitivement. Une redirection permanente vers la remplaçante est préférable à une canonical si l’ancienne URL ne doit plus servir de point d’entrée. Elle améliore aussi le parcours utilisateur, car la personne qui visite l’ancien lien arrive directement sur la page de remplacement. La canonical serait utile si l’ancienne variante devait demeurer consultable tout en cédant la représentation dans les résultats à la page préférée. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=fr&utm_source=openai))

Les erreurs d’interprétation qui coûtent le plus cher

« Disallow veut dire désindexé » : faux. Le blocage porte sur l’exploration ; une URL connue peut encore apparaître sans extrait. ([developers.google.com](https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec?hl=fr))
« Je peux protéger une information confidentielle avec robots.txt » : faux. Le protocole n’est pas une autorisation d’accès et les chemins renseignés sont visibles publiquement. ([rfc-editor.org](https://www.rfc-editor.org/rfc/rfc9309.html))
« Noindex et robots.txt se renforcent toujours » : faux. Si robots.txt empêche le crawl, il peut empêcher la lecture de noindex. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/block-indexing?rd=1&visit_id=639173061565117540-1865991663))
« Canonical supprime les doublons » : imprécis. Elle exprime une préférence de version représentative et aide à consolider les signaux ; ce n’est pas une interdiction de crawl ou un ordre absolu de retrait. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=fr&utm_source=openai))
« Le sitemap suffit à imposer une canonical » : faux. Google le qualifie de signal faible ; il doit être cohérent avec les autres signaux. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=fr&utm_source=openai))
« Une erreur sur robots.txt bloque nécessairement le site » : faux. Chez Google, une réponse 4xx, hors 429, peut au contraire être interprétée comme l’absence de restriction. ([developers.google.com](https://developers.google.com/crawling/docs/robots-txt/robots-txt-spec?hl=fr))

Tableau décisionnel simple : partir de l’objectif

Objectif : réduire les requêtes de crawl sur des URL peu importantes. Choisir robots.txt. Accepter que les URL déjà connues puissent parfois rester visibles dans les résultats.
Objectif : empêcher une page HTML publique d’apparaître dans les résultats. Choisir meta robots noindex. Ne pas bloquer l’URL dans robots.txt tant que Google doit lire la directive.
Objectif : empêcher un PDF, une image ou une vidéo d’apparaître dans les résultats. Choisir X-Robots-Tag: noindex dans la réponse HTTP. Laisser le crawler accéder au fichier.
Objectif : réunir des URL identiques ou très proches derrière une version préférée. Choisir rel=canonical, des liens internes vers la version préférée et un sitemap cohérent. Ne pas remplacer ce choix par noindex ou robots.txt.
Objectif : retirer définitivement une ancienne URL et envoyer les visiteurs vers sa remplaçante. Choisir une redirection permanente côté serveur vers la destination pertinente.
Objectif : ne plus afficher d’extrait sans retirer nécessairement la page. Choisir nosnippet ou une règle de prévisualisation adaptée, en comprenant que cela agit sur la présentation et non sur l’accès de crawl.
Objectif : empêcher toute consultation par les robots et les utilisateurs non autorisés. Choisir une authentification ou un contrôle d’accès. Robots.txt peut compléter la gestion de crawl, mais ne doit pas être la protection principale. ([developers.google.com](https://developers.google.com/search/docs/crawling-indexing/googlebot))

La règle pratique est donc de nommer le problème avant de choisir la directive. Si le problème est le volume de requêtes, penser crawl et robots.txt. S’il s’agit de la présence dans les résultats, penser noindex et accessibilité au crawler. S’il s’agit de doublons, penser canonicalisation et cohérence des signaux. Cette séparation évite de sacrifier l’exploration utile, l’indexation souhaitée ou la consolidation des signaux au profit d’une solution qui ne répond pas réellement à l’objectif.