Guide pratique : Le fichier robots.txt expliqué simplement

Pourquoi maîtriser robots.txt ?

Un robots.txt mal configuré peut désindexer tout votre site en quelques heures. Inversement, bien utilisé, il bloque les bots inutiles (scrapers, IA d’entraînement) et économise votre budget de crawl Google. C’est le premier fichier que regarde tout bot qui visite votre domaine.

Emplacement et syntaxe

Le fichier robots.txt se place à la racine du domaine : https://example.sn/robots.txt. Il n’est pas case-sensitive pour le nom mais l’est pour les chemins.

User-agent: *
Disallow: /wp-admin/
Disallow: /cart/
Disallow: /checkout/
Allow: /wp-admin/admin-ajax.php

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

Directives par bot

User-agent: Googlebot
Disallow: /admin/
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: bingbot
Crawl-delay: 10
Disallow: /search

User-agent: *
Disallow: /api/private/

Les User-agents à connaître

Moteurs:        Googlebot, Googlebot-Image, bingbot, DuckDuckBot, YandexBot, Baiduspider
IA scrapers:    GPTBot, ClaudeBot, Claude-Web, anthropic-ai, CCBot, Google-Extended, PerplexityBot
Réseaux:        facebookexternalhit, Twitterbot, LinkedInBot
SEO tools:      AhrefsBot, SemrushBot, MJ12bot, DotBot

Bloquer les IA de l’entraînement (tout en gardant Googlebot)

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: *
Allow: /

Wildcards et ancrage

