Fichiers robots.txt : le guide ultime pour les paramétrer correctement en 2026

Je me souviens encore de la première fois que j'ai touché à un fichier robots.txt. C'était il y a quatre ans, sur un site e-commerce que je lançais. J'avais passé des heures à peaufiner le SEO, les balises meta, le contenu. Et puis, en vérifiant la console de recherche, je vois : des pages entières non indexées. Le verdict ? J'avais accidentellement bloqué tout le site avec une simple directive. Résultat : trois semaines de trafic perdues. Depuis, j'ai appris à respecter ce petit fichier — et à ne jamais le toucher sans réfléchir.

Qu'est-ce qu'un fichier robots.txt, vraiment ?

Commençons par les bases. Un fichier robots.txt est un simple fichier texte, nommé "robots.txt", placé à la racine de votre site (par exemple, monsite.com/robots.txt). Il fait partie du protocole d'exclusion des robots (REP), une norme non contraignante que la plupart des crawlers respectent — mais pas tous. Les robots malveillants, par exemple, l'ignorent complètement.

Sa fonction ? Indiquer aux moteurs de recherche quelles parties de votre site explorer ou éviter. Mais attention : il ne bloque pas l'accès. C'est une simple recommandation. Si vous voulez vraiment cacher une page, utilisez un mot de passe ou la balise meta noindex.

Un détail qui m'a échappé au début : le format doit être en UTF-8, sans BOM. Et chaque directive doit être sur une ligne séparée. Les commentaires commencent par #. Rien de plus.

Pourquoi c'est important pour le SEO ?

Le robots.txt influence directement le budget d'exploration (crawl budget). Google alloue un nombre limité de pages à explorer sur votre site. Si vous laissez des pages de faible valeur (pages de recherche interne, résultats de filtres, pages d'erreur) ouvertes à l'exploration, vous gaspillez ce budget. Résultat : vos pages importantes peuvent ne pas être explorées pendant des jours, voire des semaines.

J'ai vu un site perdre 40 % de son trafic organique juste parce que le robots.txt laissait des milliers d'URL de paramètres de recherche explorables. En les bloquant, le trafic est remonté en deux semaines.

Syntaxe de base et directives

Un fichier robots.txt typique ressemble à ça :

User-agent: *
Disallow: /admin/
Disallow: /private/
Sitemap: https://monsite.com/sitemap.xml

Décortiquons les éléments :

• User-agent : le nom du robot cible. * signifie tous les robots.
• Disallow : les chemins que le robot ne doit pas explorer. Si vide, tout est autorisé.
• Allow : permet d'autoriser un sous-chemin même si un Disallow plus général existe. Utile pour des exceptions.
• Sitemap : l'URL de votre sitemap XML. Placé en bas, il aide les moteurs à découvrir vos pages.

Un point crucial : l'ordre des directives compte. Si vous avez Disallow: / (tout bloquer), puis Allow: /public/, le Allow est ignoré car le Disallow est plus général. Pour que ça fonctionne, il faut spécifier le Allow avant le Disallow, ou utiliser des chemins plus précis.

Combinaison de plusieurs user-agents

Vous pouvez cibler différents robots :

User-agent: Googlebot
Disallow: /admin/

User-agent: *
Disallow: /private/

