Le fichier robots.txt indique aux robots d’exploration quelles zones d’un site ils peuvent visiter ou doivent éviter. Il ne supprime pas une page des résultats de recherche, ne protège pas un contenu confidentiel et ne remplace pas une règle de désindexation. Bien utilisé, il aide à limiter l’exploration inutile et à clarifier les priorités techniques d’un site. Mal configuré, il peut au contraire empêcher les moteurs d’accéder à des ressources indispensables ou à des pages que vous souhaitez rendre visibles.
Ce guide explique comment construire un fichier robots.txt simple, où le placer, comment vérifier ses règles et dans quels cas il vaut mieux ne pas l’utiliser.
À quoi sert réellement un fichier robots.txt ?
Le fichier robots.txt se trouve à la racine du domaine, par exemple à l’adresse https://exemple.fr/robots.txt. Lorsqu’un robot visite un site, il peut consulter ce fichier avant de commencer son exploration. Les règles s’appliquent généralement à un agent donné, comme Googlebot, ou à tous les robots avec l’agent générique.
Son rôle principal est de gérer l’exploration, et non l’indexation. Une règle peut demander à un robot de ne pas visiter une URL ou un répertoire, mais elle ne constitue pas une garantie absolue que l’adresse restera absente des résultats. Une URL interdite peut parfois être connue par un lien externe et apparaître sans que son contenu soit exploré.
Cette distinction permet d’éviter trois confusions fréquentes :
- Empêcher l’exploration : c’est la fonction principale du robots.txt.
- Empêcher l’indexation : cela passe plutôt par une directive noindex envoyée dans la page ou dans un en-tête HTTP, lorsque le robot peut accéder à la ressource.
- Protéger une donnée : cela nécessite une authentification, une restriction d’accès ou un contrôle côté serveur.
Ne placez donc jamais un mot de passe, une clé d’API ou un document confidentiel dans un répertoire en pensant qu’une règle Disallow le rendra privé. Le fichier est public et les règles peuvent être consultées par n’importe quel visiteur.
La syntaxe minimale à connaître
Un fichier robots.txt est composé de groupes de règles. Chaque groupe commence par une directive User-agent, qui désigne le robot concerné, puis contient une ou plusieurs directives Disallow ou Allow.
Pour appliquer une règle à tous les robots, la structure la plus simple est la suivante : User-agent: * puis Disallow: /dossier-prive/.
La première ligne cible tous les robots. La seconde leur demande de ne pas explorer les URL dont le chemin commence par « /dossier-prive/ ». Le slash final est utile pour limiter la règle à ce répertoire plutôt qu’à toutes les URL dont le nom commencerait par le même texte.
Voici les principaux cas de figure à comprendre :
- Disallow: / interdit l’exploration de l’ensemble du site pour le robot concerné.
- Disallow: /admin/ bloque l’exploration d’un répertoire et de ses sous-chemins.
- Disallow: laissé vide n’interdit aucun chemin.
- Allow: /admin/ajax-public/ peut autoriser un sous-chemin précis lorsqu’une règle plus large le bloque.
- Une ligne commençant par le caractère dièse est un commentaire et n’est pas interprétée comme une règle.
Les comportements exacts peuvent varier selon les moteurs et leur interprétation des règles avancées. Pour un site courant, une syntaxe courte, explicite et testée reste préférable à un ensemble de motifs difficiles à maintenir.
Construire un fichier adapté à un site vitrine ou WordPress
Un petit site n’a généralement pas besoin d’une longue liste d’interdictions. Commencez par identifier les URL qui consomment inutilement des ressources d’exploration sans apporter de valeur dans les résultats : certains espaces d’administration, des répertoires techniques ou des variantes internes générées par un outil.
Sur WordPress, il faut éviter de copier une liste trouvée en ligne sans comprendre ses conséquences. Les répertoires nécessaires au fonctionnement visuel du site, notamment certains fichiers CSS ou JavaScript, ne doivent pas être bloqués automatiquement. Si Google ne peut pas charger les ressources d’une page, il risque de mal interpréter sa mise en page ou son expérience sur mobile.
Une approche prudente consiste à :
- Observer les URL réellement explorées dans les outils de suivi du site.
- Repérer les chemins répétitifs, inutiles ou générés par des fonctions internes.
- Ajouter une seule règle à la fois.
- Vérifier qu’aucune page importante, image ou ressource nécessaire n’est concernée.
- Surveiller les effets après la mise en ligne.
Le fichier peut aussi déclarer l’emplacement du sitemap XML avec une ligne du type « Sitemap: https://exemple.fr/sitemap.xml ». Cette indication aide les moteurs à trouver le plan du site, mais elle ne remplace pas sa déclaration dans les outils dédiés ni la qualité de ses URL.
Les erreurs qui bloquent un site par inadvertance
Interdire tout le domaine pendant une mise en ligne
La règle Disallow: / est parfois utilisée sur un site de préproduction. Le problème apparaît lorsque cette configuration est transférée sur le site public sans être retirée. Le domaine reste alors difficilement explorable. Avant chaque mise en production, vérifiez le contenu du fichier depuis l’adresse publique et non uniquement dans l’interface de votre CMS.
Confondre une URL et un répertoire
Une règle trop courte peut toucher davantage de pages que prévu. Par exemple, un chemin générique peut correspondre à plusieurs URL ayant un préfixe commun. Décrivez le chemin complet lorsque vous ciblez une fonction précise et documentez la raison de chaque règle complexe.
Bloquer les fichiers utiles au rendu
Les feuilles de style, scripts et images ne sont pas de simples détails techniques. Les moteurs peuvent en avoir besoin pour comprendre l’affichage d’une page. Avant de bloquer un type de ressource, demandez-vous si cette ressource est chargée dans des pages publiques et si son absence modifierait leur rendu.
Utiliser robots.txt pour cacher une page sensible
Une page bloquée peut rester connue par son adresse. Pour une information privée, supprimez la publication, protégez l’accès par authentification ou appliquez une mesure adaptée au serveur. Le robots.txt n’est pas un dispositif de sécurité.
Robots.txt, noindex et protection d’accès : quelle solution choisir ?
| Objectif | Solution la plus adaptée | Point de vigilance |
|---|---|---|
| Réduire l’exploration d’une zone inutile | Robots.txt | La règle ne garantit pas la désindexation de l’URL. |
| Retirer une page des résultats | Directive noindex | Le robot doit pouvoir accéder à la page pour lire la directive. |
| Réserver une page à des utilisateurs autorisés | Authentification ou contrôle serveur | Ne pas exposer de contenu confidentiel dans une URL publique. |
| Signaler les pages importantes | Sitemap XML et liens internes cohérents | Un sitemap ne force pas l’indexation. |
Ces outils peuvent être combinés, mais ils ne répondent pas au même besoin. Bloquer une page avec robots.txt puis attendre que Google lise un noindex placé dans cette page est contradictoire : si l’accès est interdit, le robot ne peut généralement pas consulter la directive.
Comment vérifier un robots.txt sans prendre de risque
Commencez par ouvrir directement le fichier dans un navigateur. Vérifiez qu’il est accessible sur le bon domaine, en HTTPS, et qu’il ne renvoie pas une page d’erreur ou le contenu d’un autre document. Un site multilingue ou réparti sur plusieurs sous-domaines peut nécessiter un fichier distinct pour chaque hôte.
Ensuite, examinez les règles comme si vous étiez un robot : une page stratégique est-elle concernée ? Le chemin d’un sitemap est-il correct ? Une règle générale est-elle neutralisée par une exception mal formulée ? Ne vous contentez pas de tester la page d’accueil. Contrôlez aussi une page de contenu, une ressource chargée par le thème et, si le site en possède, une URL filtrée ou paramétrée.
Les outils pour webmasters peuvent signaler des problèmes d’exploration, mais leurs tests ne remplacent pas une lecture humaine de la configuration. Après une modification importante, surveillez les rapports d’indexation, les erreurs d’exploration et les évolutions inhabituelles du trafic organique. Un changement brutal doit conduire à vérifier le fichier avant de modifier d’autres éléments SEO.
La règle de décision à retenir
Si votre objectif est simplement d’empêcher l’exploration d’une zone sans intérêt, le robots.txt peut convenir. Si vous voulez retirer une page des résultats, choisissez une directive de désindexation adaptée. Si vous cherchez à protéger une information, utilisez un contrôle d’accès réel.
Pour un site débutant, la meilleure configuration n’est pas la plus longue. Elle est compréhensible, limitée aux besoins identifiés et vérifiée après chaque changement. Gardez une copie de la version précédente, notez la raison de chaque règle et effectuez un contrôle lors de chaque mise en production. Cette discipline évite qu’une simple ligne transforme un problème technique local en blocage global de la visibilité.
Maya Connect
Maya Connect est la voix éditoriale de Clic Connect. Curieuse, méthodique et attentive aux usages concrets, elle transforme les sujets numériques complexes en parcours compréhensibles et applicables. Elle relie chaque notion à un objectif précis, explicite les prérequis et distingue systématiquement les faits établis, les bonnes pratiques et les pistes à expérimenter.
