Un fichier `robots.txt` mal configuré, et votre site disparaît de Google. Pas une pénalité, non : une disparition pure et simple. J'ai vu ça arriver sur un site client l'année dernière, et croyez-moi, voir ses pages reculer de 80 % de trafic en deux jours, ça marque.
La plupart des guides en ligne répètent les mêmes généralités : "mettez votre fichier à la racine", "utilisez Disallow"… Mais personne ne parle des pièges réels. Des erreurs que j'ai moi-même commises, passées des heures à déboguer.
Alors voici ce que j'ai appris à force de configurer des robots.txt pour des dizaines de sites, petits et gros.
Comprendre le rôle réel de robots.txt : un filtrage, pas un rempart
Commençons par dissiper un malentendu colossal. robots.txt ne bloque pas l'indexation. C'est un protocole de courtoisie pour les robots d'exploration. Il leur dit : "ne parcourez pas ces pages". Si un robot le respecte, il n'y entrera pas, donc il ne les indexera pas directement. Mais les URLs peuvent toujours apparaître dans les résultats de recherche si des liens externes pointent vers elles. Et si vous bloquez une page avec robots.txt alors qu'elle est déjà indexée, Google peut continuer à l'afficher, sans la recrawler.
Le vrai outil pour empêcher l'indexation, c'est la balise `meta robots` avec la valeur `noindex`, ou l'en-tête HTTP `X-Robots-Tag`. J'ai perdu des semaines à cause de cette confusion.
Ce que robots.txt contrôle vraiment
Voici la liste des actions qu'il permet :
- Diriger les robots vers des zones qu'ils peuvent explorer
- Éviter la surcharge du serveur en bloquant l'accès à des fichiers inutiles (scripts, CSS si vous êtes paranoïaque sur la bande passante)
- Empêcher l'exploration de contenus dupliqués (paramètres de tri, filtres internes)
- Indiquer l'emplacement de votre sitemap
Ce qu'il ne contrôle pas :
- L'indexation (comme dit plus haut)
- Les robots malveillants qui ignorent le protocole
- Le PageRank : une page bloquée par robots.txt ne transmet pas son autorité
Les directives essentielles et les pièges de syntaxe
Le fichier est un texte brut. Il n'y a pas d'extension `.txt` à coller, le fichier s'appelle exactement `robots.txt`. Directives par ligne : `User-agent`, `Disallow`, `Allow`, `Sitemap`.
L'ordre des règles compte. Pour un user-agent donné, la règle la plus spécifique (le plus long préfixe) l'emporte sur les règles générales, pas la plus récente. C'est contre-intuitif.
Erreurs de syntaxe que j'ai commises et leurs conséquences
Voici l'exemple classique, celui que j'ai laissé nous coûter une journée de travail :
User-agent: Googlebot
Disallow: /blog
Allow: /blog/article-important
Ce que je voulais : bloquer tout le blog sauf un article. Ce que Google a compris : l'article important est bloqué aussi. Pourquoi ? Parce que `/blog` est plus court que `/blog/article-important`, donc la règle la plus spécifique, `Allow`, aurait dû l'emporter. Mais à cause d'une autre erreur — l'absence de slash final sur `/blog` — le moteur matchait `/blog` comme préfixe de tout ce qui commençait par "blog", y compris `/blog/article-important`. La règle `Allowed` s'appliquait bien, mais le slash manquant a tout faussé.
Règle d'or : mettez un slash final dans vos répertoires (`/blog/` et non `/blog`).
L'utilisation des wildcards : utile mais risquée
Les `*` et `$` fonctionnent pour Google. Exemple :
Disallow: /*?sort=
Bloque toutes les URLs contenant un paramètre `sort`. Mais soyez précis. J'ai vu des gens écrire `Disallow: /` pour bloquer tout le site… et se demander pourquoi plus rien n'était exploré. Un `Disallow: /` bloque l'accès à toutes les URLs. Dans la plupart des cas, c'est une erreur fatale, sauf si vous voulez tester un environnement de staging.
Mon conseil : commencez simple. Testez. Ajoutez progressivement.
Le cas des sous-domaines et des protocoles
Un point rarement abordé : robots.txt est spécifique à un domaine. Un fichier sur `example.com` ne s'applique pas à `cdn.example.com` ni à `www.example.com`.
Vous devez héberger un fichier séparé sur chaque sous-domaine que vous voulez contrôler.
Et l'implémentation HTTPS/HTTP ? Si votre site est en HTTPS, le fichier doit être accessible en HTTPS à l'URL `https://example.com/robots.txt`. Si un ancien site HTTP existe encore, hébergez un fichier dessus aussi pour rediriger les robots qui passent par l'ancien protocole. C'est un détail que j'ai découvert en analysant les logs de mon serveur : des robots de vieux moteurs passaient encore par HTTP.
Stratégie de test et de validation avant mise en production
Ne mettez jamais un robots.txt en ligne sans le tester. C'est une règle que j'ai apprise à mes dépens, après avoir bloqué par erreur l'exploration de la section produits d'un client pendant 48 heures.
Les outils que vous devriez utiliser
Il y a plusieurs niveaux de vérification :
- La vérification manuelle : ouvrez `https://votresite.com/robots.txt` dans un navigateur et inspectez le contenu brut
- Les validateurs en ligne : le testeur de robots.txt de Google Search Console est l'outil le plus fiable. Il simule l'exploration par Googlebot et vous montre les URLs bloquées
- L'analyse des logs serveur : vérifiez que les robots que vous ciblez accèdent au fichier et respectent les directives. Un pic de trafic sur des URLs bloquées est un signal d'alerte
Je recommande cette méthode :
- Écrivez le fichier dans un éditeur avec coloration syntaxique
- Testez-le sur un environnement de staging ou localement
- Validez avec le testeur de Google Search Console
- Mettez en production
- Surveillez les logs pendant 48 heures
Gestion des robots spécifiques : Bing, Yandex et les crawlers IA
En 2026, on ne peut plus ignorer les bots d'intelligence artificielle. GPTBot, ClaudeBot, PerplexityBot… Ils explorent votre contenu pour entraîner des modèles, et vous pouvez les bloquer ou les autoriser explicitement.
Voici un exemple de config typique pour bloquer les crawlers IA tout en acceptant les moteurs traditionnels :
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: *
Allow: /
Disallow: /admin/
Disallow: /private/
Oui, le `User-agent: *` couvre tous les autres. Et oui, dans ce cas précis, les bots IA sont bloqués car ils sont listés en premier avec leurs propres règles.
Différences entre robots
Chaque robot a ses particularités :
- Googlebot : respecte les wildcards `*` et `$`
- Bingbot : moins flexible sur les motifs avancés
- Yandex : a son propre syntaxe, mais les directives de base fonctionnent
Règle pragmatique : utilisez la syntaxe standard, testez avec Google, et gardez des règles simples pour les autres. Les directives complexes que vous écrivez pour Google peuvent être ignorées ou mal interprétées par Bing.
Créer un fichier robots.txt efficace : marche à suivre complète
Étape 1 : Identifier vos zones privées et vos ressources importantes
Avant d'ouvrir votre éditeur, dressez la liste :
À bloquer : les répertoires d'administration (`/admin/`, `/wp-admin/`), les pages de paramètres, les résultats de recherche interne, les contenus en double, les données utilisateur À autoriser : vos pages principales, vos ressources CSS/JS si vous voulez que Google les explore, vos images À déclarer : votre sitemapÉtape 2 : Rédiger le fichier avec des directives claires
Structure de base :
User-agent: *
Disallow: /admin/
Disallow: /private/
Disallow: /search?
Sitemap: https://example.com/sitemap.xml
Utilisez des lignes vides entre les groupes de règles. Les commentaires avec `#` sont permis. Commentez vos choix : c'est utile quand vous revenez sur le fichier six mois plus tard.
Étape 3 : Testez et déployez
Suivez la méthode de test décrite plus haut. Une fois en ligne, vérifiez que le fichier est accessible et que vous n'avez pas cassé l'exploration de vos pages importantes.
La question du sitemap : à déclarer ou pas ?
Oui, toujours. La directive `Sitemap` dans robots.txt est un signal fort pour les moteurs de recherche. Elle indique l'emplacement exact de votre sitemap XML.Certains disent que ça n'a plus d'importance depuis que Google Search Console permet de soumettre directement le sitemap. C'est partiellement vrai pour Google, mais Bing et Yandex utilisent toujours cette directive. Et ça ne coûte rien.
J'ai vu des sites où le sitemap n'était pas déclaré et où l'exploration de nouvelles pages prenait des semaines. Après l'ajout de la directive, c'est passé à quelques jours.
Conclusion : laissez votre robots.txt tranquille, mais restez vigilant
Mon dernier conseil, et c'est le plus important : configurer robots.txt est un événement rare, pas une routine hebdomadaire. Une fois que vous l'avez bien configuré, vous n'y touchez plus.
Sauf circonstances particulières :
- Migration de site
- Lancement d'une nouvelle section
- Détection d'une fuite de données sensibles
- Attaque de crawlers IA
Et quand vous y touchez, faites-le avec la prudence d'un chirurgien : sauvegarde de l'ancien fichier, test préalable, déploiement progressif. Parce qu'un fichier `robots.txt` de 15 lignes peut faire plus de dégâts qu'une erreur de code sur 500 pages.
Un dernier point que je veux marteler, parce que je l'ai appris à la dure : quand vous bloquez un répertoire avec `Disallow: /dossier/`, vérifiez que le slash final est là. J'ai relu une centaine de fichiers après ma première erreur, et je vous garantis que c'est l'erreur la plus fréquente. Un simple slash, et tout bascule.
Sur ce, je retourne analyser les logs de mes serveurs. La mécanique du crawl, c'est comme la plomberie : on ne la remarque que quand elle fuit.