User-agent: *
Disallow: /*.pdf$        # bloque tous les PDF
Disallow: /*?sessionid=  # bloque les URLs avec param sessionid
Disallow: /tmp/          # répertoire entier
Allow: /tmp/public/      # exception dans tmp

Servir robots.txt en Next.js

// app/robots.ts
import type { MetadataRoute } from "next";

export default function robots(): MetadataRoute.Robots {
  return {
    rules: [
      { userAgent: "*", allow: "/", disallow: ["/api/", "/admin/"] },
      { userAgent: "GPTBot", disallow: "/" },
      { userAgent: "ClaudeBot", disallow: "/" },
    ],
    sitemap: "https://example.sn/sitemap.xml",
    host: "https://example.sn",
  };
}

Nginx qui réécrit dynamiquement

location = /robots.txt {
  default_type text/plain;
  return 200 "User-agent: *\nDisallow: /api/\nSitemap: https://$host/sitemap.xml\n";
}

Erreurs classiques

❌ Disallow: /                  # bloque tout le site (à faire en prod par erreur)
❌ Disallow: *                  # syntaxe invalide, ignorée
❌ Allow: / + Disallow: /       # ambiguïté
❌ Robots.txt invalide UTF-8    # encoder en UTF-8 sans BOM
❌ robots.txt > 500 KB           # Google ignore au-delà
❌ Redirection 301 de robots.txt # risque d'être ignoré

Tester avec Google

# Outil Testeur robots.txt (ex-Search Console, déprécié 2023)
# Actuellement: URL Inspection dans Search Console pour vérifier
# chaque URL individuellement

# Validation programmatique
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1)" https://example.sn/robots.txt

# Test par Python (robotparser)
python - <<'EOF'
from urllib.robotparser import RobotFileParser
rp = RobotFileParser()
rp.set_url("https://example.sn/robots.txt")
rp.read()
print(rp.can_fetch("Googlebot", "https://example.sn/admin"))  # False
print(rp.can_fetch("*", "https://example.sn/produit/42"))     # True
EOF

Différence avec noindex

robots.txt Disallow: empêche le CRAWL (Google ne télécharge pas)
                     → l'URL peut quand même apparaître dans les résultats sans description

<meta name="robots" content="noindex">: interdit l'INDEXATION
                     → requiert que le bot puisse crawler la page pour voir le noindex !
                     → donc si on veut noindex, il faut PAS bloquer via robots.txt
                     → noindex est plus efficace pour masquer complètement

Règle: pour cacher une page des résultats, utiliser noindex et LAISSER le crawl.

Pour creuser ce sujet

• Sitemap XML
• Configurer Search Console
• Spec officielle : RFC 9309 — Robots Exclusion Protocol
• Doc Google : Google — Introduction to robots.txt
• Liste bots IA : darkvisitors.com

Étape 1 : comprendre à quoi sert vraiment robots.txt

Le fichier robots.txt est un texte simple, déposé à la racine d’un site, qui indique aux robots d’indexation quelles parties du site ils peuvent explorer. Il est défini par le RFC 9309 publié en septembre 2022, qui standardise enfin un protocole utilisé depuis 1994 sous le nom Robots Exclusion Protocol. Ce n’est pas un mécanisme de sécurité : un robot malveillant l’ignorera. C’est un signal de coopération adressé aux robots respectueux : Googlebot, Bingbot, applebot, et la plupart des crawlers SEO.

Une boutique e-commerce à Dakar qui veut empêcher Google d’indexer ses pages de panier ou ses URL avec paramètres internes ne doit pas se contenter de robots.txt : il bloque le crawl, pas l’indexation. Pour empêcher l’indexation, on utilise une balise meta robots noindex ou un en-tête HTTP X-Robots-Tag. Cette distinction est centrale et mal comprise par 80% des propriétaires de site.

Étape 2 : localiser et créer le fichier

Le fichier doit être accessible à l’URL exacte https://votre-domaine.tld/robots.txt. Pas dans un sous-dossier, pas avec une autre casse, pas en HTTP si le site est en HTTPS. Sur un hébergement mutualisé, déposez-le dans le dossier public_html ou www selon le panneau de contrôle. Sur un site WordPress, il peut être généré dynamiquement par un plugin SEO ou exister physiquement sur le disque.

# Test depuis un terminal
curl -I https://exemple.sn/robots.txt
# Doit renvoyer 200 OK et Content-Type: text/plain

Si vous obtenez 404, le fichier n’existe pas et les robots considèrent que tout est autorisé. Si vous obtenez 200 mais avec un Content-Type HTML, le serveur sert une page d’erreur stylisée à la place : à corriger immédiatement, car certains crawlers conservatifs interprètent cela comme un blocage total et arrêtent de visiter le site.

Étape 3 : écrire les directives de base

La syntaxe minimale tient en deux directives. User-agent identifie le robot ciblé (l’astérisque vise tous les robots). Disallow liste les chemins interdits. Une ligne vide sépare les blocs.

User-agent: *
Disallow: /admin/
Disallow: /panier/
Disallow: /tmp/

Cette configuration interdit à tous les robots l’accès aux répertoires admin, panier et tmp. Le chemin doit commencer par un slash et représente une URL relative à la racine. Disallow: /admin bloquerait aussi /admin-public/ par préfixe : ajoutez le slash de fin si vous voulez bloquer un dossier exact.

Étape 4 : autoriser explicitement avec Allow

La directive Allow inverse Disallow pour autoriser un chemin spécifique à l’intérieur d’un dossier interdit. C’est utile pour exposer une ressource précieuse au sein d’une zone bloquée.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Ici, on bloque l’admin WordPress mais on autorise admin-ajax.php qui est utilisé par certains plugins frontaux pour récupérer des données : sans cette autorisation explicite, les robots verraient des pages cassées et pénaliseraient le site. La règle de spécificité veut que la directive la plus précise gagne.

Étape 5 : cibler des robots spécifiques

Vous pouvez écrire des règles différentes pour chaque robot. C’est utile pour autoriser Googlebot mais bloquer un crawler agressif qui surcharge votre serveur.

User-agent: Googlebot
Disallow: /private/

User-agent: AhrefsBot
Disallow: /

User-agent: *
Disallow: /admin/

Dans cet exemple, Googlebot ne peut pas crawler /private/ mais a accès au reste, AhrefsBot est totalement bloqué, et tous les autres robots ne voient pas /admin/. Attention : un robot ne lit qu’un seul bloc, celui qui le concerne le plus précisément. Si Googlebot trouve un bloc qui le cible nommément, il ignore le bloc User-agent: *.

Étape 6 : déclarer le sitemap XML

Le robots.txt est aussi le bon endroit pour pointer vers votre sitemap XML, ce qui aide les robots à découvrir toutes vos URL importantes. La directive Sitemap accepte une URL absolue.

Sitemap: https://exemple.sn/sitemap_index.xml
Sitemap: https://exemple.sn/news-sitemap.xml

Plusieurs lignes Sitemap sont autorisées. Placez-les en haut ou en bas du fichier. Cette déclaration ne remplace pas la soumission du sitemap dans Google Search Console et Bing Webmaster Tools, mais elle aide les autres moteurs (DuckDuckGo, Qwant, Yandex) qui n’ont pas de console de soumission grand public.

Étape 7 : utiliser les jokers et le caractère $

Googlebot et la plupart des grands moteurs supportent les caractères spéciaux * (n’importe quelle séquence) et $ (fin d’URL). Ils ne sont pas dans le RFC 9309 mais sont devenus un standard de fait.

User-agent: *
Disallow: /*?session=
Disallow: /*.pdf$
Disallow: /search?

La première règle bloque toutes les URL contenant ?session=. La deuxième bloque exactement les URL se terminant par .pdf (sans bloquer .pdfx ou .pdf?ref=). La troisième bloque toute URL commençant par /search?, utile pour empêcher l’indexation des pages de résultats internes qui créent du contenu dupliqué.

Étape 8 : tester avant de déployer

Une erreur dans robots.txt peut désindexer votre site en quelques jours. Testez impérativement avant de pousser en production. Google Search Console propose un outil de test du robots.txt qui simule le comportement de Googlebot pour une URL donnée. Saisissez une URL importante et vérifiez qu’elle est bien autorisée.

Côté ligne de commande, des outils comme robotstxt en Python ou des bibliothèques en Go reproduisent fidèlement la logique RFC 9309. À lire ensuite sur le SEO technique, voyez notre guide SEO technique checklist et soumettre un sitemap à Google Search Console.

Étape 9 : éviter les pièges classiques

Cinq pièges reviennent constamment. Premier piège : bloquer le CSS et le JavaScript. Google a besoin de charger ces ressources pour rendre la page comme un vrai utilisateur. Bloquer /wp-includes/ ou /wp-content/ en bloc casse le rendu et fait chuter le classement. Deuxième piège : mettre Disallow: / en production par accident, ce qui bloque tout le site.

Troisième piège : oublier que robots.txt est public. Y lister vos chemins admin, c’est offrir une carte au attaquant. Préférez des règles générales et un mot de passe HTTP côté serveur. Quatrième piège : croire que Disallow empêche l’indexation. Une URL bloquée au crawl peut quand même apparaître dans Google si d’autres sites pointent vers elle. Cinquième piège : ne pas tester après chaque modification.

Étape 10 : maintenir le fichier dans le temps

Le robots.txt n’est pas un fichier qu’on écrit une fois et qu’on oublie. À chaque refonte, à chaque ajout de section, vérifiez que les règles sont toujours pertinentes. Versionnez le fichier dans Git si vous hébergez un site géré par développeur, ou conservez l’historique des modifications dans un commentaire en haut du fichier.

# robots.txt v3 — révisé le 30 avril 2026
# Ajout: blocage /tag/ pour réduire la duplication
User-agent: *
Disallow: /tag/
Disallow: /admin/
Sitemap: https://exemple.sn/sitemap_index.xml

Cette discipline transforme un fichier de 5 lignes mystérieux en outil documenté qui survit aux changements de prestataire. Un audit SEO sérieux commence d’ailleurs systématiquement par la lecture du robots.txt : autant qu’il soit propre, lisible, et à jour.

Étape 11 : gérer le crawl-delay et les robots agressifs

Certains crawlers (souvent des outils SEO tiers ou des aspirateurs de contenu) génèrent une charge serveur disproportionnée. La directive Crawl-delay demande au robot d’attendre N secondes entre deux requêtes. Elle n’est pas standard RFC 9309 mais Bing et Yandex la respectent. Google ne la prend pas en compte : pour Googlebot, utilisez la limite de fréquence de crawl dans Google Search Console.

User-agent: bingbot
Crawl-delay: 5

User-agent: SemrushBot
Disallow: /

Cinq secondes entre chaque requête, soit 12 requêtes par minute maximum, suffit largement pour un site éditorial moyen. Pour les robots vraiment hostiles, le bon réflexe est souvent un blocage total au niveau du serveur (.htaccess Apache, configuration Nginx) plutôt qu’une simple ligne Disallow qu’ils ignoreront.

Étape 12 : robots.txt et CDN, un couple à surveiller

Si votre site passe par un CDN (Cloudflare, Bunny, KeyCDN), le robots.txt doit être accessible à la fois sur le domaine principal et sur les éventuels sous-domaines servis par le CDN. Un sous-domaine d’images img.exemple.sn qui sert des médias devrait avoir son propre robots.txt si on veut autoriser l’indexation des images dans Google Images.

Vérifiez aussi que le CDN ne met pas le robots.txt en cache trop longtemps. Une mauvaise mise en cache peut maintenir une ancienne version pendant des heures après une modification critique. Configurez un TTL court (5 à 15 minutes) sur ce fichier précis, indépendamment du TTL global du site.

Étape 13 : ce que robots.txt ne peut pas faire

Pour terminer, listons les usages dans lesquels robots.txt n’est pas la bonne solution. Empêcher l’apparition d’une URL dans Google : utilisez la balise meta robots noindex dans le HTML de la page. Protéger une zone privée : robots.txt n’est pas une barrière, mettez une authentification HTTP ou applicative. Cacher la structure de votre site à un attaquant : le fichier est public, considérez que vos chemins sont visibles. Bloquer les scrapers IA (GPTBot, ClaudeBot, etc.) : c’est possible et de plus en plus courant, mais cela ne s’applique qu’aux crawlers respectueux du protocole.

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

Cette pratique, qui s’est généralisée en 2024-2025, exprime un choix éditorial : ne pas voir son contenu inclus dans les corpus d’entraînement. Elle suppose toutefois que les éditeurs des modèles respectent leur propre user-agent, ce qui est le cas pour les acteurs majeurs aujourd’hui. Documentez le choix dans un commentaire pour qu’il survive aux changements d’équipe technique.