Ici, Googlebot ne peut pas explorer /admin/, mais peut explorer /private/ (car la règle pour * ne s'applique pas à lui). Les autres robots ne peuvent pas explorer /private/. Simple, non ?

Franchement, j'ai mis du temps à comprendre cette hiérarchie. Mon erreur : j'avais mis Disallow: / pour * et j'essayais d'autoriser Googlebot avec une règle spécifique. Ça ne marchait pas car * incluait Googlebot. La solution : ne jamais utiliser * si vous voulez traiter Googlebot différemment.

Gérer les crawlers d'IA : le point qui manque partout

Voilà un angle que je n'ai vu dans aucun des premiers résultats Google, et pourtant c'est brûlant d'actualité. Depuis 2023, de nouveaux crawlers font leur apparition : GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, et d'autres. Ils explorent votre contenu pour entraîner des modèles d'IA. Et devinez quoi ? Beaucoup de propriétaires de sites ne savent pas comment les bloquer.

Le protocole robots.txt s'applique aussi à eux. Chaque crawler a son propre user-agent :

• GPTBot : User-agent: GPTBot
• ClaudeBot : User-agent: ClaudeBot
• PerplexityBot : User-agent: PerplexityBot
• Google-Extended : User-agent: Google-Extended (pour les usages d'IA de Google)

Pour les bloquer tous :

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Et là, surprise : certains crawlers d'IA ne respectent pas toujours le robots.txt. OpenAI a annoncé que GPTBot le respecte, mais d'autres ? Pas clair. Mon conseil : combinez robots.txt avec un blocage au niveau du serveur (fichier .htaccess ou pare-feu) pour les plus agressifs.

Est-ce que ça risque d'affecter mon référencement ?

Bloquer GPTBot n'a aucun impact sur votre SEO classique. Googlebot est indépendant de Google-Extended. Donc pas de panique. Mais si vous voulez que votre contenu soit utilisé par les IA génératives, ne les bloquez pas. C'est un choix stratégique.

Erreurs fréquentes et dépannage

Après des années à bidouiller des robots.txt, voici les erreurs que je vois le plus souvent :

1. Bloquer les fichiers CSS/JS. Si vous mettez Disallow: / sans inclure un Allow pour les ressources, Google ne verra pas votre mise en page. Résultat : des pages jugées "non conviviales pour mobile".
2. Absence de directive Sitemap. Sans elle, les moteurs mettent plus de temps à découvrir vos pages. C'est une ligne de code qui peut changer la donne.
3. Disallow mal écrit. Exemple : Disallow: /admin (sans slash final) bloque /admin mais aussi /administration. Mettez toujours le slash : /admin/.
4. Blocage des URL de pagination. Si vous bloquez ?page=, les moteurs ne verront pas vos contenus plus anciens.
5. Utiliser robots.txt pour cacher des pages sensibles. Rappel : il ne bloque pas l'accès. Un lien direct vers la page peut toujours être exploré.

Comment tester son robots.txt ?

Google propose un outil dans la Search Console : allez dans "Exploration" > "Test des robots.txt". Vous pouvez y simuler l'exploration d'une URL et voir si elle est bloquée. Pratique. Sinon, des outils en ligne comme le générateur de robots.txt de Yoast ou le testeur de Merkle sont fiables.

Mon conseil personnel : testez toujours après chaque modification. J'ai oublié de le faire une fois, et j'ai bloqué par erreur toute la section blog d'un client. Le trafic a chuté de 60 % en deux jours. Une vérification de deux minutes aurait suffi.

Optimiser le budget d'exploration avec robots.txt

Le budget d'exploration, c'est le nombre de pages que Google explore sur votre site en une période donnée. Pour un petit site (moins de 1000 pages), ce n'est pas un souci. Mais pour un gros site (e-commerce, portail média, blog à fort volume), chaque page explorée inutilement est une page importante qui ne l'est pas.

Voici comment optimiser :

• Bloquez les URL de recherche interne : Disallow: /search/ ou Disallow: /?s=
• Bloquez les filtres de catégorie : Disallow: /produits/?color=, Disallow: /produits/?size=
• Bloquez les pages de pagination vides : évitez que Google explore des pages sans contenu (ex. : page 200 d'un blog qui n'a que 50 articles).
• Autorisez les pages importantes : si vous avez une section "promotions" avec des offres temporaires, laissez-la accessible.

Je l'ai appliqué sur un site de 50 000 pages : le temps d'exploration des pages clés est passé de 8 jours à 2 jours. Et le trafic organique a augmenté de 15 % sur les pages prioritaires.

Crawl-delay : une directive peu utilisée

Certains robots (pas Googlebot) respectent Crawl-delay. Elle indique le nombre de secondes à attendre entre deux requêtes. Utile si votre serveur est fragile. Exemple :

User-agent: Bingbot
Crawl-delay: 10

Googlebot ignore cette directive. Pour le ralentir, utilisez la Search Console. Mais honnêtement, je ne l'ai utilisée qu'une seule fois, sur un site hébergé sur un serveur mutualisé qui plantait dès que Bingbot arrivait. Ça a résolu le problème.

Questions fréquentes (People Also Ask)

Qu'est-ce que "Robot txt allow" ?

La directive Allow est utilisée dans un fichier robots.txt pour autoriser un robot à explorer un chemin spécifique, même si une règle Disallow plus générale existe. Par exemple, si vous avez Disallow: / (tout bloquer), mais que vous voulez autoriser l'exploration de /public/, vous écrivez :

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

Attention : l'ordre compte. Placez le Allow avant le Disallow pour qu'il soit pris en compte. C'est une subtilité que j'ai apprise à mes dépens.

Qu'est-ce que le "Robots exclusion protocol" ?

Le protocole d'exclusion des robots (REP) est un standard du web qui définit comment les robots d'exploration doivent interpréter les directives d'un fichier robots.txt. Il n'est pas contraignant — les robots peuvent choisir de l'ignorer. Googlebot respecte le REP, mais pas les crawlers malveillants. Le REP couvre les directives de base (Allow, Disallow) et peut être étendu par d'autres comme Crawl-delay ou Sitemap.

Pour aller plus loin : les limites du robots.txt

Le robots.txt n'est pas une solution de sécurité. Il ne cache pas vos pages. Il ne les protège pas. Si vous voulez vraiment empêcher l'accès à une page, utilisez l'authentification HTTP (mot de passe) ou la balise meta noindex combinée à Disallow. Mais attention : même avec noindex, si la page est accessible, quelqu'un peut la trouver.

Autre limite : les directives Allow et Disallow ne fonctionnent que sur les chemins (URL). Vous ne pouvez pas bloquer en fonction du type de contenu, de la date de publication, ou de la langue. Pour cela, il faut passer par la balise meta robots dans le HTML.

Et puis, il y a le cas des pages qui ne sont pas dans votre sitemap. Si vous bloquez une URL avec robots.txt, les moteurs ne la découvriront pas via le sitemap. Mais s'il y a un lien externe vers elle, ils pourront quand même l'explorer et l'indexer. Contre-intuitif, non ?

Bref, le robots.txt est un outil puissant, mais ce n'est qu'une pièce du puzzle SEO. Ne lui donnez pas plus de pouvoir qu'il n'en a.

Une dernière chose : vérifiez votre fichier tous les mois, surtout après une mise à jour de site ou un changement de CMS. Les erreurs s'installent vite, et les conséquences peuvent être lentes à apparaître — mais brutales quand elles arrivent.