Robots.txt Checker

Ce qu'un vérificateur robots.txt fait réellement

Un vérificateur robots.txt récupère le fichier /robots.txt de votre domaine, analyse chaque bloc user-agent et règle disallow, puis teste si un chemin donné est autorisé ou bloqué pour un crawler spécifique. Il applique la règle la plus longue correspondante quand plusieurs motifs se chevauchent, suit l'ordre de priorité dans la spec, et signale si une URL de test serait crawlée.

La plupart des crawlers cherchent d'abord leur propre bloc user-agent. S'il existe, ils utilisent ces règles. Sinon, ils reviennent au bloc wildcard User-agent: *. Cela signifie qu'un site peut autoriser Googlebot dans /admin tout en bloquant tous les autres bots. Notre vérificateur simule cette cascade pour n'importe quel user-agent que vous choisissez dans le menu déroulant User-agent à tester.

Deux erreurs courantes cassent les fichiers robots.txt en silence. La première est les erreurs de syntaxe : espaces supplémentaires, deux-points manquants, fins de ligne Windows, ou "Disallow" en majuscules quand seul le minuscule fonctionne. La seconde est les règles conflictuelles-les lignes allow et disallow qui se chevauchent, rendant ambigü si un chemin est bloqué. Notre vérificateur signale les deux et montre quelle règle gagne.

Comment utiliser ce vérificateur robots.txt

1. Collez votre domaine complet dans Site URL. Nous récupérons automatiquement votredomaine.com/robots.txt. Pas besoin de taper /robots.txt.
2. Choisissez un User-agent à tester dans le menu déroulant. Googlebot, Bingbot, GPTBot, ClaudeBot, CCBot, PerplexityBot, anthropic-ai, ou * pour wildcard. C'est l'identité du crawler que nous simulons.
3. Collez un chemin dans Test path si vous voulez vérifier une URL spécifique. Laissez-le vide pour voir l'ensemble des règles parsé. Un chemin ressemble à /admin ou /blog/post-slug.
4. Cliquez sur Check robots.txt. Vous obtenez le fichier parsé, les règles par agent, les liens sitemap, le crawl-delay s'il est défini, et un verdict pour votre chemin de test.
5. Développez Rule conflicts si des lignes sont signalées. Nous affichons les lignes allow/disallow qui se chevauchent et vous disons laquelle un vrai crawler suivrait.

Essayez de tester votredomaine.com avec User-agent défini sur GPTBot et Test path défini sur /blog. Si votre robots.txt n'a pas de bloc GPTBot mais bloque tous les bots de /admin, le blog est autorisé et admin est bloqué. Changez le user-agent en ClaudeBot et le résultat pourrait changer si vous avez un bloc spécifique à ClaudeBot.

Pourquoi tester par user-agent est important

Les crawlers de recherche ne sont plus les seuls bots qui lisent robots.txt. Les crawlers d'entraînement IA-GPTBot d'OpenAI, ClaudeBot d'Anthropic, CCBot de Common Crawl, PerplexityBot, et Google-Extended-respectent maintenant robots.txt pour décider s'ils peuvent scraper votre contenu pour l'entraînement des modèles. Si vous les bloquez, vos pages restent hors des datasets d'entraînement. Si vous les autorisez, vous optez pour.

Trois conséquences pratiques.

Clarté des politiques. Un robots.txt qui dit User-agent: * / Disallow: / bloque tout le monde, y compris Google. Si ce n'est pas votre intention, vous avez besoin de blocs séparés par agent. Tester par user-agent révèle ce que chaque bot voit avant qu'un modèle s'entraîne sur votre contenu.

Contrôle du crawler IA. En 2026, la plupart des propriétaires de sites veulent les bots de recherche mais pas les bots d'entraînement. Cela nécessite des blocs disallow explicites pour GPTBot, ClaudeBot et CCBot. Les concurrents ignorent ces agents. Nous les testons par défaut parce qu'ils comptent.

