Comment vérifier le fichier robots.txt d’un site
Comment vérifier si un site web possède un fichier robots.txt
Un fichier robots.txt est un petit fichier texte qui donne des consignes d’exploration aux robots qui choisissent de les respecter. Le consulter peut vous aider à comprendre quelles sections d’un site certains robots sont invités à explorer ou à éviter. Il ne révèle pas tous les paramètres du site et ne constitue pas une barrière de sécurité.
Si vous vous demandez comment vérifier si un site web possède un fichier robots.txt, commencez par identifier son origine exacte, puis examinez la réponse du serveur et le contenu du fichier. Ces détails sont importants : un fichier présent sur un sous-domaine ne renseigne pas forcément sur un autre, et une erreur affichée par le navigateur ne signifie pas toujours que le fichier est absent.
1. Comprendre ce que robots.txt peut — ou ne peut pas — vous apprendre
Le fichier robots.txt contient des règles destinées aux robots d’exploration automatisés. Une règle peut demander à un robot d’indexation respectueux des consignes de ne pas explorer un chemin comme /private/. Il s’agit d’une demande, pas d’un mécanisme de contrôle d’accès : un visiteur peut toujours ouvrir cette URL, et un robot peut ignorer la consigne.
Le fichier ne garantit pas non plus qu’une page bloquée sera exclue des résultats de recherche. Un moteur de recherche peut découvrir une URL grâce à des liens publiés ailleurs et l’afficher sans en explorer le contenu. Si une page doit rester privée, protégez-la avec un véritable contrôle d’accès, par exemple une authentification, plutôt que de vous fier à robots.txt.
Considérez ce fichier comme un ensemble public d’indications. Il peut aider à comprendre le comportement d’exploration, mais ne permet pas de confirmer qu’une page est accessible, privée ou indexée. Vérifiez ces points séparément.
2. Trouver le fichier robots.txt à la bonne origine
Pour un site à l’adresse https://example.com, le fichier se trouve généralement à l’adresse https://example.com/robots.txt. Pour savoir comment trouver le fichier robots.txt d’un site, conservez le protocole et le nom d’hôte affichés dans la barre d’adresse, et ajoutez le port s’il ne s’agit pas du port par défaut. Le chemin se trouve à la racine de cette origine, et non dans un dossier comme /blog/.
Changer de protocole ou de nom d’hôte peut donner des résultats différents. Par exemple, http://example.com/robots.txt и https://example.com/robots.txt correspondent à des requêtes distinctes, même si l’une redirige vers l’autre. De même, www.example.com и example.com peuvent être configurés séparément.
Les sous-domaines ont leurs propres origines. Un fichier situé à https://shop.example.com/robots.txt ne s’applique pas automatiquement à https://example.com/ ou https://help.example.com/. Vérifiez l’hôte qui vous intéresse, surtout si une entreprise héberge sa boutique, son service d’assistance et son site principal sur des sous-domaines différents.
Pour une première vérification, utilisez la barre d’adresse : saisissez l’URL complète du fichier robots.txt et examinez le résultat. Une page en texte brut est courante, mais une présentation mise en forme par le navigateur convient aussi. L’essentiel est de savoir quelle URL vous avez demandée et quelle réponse le serveur a renvoyée.
3. Examiner la réponse, pas seulement la page affichée par le navigateur
Une réponse réussie signifie généralement que le serveur a renvoyé du contenu pour cette URL. De nombreux sites renvoient un code d’état HTTP tel que 200, mais le texte affiché peut contenir des règles, être vide ou même correspondre à une page inattendue. Examinez le contenu et le code d’état ensemble : ne considérez pas l’affichage d’une page comme une preuve que le fichier robots.txt est valide.
Une réponse indiquant que la page est introuvable, souvent 404, suggère que le chemin demandé n’existe pas sur cette origine à ce moment-là. Pour comprendre que signifie une erreur 404 sur robots.txt, vérifiez d’abord le nom d’hôte et les redirections : une faute de frappe ou un autre sous-domaine peut produire le même résultat.
Les redirections méritent une attention particulière. L’URL demandée peut renvoyer vers un autre hôte ou chemin, dont le contenu peut dépendre d’une origine différente. Notez l’URL d’origine et l’adresse finale avant de déterminer les consignes du site que vous avez consultées.
Les erreurs d’accès et les défaillances du serveur ne signifient pas la même chose que l’absence du fichier. Une réponse 403 peut indiquer que le serveur a refusé la requête ; une réponse 5xx peut signaler un problème temporaire du serveur. Un délai d’attente dépassé ou une erreur de connexion du navigateur peut également empêcher la vérification. Réessayez plus tard ou utilisez une autre méthode avant de tirer une conclusion définitive.
Pour une autre vérification de site, vous pouvez aussi lire comment vérifier si un site web publie une déclaration concernant les liens d’affiliation ; cette vérification porte sur une politique visible, et non sur les consignes destinées aux robots.
4. Vérifier les directives de robots.txt pour le robot qui vous intéresse
Pour savoir comment vérifier les règles d’un fichier robots.txt, lisez chaque groupe de règles dans son contexte. Une ligne User-agent désigne un robot d’exploration, tandis que les lignes Disallow et Allow précisent les chemins que ce robot est invité à ne pas explorer ou qu’il peut explorer. L’interprétation exacte peut dépendre du robot : consultez sa documentation si le résultat est important.
Par exemple, un groupe commençant par User-agent: ExampleBotpeut ne s’appliquer qu’au robot nommé. Un groupe distinct avec User-agent: * est destiné aux robots qui ne disposent pas d’un groupe plus spécifique. Ne partez pas du principe qu’une règle visant un robot s’applique à tous les moteurs de recherche ou aux autres services automatisés.
Les chemins comptent aussi. Une règle visant /images/ n’est pas équivalente à une règle visant /, et une règle pour /drafts/ ne couvre pas nécessairement un chemin au nom similaire situé ailleurs. Avant d’appliquer une règle à une URL, vérifiez le chemin complet et le groupe auquel elle appartient.
Considérez un fichier qui contient Disallow: /private/sous un groupe général de user-agent. Cette consigne demande aux robots concernés d’éviter d’explorer les chemins situés sous ce répertoire. Elle n’empêche pas quelqu’un d’ouvrir une URL connue et ne prouve pas que tous les robots la respecteront.
Certains fichiers comportent des commentaires, des lignes vides ou des règles destinées à des services particuliers. Concentrez-vous sur le groupe user-agent correspondant à votre question, puis consultez les règles publiées par le robot pour savoir comment il traite les directives qui se chevauchent ou qui sont inhabituelles. Si vous vérifiez un moteur de recherche en particulier, sa documentation est la référence à consulter pour comprendre son comportement.
5. Faire la différence entre un fichier vide, absent ou invalide
Une réponse vide et un fichier absent sont deux constats différents. Si le serveur renvoie une réponse réussie sans texte visible, le fichier existe peut-être, mais ne contient aucune directive. Si le serveur renvoie un code d’état indiquant que la page est introuvable, il n’a pas trouvé de fichier à l’URL demandée. Notez le code d’état et le corps de la réponse afin de ne pas confondre ces deux situations.
Un contenu inattendu mérite un examen supplémentaire. Une page contenant un message d’erreur général du site, un écran de connexion ou du code HTML peut indiquer que la requête a abouti à une page de secours plutôt qu’à un fichier robots.txt classique. L’URL peut se charger correctement tout en renvoyant un contenu qui ne fournit pas de consignes utiles aux robots.
Ne cherchez pas à deviner le sens de lignes mal formées ou inhabituelles. Enregistrez la réponse exacte et comparez-la à la documentation du robot concerné. Si le fichier change entre deux vérifications, notez l’heure : une réponse ultérieure peut correspondre à une version corrigée plutôt qu’au même contenu.
6. Vérifier les résultats avec une deuxième méthode
Si le résultat affiché dans le navigateur n’est pas clair, envoyez une requête depuis la ligne de commande. Par exemple, curl -i https://example.com/robots.txt permet d’afficher les en-têtes de réponse et le corps renvoyé en une seule requête. Remplacez l’adresse d’exemple par l’origine exacte que vous vérifiez, en précisant le bon sous-domaine et le port, le cas échéant.
Les outils de développement du navigateur offrent une autre possibilité. Ouvrez l’onglet Réseau, chargez l’URL de robots.txt, puis sélectionnez la requête pour examiner son statut, ses en-têtes et son corps. Cette méthode est utile lorsqu’un navigateur affiche une redirection ou une page mise en forme sans indiquer clairement la destination finale.
Si les méthodes donnent des résultats différents, comparez l’URL exacte, l’heure, le code d’état, les redirections et le contenu. Une requête en ligne de commande et une requête effectuée dans un navigateur peuvent suivre des redirections différentes ou rencontrer un problème temporaire du serveur. Si vous utilisez un proxy d’entreprise, un VPN ou une extension de navigateur, effectuez un test sans cet intermédiaire si cela s’avère pertinent : une réponse différente peut révéler l’intervention d’un intermédiaire plutôt qu’un problème sur le site lui-même.
Autre exemple de vérification de site : comment vérifier si un site webaffiche une mention de droits d’auteur. Ne confondez pas cette vérification avec celle de robots.txt : la première porte sur une déclaration destinée aux lecteurs, tandis que le second est un fichier destiné aux robots d’exploration.
7. Noter la portée et les limites de la vérification
Notez l’URL exacte du fichier robots.txt, la date et l’heure de la requête, le code d’état HTTP, la destination de toute redirection et le contenu affiché. Si vous interprétez un groupe de directives en particulier, précisez également le robot ou le user-agent concerné. Ces informations permettent de reproduire la vérification si le site change.
Limitez la portée de votre conclusion. Une réponse réussie montre ce que le serveur a renvoyé pour une origine donnée à un instant précis ; elle ne prouve pas qu’une page est indexée, accessible à tous les visiteurs ou bloquée pour tous les robots. Une réponse indiquant que le fichier est introuvable ne concerne que l’URL demandée, et non automatiquement toutes les versions du site utilisant un sous-domaine ou un protocole différent.
Le fichier robots.txt peut changer sans préavis. Si votre décision dépend des règles en vigueur, vérifiez à nouveau l’origine exacte et conservez la nouvelle réponse au lieu de vous fier à une ancienne copie.
