Le fichier robots.txt est l'un des outils les plus anciens et les plus puissants de l'arsenal d'un webmaster. Situé à la racine de chaque domaine, ce fichier texte brut indique aux crawlers quelles parties de votre site ils peuvent explorer et lesquelles ils doivent ignorer. Malgré sa simplicité, le robots.txt est aussi l'un des fichiers les plus fréquemment mal configurés sur le web. Une seule règle mal placée peut masquer un site entier aux moteurs de recherche ou exposer des sections que vous souhaitiez garder privées.

Ce guide couvre tout, des fondamentaux syntaxiques aux patterns avancés, pour que vous puissiez rédiger vos règles robots.txt en toute confiance.

Où se trouve le robots.txt et comment les crawlers le trouvent

Tout crawler conforme, avant de demander toute autre URL sur un domaine, récupère le fichier /robots.txt à la racine :

https://example.com/robots.txt

Règles essentielles concernant le fichier :

• Il doit être servi au chemin exact /robots.txt — pas /Robots.txt, ni dans un sous-répertoire.
• Il doit renvoyer un code de statut 200 avec un type de contenu text/plain. Si le serveur renvoie un 404, les crawlers supposent que tout est autorisé. Une erreur 5xx amène la plupart des crawlers à suspendre entièrement l'exploration jusqu'à ce que le fichier redevienne disponible.
• Le fichier s'applique par origine (schéma + hôte + port). Une règle sur https://example.com/robots.txt ne régit pas https://blog.example.com ni http://example.com.
• La taille maximale du fichier respectée par Google est de 500 Kio. Tout ce qui dépasse cette limite est ignoré.

Syntaxe de base

Un fichier robots.txt est composé d'un ou plusieurs groupes de règles. Chaque groupe commence par une ou plusieurs lignes User-agent, suivies de directives Disallow et/ou Allow :

User-agent: Googlebot
Disallow: /private/
Allow: /private/public-page.html

User-agent: *
Disallow: /tmp/
Disallow: /internal/

User-agent

La ligne User-agent spécifie quel crawler est concerné par les règles suivantes. Le joker * correspond à tout crawler qui ne dispose pas de son propre bloc spécifique. Les crawlers se rattachent au bloc User-agent le plus spécifique disponible. Si User-agent: * et User-agent: Googlebot coexistent, Googlebot utilise uniquement le bloc qui lui est dédié et ignore entièrement le bloc joker.

Disallow

Disallow: /path/ indique au crawler concerné de ne pas accéder aux URL commençant par /path/. Un Disallow: vide (sans chemin) signifie que rien n'est interdit — équivalent à un accès complet.

Allow

Allow: /path/ autorise explicitement l'accès aux URL correspondant au pattern, même si un Disallow plus large les bloquerait autrement. C'est essentiel pour créer des exceptions.

Wildcards et correspondance de motifs

La spécification originale de 1994 du robots.txt n'incluait pas de wildcards, mais Google, Bing et la plupart des crawlers modernes prennent en charge deux caractères importants de correspondance de motifs :

L'astérisque : *

Correspond à toute séquence de caractères (y compris une chaîne vide). Exemples :

• Disallow: /*.pdf — bloque toutes les URL contenant .pdf n'importe où dans le chemin.
• Disallow: /directory/*/page — bloque les URL comme /directory/anything/page.

Le signe dollar : $

Ancre la correspondance à la fin de l'URL. Sans $, les patterns correspondent comme des préfixes. Exemples :

