robots.txt, la balise noindex et rel="canonical" servent trois objectifs différents. Les confondre mène à des erreurs qui, au mieux, ne font rien, et au pire produisent l'inverse de l'effet recherché. Voici comment les distinguer une bonne fois pour toutes.
robots.txt : contrôler le crawl, pas l'indexation
Le fichier robots.txt dit aux robots quelles URL ils ont le droit de visiter. C'est tout. Il agit sur le crawl, jamais directement sur l'index.
Voici le piège classique. Vous voulez retirer une page de Google, alors vous la bloquez dans robots.txt :
User-agent: *
Disallow: /page-a-cacher/Résultat : Google ne peut plus visiter la page… mais il peut toujours l'indexer s'il la connaît par ailleurs (un lien externe, par exemple). Vous obtenez alors le pire des deux mondes : la page reste dans l'index, mais comme Google ne peut plus la lire, elle apparaît avec la mention « Aucune information disponible » et un titre pioché au hasard. Et surtout : Google ne verra jamais votre balise noindex, puisqu'il n'a pas le droit de charger la page pour la lire.
Pour désindexer une page, il ne faut pas la bloquer dans robots.txt. Il faut au contraire laisser Google la crawler, pour qu'il découvre la balise noindex qu'elle contient.
noindex : retirer une page de l'index
La balise noindex est le vrai outil pour dire « ne mets pas cette page dans tes résultats ». Elle se place dans le <head> :
<meta name="robots" content="noindex, follow">Le follow précise que Google peut quand même suivre les liens de la page (utile pour laisser circuler le maillage). La combinaison noindex, follow est idéale pour les pages que vous voulez garder crawlables et utiles à la navigation, mais absentes des résultats : pages de filtres, archives, résultats de recherche interne, pages générées à faible valeur propre.
Point de vigilance déjà évoqué mais capital : un noindex doit être déterministe. S'il est calculé dynamiquement à partir d'une condition qui peut échouer (un appel API, une requête base de données lente), une panne transitoire peut le poser sur des pages valides et les faire disparaître de l'index. Ce qui se remet en place lentement.
rel=canonical : désigner la version de référence
La balise canonique ne bloque ni ne retire rien. Elle dit à Google : « parmi plusieurs pages similaires, voici celle qui fait référence ». Google consolide alors les signaux (liens, autorité) vers l'URL canonique.
<link rel="canonical" href="https://exemple.fr/page-de-reference">Cas d'usage typiques : une même fiche accessible via plusieurs URL (avec ou sans paramètres de tri), une version imprimable, du contenu syndiqué. La canonique évite que Google traite ces variantes comme du contenu dupliqué et disperse votre autorité.
Attention : la canonique est un signal, pas un ordre. Google peut choisir d'ignorer votre canonique s'il juge qu'une autre page est plus pertinente. Elle fonctionne mieux quand les pages sont réellement quasi-identiques.
Tableau de décision
Pour choisir le bon outil, posez-vous une seule question — que voulez-vous obtenir ?
- « Cette page ne doit pas apparaître dans Google » →
noindex(et surtout pas de blocage robots.txt). - « Ces pages sont des doublons, consolide-les » →
rel="canonical"vers la version de référence. - « Je veux économiser du budget de crawl sur des URL sans intérêt » →
robots.txt, à condition que ces pages ne soient pas déjà indexées et que vous ne cherchiez pas à les désindexer. - « Cette page contient des données sensibles » → ni l'un ni l'autre suffisent seuls ; il faut une vraie protection (authentification), car robots.txt est public et noindex n'empêche pas l'accès direct.
La plupart des erreurs d'indexation viennent d'un mauvais appariement outil/objectif. En gardant en tête que robots.txt agit sur le crawl, noindex sur l'index et canonical sur la consolidation, on évite l'immense majorité des pièges.