Pourquoi Google refuse-t-il de lire un fichier Robots.txt avec une majuscule ?

Quelle est l'origine de cette exigence de casse ?

Le protocole d'exclusion des robots (REP) a été formalisé en 1994 par Martijn Koster, et la spécification originale imposait robots.txt en minuscules strictes. Cette convention technique découle des systèmes Unix de l'époque, où les noms de fichiers sont sensibles à la casse.

Google perpétue cette règle non par archaïsme, mais par respect de la norme RFC 9309 publiée en septembre 2022. Le moteur ne fait aucune tolérance : un fichier nommé Robots.txt, ROBOTS.TXT ou RoBots.TxT sera tout simplement ignoré comme s'il n'existait pas. Googlebot cherchera uniquement /robots.txt à la racine du domaine.

Comment les serveurs web réagissent-ils face à cette contrainte ?

La sensibilité à la casse dépend du système d'exploitation du serveur. Sur Linux/Unix, robots.txt et Robots.txt sont deux fichiers distincts. Sur Windows/IIS, le système de fichiers NTFS est insensible à la casse par défaut, mais Apache ou Nginx servent exactement le fichier demandé.

Ce décalage crée des situations perverses : un administrateur Windows peut créer Robots.txt, le tester en local avec succès, mais constater que Googlebot ne le trouve pas en production. L'erreur est silencieuse, aucune alerte dans Search Console ne signale explicitement cette confusion de casse.

Quelles sont les conséquences pratiques d'une mauvaise casse ?

Un fichier robots.txt mal nommé équivaut à une absence totale de fichier. Googlebot interprétera cette absence comme une autorisation universelle de crawl. Toutes vos directives Disallow, User-agent spécifiques, ou références au sitemap XML seront perdues.

Concrètement, des pages sensibles (staging, admin, paramètres de session) peuvent être crawlées et indexées. Le crawl budget peut être gaspillé sur des URL inutiles. Et si vous bloquez des ressources CSS/JS via robots.txt pour des tests, cette protection disparaît instantanément.

• robots.txt (minuscules strictes) : seule version reconnue par Google
• Robots.txt, ROBOTS.TXT : ignorés totalement, aucun message d'erreur
• Sensibilité serveur : Linux/Unix distingue la casse, Windows IIS peut masquer le problème localement
• Search Console : l'outil de test robots.txt fonctionne uniquement si le fichier est correctement nommé
• Impact crawl : absence = autorisation totale, perte de toutes les directives

Cette déclaration est-elle cohérente avec les observations terrain ?

Absolument. Les tests confirment que Google applique cette règle sans exception ni délai de grâce. Un audit de migration montre régulièrement des sites qui perdent leurs restrictions de crawl après un changement de serveur, simplement parce que le nouveau sysadmin a créé le fichier avec une majuscule initiale.

Le comportement est identique sur tous les User-agents Google (Googlebot, Googlebot-Image, Google-InspectionTool). La casse stricte n'est pas une préférence technique, c'est une conformité RFC obligatoire. Bing, pour info, applique la même règle — aucun moteur majeur ne fait de tolérance.

Quelles nuances faut-il apporter à cette règle apparemment simple ?

La simplicité apparente cache des pièges de configuration serveur. Certains hébergements mutualisés Windows servent le fichier quelle que soit la casse demandée, ce qui donne une fausse impression de compatibilité. Un test manuel dans un navigateur ne suffit donc pas.

Autre subtilité : les redirections 301 vers robots.txt. Si /Robots.txt redirige vers /robots.txt, Google suivra cette redirection et lira le fichier correct. Mais cette béquille introduit une latence inutile et consomme du crawl budget. Mieux vaut corriger la source. [A vérifier] si Google tolère les redirections permanentes sans pénalité de temps de réponse dans tous les contextes.

Dans quels cas cette règle peut-elle poser problème en pratique ?

Les migrations de CMS génèrent des erreurs récurrentes. Un export WordPress vers un serveur IIS peut créer automatiquement Robots.txt si le script utilise des conventions .NET. Les systèmes de déploiement CI/CD qui créent les fichiers via scripts doivent explicitement forcer la casse minuscule.

Les environnements multi-domaines avec fichiers robots.txt générés dynamiquement doivent vérifier que le template respecte la casse. Un seul domaine mal configuré dans un pool de 50 sites peut passer inaperçu pendant des mois, jusqu'à ce qu'une indexation massive de pages staging signale le problème.

Comment vérifier que votre fichier robots.txt est correctement nommé ?

Première étape : tester l'URL exacte https://votredomaine.com/robots.txt (minuscules strictes) dans un navigateur en navigation privée. Le fichier doit s'afficher avec un Content-Type text/plain et un statut HTTP 200. Si vous obtenez une 404, le fichier n'existe pas ou est mal nommé.

Ensuite, testez avec une majuscule : https://votredomaine.com/Robots.txt. Si cette URL fonctionne aussi, votre serveur est insensible à la casse (typique Windows IIS), mais Google cherchera uniquement la version minuscule. Vous devez donc renommer le fichier en SSH/FTP ou via votre panneau d'hébergement.

Quelles erreurs éviter lors de la création ou modification du fichier ?

Ne jamais créer le fichier via un éditeur Windows qui pourrait imposer une extension cachée (.txt.txt) ou une casse par défaut. Utilisez un éditeur de code avec encodage UTF-8 sans BOM. Vérifiez les permissions Unix (644 minimum) pour garantir la lecture par le serveur web.

Les systèmes de cache CDN (Cloudflare, Fastly) peuvent servir une ancienne version du fichier si vous renommez sans purger le cache. Après toute modification de casse, forcez une purge complète du cache et attendez 5-10 minutes avant de tester avec l'outil Search Console.

Comment s'assurer de la conformité sur l'ensemble d'un parc de sites ?

Pour une infrastructure multi-sites, scripter un contrôle automatisé via curl ou wget qui vérifie la présence de /robots.txt (minuscules) et l'absence de /Robots.txt. Intégrer ce check dans les pipelines CI/CD pour bloquer un déploiement non conforme.

Les agences gérant des portefeuilles clients doivent auditer systématiquement la casse du fichier lors de la prise en main. Un simple script Python peut tester 100 domaines en quelques minutes et signaler les anomalies de nomenclature avant qu'elles n'impactent le crawl.

• Tester manuellement https://domaine.com/robots.txt (minuscules) → statut 200 attendu
• Tester https://domaine.com/Robots.txt → doit retourner 404 idéalement
• Vérifier l'encodage UTF-8 sans BOM et les permissions Unix 644
• Purger le cache CDN après tout renommage de fichier
• Valider le contenu via l'outil robots.txt de Search Console
• Automatiser la vérification de casse dans les scripts de déploiement CI/CD