• Disallow: /*.pdf$ — bloque les URL qui se terminent par .pdf mais autorise /file.pdf?view=1 (car l'URL ne se termine pas à .pdf).
• Allow: /page$ — autorise exactement /page mais pas /page/subpage ni /page?q=1.

Allow vs Disallow : lequel l'emporte ?

Lorsqu'une URL correspond à la fois à une règle Allow et à une règle Disallow, la résolution dépend de la spécificité (longueur du chemin). L'implémentation de Google suit cette logique :

1. La règle avec le chemin correspondant le plus long l'emporte.
2. Si les deux règles ont la même longueur, Allow prend le dessus.

Exemple :

User-agent: *
Disallow: /directory/
Allow: /directory/public/

Ici, /directory/public/page.html est autorisé car /directory/public/ (20 caractères) est plus long que /directory/ (11 caractères). Mais /directory/secret.html reste bloqué.

C'est une source de confusion fréquente. Testez toujours vos règles avec un outil de validation robots.txt pour confirmer le résultat pour des URL spécifiques.

La directive Crawl-delay

Crawl-delay demande au crawler d'attendre un nombre de secondes défini entre les requêtes successives :

User-agent: Bingbot
Crawl-delay: 10

Points importants :

• Google ignore totalement Crawl-delay. Pour contrôler la fréquence d'exploration de Googlebot, utilisez le paramètre Crawl Rate dans Google Search Console.
• Bing le respecte. Une valeur de 10 signifie que Bingbot attendra 10 secondes entre les requêtes.
• Yandex, Baidu et certains autres crawlers le respectent également, bien que les implémentations varient.
• Définir une valeur excessivement élevée (par ex. 60) arrête de fait l'exploration. À utiliser avec parcimonie et uniquement lorsque votre serveur ne peut réellement pas supporter la charge.

La directive Sitemap

Vous pouvez déclarer des sitemaps directement dans le robots.txt :

Sitemap: https://example.com/sitemap.xml
Sitemap: https://example.com/sitemap-news.xml

Points essentiels :

• La directive Sitemap n'est liée à aucun bloc User-agent. Placez-la en haut ou en bas du fichier — elle s'applique globalement.
• L'URL doit être complètement qualifiée (URL absolue avec le schéma).
• Vous pouvez lister plusieurs sitemaps.
• C'est une indication de découverte, pas une garantie. Soumettre les sitemaps via Search Console ou Bing Webmaster Tools est plus fiable.

Erreurs courantes qui perturbent l'exploration

1. Bloquer les CSS et le JavaScript

User-agent: *
Disallow: /assets/
Disallow: /js/
Disallow: /css/

Les moteurs de recherche modernes effectuent le rendu des pages pour évaluer le contenu et la mise en page. Si vous bloquez les ressources nécessaires au rendu, le crawler voit une page cassée — et peut la rétrograder ou l'ignorer. Ne bloquez que les ressources véritablement sans rapport avec le rendu du contenu public.

2. Utiliser Disallow pour empêcher l'indexation

Disallow empêche l'exploration, pas l'indexation. Si d'autres pages renvoient vers une URL bloquée, Google peut quand même l'indexer — simplement sans contenu à afficher, ce qui donne un résultat cryptique. Pour réellement retirer une page de l'index, utilisez une balise meta noindex ou un en-tête X-Robots-Tag et autorisez le crawler à voir la page.

3. Oublier le slash final

Disallow: /private   # bloque /private, /private.html, /privately, etc.
Disallow: /private/  # bloque uniquement les chemins à l'intérieur du répertoire /private/

Le premier pattern est plus large que ce que la plupart des gens prévoient. Réfléchissez toujours à la nécessité du slash final.

4. Blocs joker et blocs spécifiques contradictoires

Avoir un bloc User-agent: * et un bloc spécifique à un bot où le bloc spécifique est vide donne effectivement à ce bot un accès complet — même si le bloc joker est restrictif. C'est voulu, mais cela surprend les personnes qui supposent que les règles se cumulent.

5. Servir le robots.txt derrière une redirection

Si /robots.txt renvoie un 301 ou 302, la plupart des crawlers suivront la redirection. Cependant, les chaînes de redirection, les boucles de redirection ou la redirection vers une réponse non text/plain amèneront les crawlers à considérer le fichier comme indisponible. Restez simple : servez le fichier directement à la racine avec une réponse 200.

6. Ne pas prendre en compte les crawlers IA

Si votre robots.txt ne contient qu'un bloc User-agent: *, tout crawler IA que vous n'avez pas explicitement bloqué aura le même accès que Googlebot. Pensez à ajouter des règles spécifiques pour des bots comme GPTBot, ClaudeBot, PerplexityBot et Bytespider.

Tester votre robots.txt

Ne déployez jamais de modifications du robots.txt sans les tester. Outils disponibles :

• Google Search Console — le testeur robots.txt montre comment Google interprète vos règles pour des URL spécifiques.
• Bing Webmaster Tools — fonctionnalité de test similaire pour Bingbot.
• Spider.es — vérifiez quels crawlers (moteurs de recherche, bots IA, outils SEO) peuvent accéder à n'importe quelle URL de votre domaine, avec la règle spécifique qui contrôle chaque verdict.
• Outils en ligne de commande — des bibliothèques comme urllib.robotparser de Python vous permettent d'automatiser les tests dans les pipelines CI/CD.

Un modèle de départ solide

# Moteurs de recherche : accès complet
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /
Crawl-delay: 5

# Crawlers IA : accès sélectif
User-agent: GPTBot
Disallow: /premium/
Allow: /blog/

User-agent: Google-Extended
Disallow: /

# Par défaut : autorisé avec restrictions
User-agent: *
Disallow: /admin/
Disallow: /tmp/
Disallow: /search?*

Sitemap: https://example.com/sitemap.xml

Adaptez ce modèle à vos besoins. Le principe est simple : soyez explicite sur ce que vous autorisez, délibéré sur ce que vous bloquez, et testez avant de déployer.

Conclusion

Le robots.txt est d'une simplicité trompeuse. Quelques lignes de texte déterminent si des millions de personnes peuvent découvrir votre contenu via les moteurs de recherche et les outils IA. Traitez-le avec le même soin que la configuration de sécurité de votre site. Auditez-le régulièrement — surtout lorsque de nouveaux crawlers IA apparaissent — et utilisez des outils comme Spider.es pour vérifier que votre politique souhaitée correspond à la réalité.