Détection des conflits. Quand vous avez à la fois Disallow: /blog et Allow: /blog/public, la règle la plus spécifique gagne. Mais parser à la main quelle règle est la plus longue ou la plus spécifique est sujet à erreur. Tester montre exactement ce qu'un bot ferait, pas ce que vous pensez que le fichier dit.

Priorité des règles et wildcards

La spec robots.txt définit un ordre de priorité quand plusieurs règles correspondent au même chemin. La règle avec le préfixe correspondant le plus long gagne. Si deux règles ont la même longueur, la règle allow gagne sur disallow.

Les wildcards rendent cela plus difficile à voir. Une ligne comme Disallow: /admin* bloque /admin, /admin/users, et /admin-panel. Une ligne plus tard Allow: /admin/public l'annule pour ce seul dossier parce que /admin/public est plus long que /admin. Notre vérificateur évalue les deux et vous dit laquelle s'applique.

Le wildcard $ ancre la fin d'un chemin. Disallow: /*.pdf$ bloque tous les fichiers PDF mais permet /report.pdf.html parce que le chemin ne se termine pas par .pdf. Les concurrents parsent souvent $ incorrectement ou l'ignorent. Nous correspondons à l'implémentation Google.

Le nom du user-agent n'est pas sensible à la casse dans la spec, donc User-agent: googlebot et User-agent: Googlebot sont identiques. Les chemins Disallow sont sensibles à la casse sur la plupart des serveurs. /Admin et /admin sont des URLs différentes. Notre vérificateur respecte les deux règles.

Validation du sitemap et directives de crawl

Chaque fichier robots.txt devrait inclure au moins une ligne Sitemap: pointant vers votre fichier sitemap.xml. Cela dit aux crawlers où trouver la liste des URLs que vous voulez indexées. Notre vérificateur récupère chaque URL sitemap listée dans votre robots.txt et rapporte le code de statut HTTP. Si un sitemap retourne 404, les crawlers ne peuvent pas l'utiliser, et vous perdez un signal qui aide à la découverte.

Plusieurs déclarations de sitemap sont valides. Si vous avez des sitemaps séparés pour les posts, pages et produits, listez les trois. Si vous utilisez un index sitemap qui référence des sitemaps enfants, listez seulement l'index. Évitez de lister chaque sitemap enfant individuellement parce que cela encombre le fichier et duplique les informations déjà dans l'index.

La directive Crawl-delay: définit le nombre minimum de secondes qu'un bot devrait attendre entre les requêtes vers votre serveur. Googlebot ignore complètement cette directive et utilise son propre taux de crawl adaptatif basé sur le temps de réponse du serveur. Bingbot, Yandex et certains crawlers plus petits le respectent. Un crawl-delay de 1 seconde est sûr. Un délai de 10 ou plus arrête effectivement la plupart du crawling sur les grands sites. Ne l'utilisez que si votre serveur ne peut pas gérer les taux de crawl normaux.

Une directive moins courante est Request-rate:, qui définit un nombre de requêtes par fenêtre de temps. Peu de crawlers la supportent, et elle ne fait pas partie de la spec officielle. Si vous la voyez dans un robots.txt, c'est probablement du legacy ou non-standard. Notre vérificateur la note mais ne la force pas parce que le comportement du crawler varie.

Erreurs de syntaxe et cas limites de validation

La syntaxe robots.txt est inflexible. Un seul espace mal placé ou une tabulation peut invalider une règle. Le nom de la directive-User-agent, Disallow, Allow, Sitemap, Crawl-delay-doit être suivi d'un deux-points sans espace avant et au moins un espace ou une tabulation après. Disallow:/admin échoue. Disallow: /admin fonctionne. Notre vérificateur signale les problèmes d'espacement et suggère des correctifs.

Les fins de ligne Windows-\r\n au lieu de \n-causent des problèmes sur certains serveurs. Quand un fichier robots.txt est édité sous Windows et uploadé sans conversion, les bots peuvent mal lire les sauts de ligne et traiter plusieurs lignes comme une. Notre vérificateur détecte les fins de ligne non-Unix et les rapporte comme un avertissement.

