Apprenez ce que robots.txt contrôle réellement, pourquoi bloquer le crawl n’équivaut pas à demander une désindexation et comment écrire des règles simples sans masquer des ressources utiles.
Le fichier robots.txt est court, public et capable de provoquer des erreurs très larges.
Une seule règle peut interdire l’exploration d’un répertoire entier. À l’inverse, supprimer une directive ne signifie pas qu’une page sera immédiatement indexée.
Pour bien l’utiliser, il faut commencer par distinguer crawl, indexation et contrôle d’accès.
Pour un site :
https://example.com/le fichier se trouve généralement à la racine :
https://example.com/robots.txtIl est volontairement public. Toute personne peut le consulter.
Cela suffit à comprendre pourquoi on ne doit jamais y inscrire une liste de dossiers « secrets » en pensant les protéger.
Un exemple simple :
User-agent: *
Disallow: /admin-temporaire/User-agent désigne le robot concerné. * représente ici tous les robots qui appliquent ces règles.
Disallow indique un chemin que l’on demande de ne pas explorer.
On peut aussi déclarer :
Sitemap: https://example.com/sitemap.xmlLe Générateur robots.txt aide à produire une syntaxe propre, mais il faut d’abord comprendre ce que l’on souhaite réellement bloquer.
noindexC’est la distinction essentielle.
Si un robot n’explore pas une page, il ne peut pas forcément lire les directives présentes dans cette page.
Une URL bloquée dans robots.txt peut malgré tout être connue grâce à des liens externes ou internes. Selon le contexte, elle peut encore apparaître sous une forme limitée dans un index.
Si votre objectif est qu’une page accessible soit explorée mais ne soit pas indexée, la stratégie appropriée est généralement différente, par exemple une directive noindex lisible par le robot.
Il ne faut donc pas mélanger :
robots.txt → contrôler l’exploration
noindex → demander de ne pas indexer une page accessible au robotSi /factures-privees/ contient des données sensibles, écrire :
Disallow: /factures-privees/ne protège rien.
L’URL peut toujours être ouverte par un navigateur si le serveur l’autorise.
Pour protéger un contenu, utilisez :
Le SEO et la sécurité répondent ici à deux problèmes différents.
Exemple dangereux :
User-agent: *
Disallow: /Le / représente la racine. Cette règle demande donc de ne rien explorer sur le site.
Elle peut être pertinente sur un environnement temporaire dans certains contextes, mais constitue une erreur grave si elle arrive en production sans intention.
Avant publication, relisez les règles comme si vous étiez le robot : quel chemin exact correspond à cette directive ?
Les moteurs modernes peuvent avoir besoin de CSS, JavaScript et images pour interpréter correctement certaines pages.
Bloquer systématiquement :
/assets/
/scripts/
/styles/peut donc être contre-productif si ces fichiers sont nécessaires au rendu.
L’objectif n’est pas de réduire le nombre de fichiers visités à tout prix, mais d’éviter l’exploration inutile tout en laissant le contenu principal interprétable.
Allow ?Une règle Allow peut préciser une exception dans une zone plus largement interdite selon le comportement des robots concernés.
Exemple conceptuel :
Disallow: /private/
Allow: /private/public-guide.htmlLes règles de correspondance méritent d’être testées plutôt que devinées, surtout lorsqu’elles deviennent complexes.
Dans beaucoup de petits sites, un fichier simple est préférable à un ensemble de règles sophistiquées difficiles à maintenir.
Une boutique ou une page de recherche peut générer :
/catalogue?sort=price
/catalogue?sort=name
/catalogue?color=blue
/catalogue?page=2Bloquer toutes les variantes par robots.txt n’est pas automatiquement la bonne réponse.
Il faut d’abord comprendre :
Le guide Créer des URLs propres : slugs, paramètres et normalisation développe cette logique.
Le sitemap indique principalement les URLs que vous souhaitez signaler comme importantes ou disponibles à l’exploration.
robots.txt indique des restrictions d’exploration.
Mettre une URL dans un sitemap tout en la bloquant dans robots.txt envoie donc des signaux contradictoires.
Essayez de faire correspondre votre architecture publique à ce que vos fichiers techniques annoncent.
Supposons un moteur de recherche interne générant :
/recherche?q=pdf
/recherche?q=audio
/recherche?q=csvSi ces pages n’ont pas vocation à être indexées et peuvent créer un espace quasi infini de requêtes, il faut définir une stratégie globale : liens internes, directives d’indexation, éventuelles règles de crawl et comportement de la page.
Une seule ligne dans robots.txt n’est pas toujours suffisante pour résoudre toute l’architecture.
Avant de modifier votre fichier :
Disallow: / sans intention explicite ;Vous pouvez utiliser le Validateur d’URL pour contrôler la structure des adresses manipulées et le Générateur robots.txt pour préparer le fichier.
Il est utile lorsque vous voulez réduire l’exploration de zones qui n’ont pas vocation à être parcourues par des robots, par exemple certaines interfaces techniques, espaces de recherche ou variantes générées en masse.
Il est moins utile comme réponse automatique à chaque problème SEO.
Commencez toujours par poser la question :
Est-ce que je veux empêcher l’accès, l’exploration ou l’indexation ?
Ces trois objectifs nécessitent des mécanismes différents.
Collection
3 / 7
Comprenez les bases du SEO technique : exploration, indexation, URL canonique, métadonnées, données structurées, performance et maillage interne, sans confondre optimisation et promesse de classement.
Passez en revue URL, indexation, title, meta description, canonical, robots, données structurées, images, maillage interne et responsive avant de mettre une page en ligne.
Comprenez le rôle des principales métadonnées d’une page Web, ce qu’elles influencent réellement et comment éviter les titres, descriptions, canonical et balises sociales incohérents.