Les commentaires dans robots.txt commencent par #. Tout ce qui suit le # sur cette ligne est ignoré. Une erreur courante est de commenter accidentellement une directive : # Disallow: /admin ne fait rien. Si vous voyez des règles qui devraient s'appliquer mais ne s'appliquent pas, cherchez les caractères # errants.

Les lignes vides séparent les blocs user-agent. Une ligne vide termine le bloc actuel, et le prochain User-agent: en commence un nouveau. Si vous avez User-agent: Googlebot, Disallow: /private, puis une ligne vide, puis Allow: /public, la règle allow ne s'applique pas à Googlebot-elle commence un nouveau bloc sans user-agent, ce qui est invalide. Notre vérificateur signale les directives orphelines et suggère de les grouper sous le bon user-agent.

Erreurs courantes

• Bloquer Googlebot par accident. Un bloc User-agent: * avec Disallow: / bloque chaque bot, y compris Google. Si vous voulez que Googlebot entre, ajoutez un bloc User-agent: Googlebot séparé avec Allow: / avant le bloc wildcard. L'ordre compte.
• Oublier la barre oblique de tête. Disallow: admin ne fait rien. Ça doit être Disallow: /admin. Notre vérificateur signale ceci comme une probable erreur de syntaxe.
• Tester uniquement Googlebot. Votre robots.txt pourrait autoriser Google mais bloquer Bingbot ou GPTBot sans que vous le remarquiez. Testez tous les agents qui vous importent, pas juste un.
• Laisser de côté les crawlers IA. Si votre fichier n'a pas de bloc GPTBot ou ClaudeBot, ces bots reviennent à User-agent: *. Cela pourrait les autoriser quand vous pensiez que tout était bloqué. Les blocs explicites par agent rendent la politique sans ambiguïté.
• Supposer que les liens sitemap sont validés ailleurs. Une URL sitemap dans robots.txt peut être cassée, retourner 404, ou pointer vers un fichier XML qui n'existe plus. Notre vérificateur teste le lien et rapporte le code de statut.

Conseils avancés

• Testez le même chemin par rapport à plusieurs user-agents en succession. Si le résultat change, vos blocs par agent fonctionnent. Si ça reste le même, vous vous appuyez peut-être uniquement sur le bloc wildcard.
• Vérifiez la ligne Crawl-delay si présente. Googlebot l'ignore, mais Bingbot et certains autres la respectent. Un délai de 10 secondes peut ralentir un crawl à quasi-arrêt sur les grands sites.
• Regardez les lignes Sitemap. Plusieurs déclarations de sitemap sont valides. Si vous avez un index sitemap, listez-le une fois plutôt que de répéter chaque sous-sitemap. Nous récupérons chaque lien et confirmons qu'il retourne HTTP 200.
• Testez un chemin avec des paramètres de requête. Disallow: /search bloque /search?q=test sur la plupart des serveurs, mais Disallow: /search$ ne le ferait pas parce que $ s'attend à aucun caractère de fin. Si vous voulez bloquer les chaînes de requête, utilisez l'astérisque : Disallow: /search*.
• Téléchargez la sortie parsée comme référence. Quand vous régénérez robots.txt ou changez de CMS, re-vérifiez par rapport aux mêmes chemins de test pour confirmer que le comportement n'a pas changé.
• Utilisez le rapport de conflit avant de déployer un nouveau robots.txt. Si deux règles se chevauchent, votre interprétation locale pourrait différer de celle de Googlebot. Tester élimine les suppositions.

Si vous avez besoin de générer un nouveau fichier robots.txt à partir de zéro avec des presets pour WordPress, Shopify, ou Next.js, utilisez notre générateur de fichier robots.txt. Il inclut des bascules explicites pour les crawlers IA et produit un fichier prêt pour la production avec une syntaxe garantie valide. Après le déploiement, re-vérifiez-le avec cet outil. Si vous voulez voir comment Googlebot rend la page après avoir respecté robots.txt et exécuté JavaScript, le simulateur de crawler Google affiche le HTML exact et le texte visible qu'un bot indexe. Pour confirmer que chaque URL de votre sitemap est accessible et retourne 200, utilisez le vérificateur de sitemap.