Comment auditer son robots.txt en 5 minutes

La plupart des propriétaires de sites n'ont aucune idée de ce que dit leur robots.txt actuel. Ils l'ont configuré une fois — ou n'y ont jamais touché — et partent du principe qu'il fonctionne correctement. Un audit de cinq minutes peut révéler si le fichier aide le SEO, ne fait rien d'utile, ou cause activement des dommages.

Voici la liste de vérification.

Étape 1 : vérifier que le fichier existe et est servi correctement (30 secondes)

Ouvrir le navigateur et naviguer vers votredomaine.com/robots.txt. On devrait voir un fichier texte brut avec des directives robots.txt reconnaissables : User-agent, Disallow, Allow, Sitemap.

Si on voit une erreur 404, le site n'a pas de robots.txt. Cela signifie que chaque robot a un accès complet à tout.

Si on voit le HTML de la page d'accueil au lieu d'un fichier texte, WordPress ne génère pas de robots.txt virtuel, ou un plugin ou une configuration serveur intercepte la requête.

Si on voit le fichier mais qu'il ne contient que le défaut WordPress (User-agent: * et Disallow: /wp-admin/), la politique de crawl est effectivement inexistante.

Étape 2 : chercher les blocages accidentels de contenu important (60 secondes)

Lire chaque règle Disallow et se demander : est-ce que ce patron correspond à une page que je veux voir indexée ?

Les accidents courants incluent :

Un Disallow pour /category/ qui retire toutes les archives de catégories de la recherche. Un Disallow pour /page/ qui correspond aux archives paginées mais aussi à des pages légitimes avec « page » dans l'URL. Un Disallow pour /wp-content/ qui bloque le rendu CSS et JavaScript. Un problème de barre oblique finale : Disallow: /blog bloque /blog, /blog/, et /blog/nimportequoi, tandis que Disallow: /blog/ ne bloque que les chemins sous /blog/.

En cas de doute, utiliser le testeur robots.txt de Google dans Search Console ou simplement chercher site:votredomaine.com inurl:patron pour voir quelles pages correspondent.

Étape 3 : vérifier les règles pour les robots IA (30 secondes)

Chercher dans le fichier les chaines d'agent suivantes : GPTBot, ClaudeBot, CCBot, Google-Extended, Bytespider, Applebot-Extended, PerplexityBot, FacebookBot, Amazonbot.

Si aucune n'apparait, le robots.txt ne fait aucune distinction entre les robots de moteurs de recherche et les robots IA. Chaque robot IA a le même accès que Googlebot. C'est un choix délibéré si c'est intentionnel, mais un oubli si ça ne l'est pas.

Si certains apparaissent mais pas d'autres, vérifier si les manquants comptent pour le site. De nouveaux robots IA apparaissent régulièrement, et un fichier mis à jour pour la dernière fois en 2024 manque probablement des agents actifs en 2026.

Étape 4 : vérifier la directive Sitemap (15 secondes)

Chercher une ligne commençant par Sitemap: suivie d'une URL. Si elle est absente, l'ajouter. Si elle est présente, vérifier que l'URL fonctionne réellement en l'ouvrant dans le navigateur. Une directive Sitemap pointant vers un 404 est pire qu'aucune directive, parce qu'elle envoie explicitement les robots vers un cul-de-sac.

Étape 5 : chercher les contradictions (60 secondes)

Trois contradictions courantes à rechercher :

Des URL interdites qui apparaissent dans le sitemap. Ouvrir le sitemap et chercher tout chemin qui est aussi interdit dans le robots.txt. Si des correspondances existent, on invite et on bloque simultanément les robots du même contenu.

Une règle Disallow: / sous User-agent: * qui bloque tout. C'est parfois configuré pendant le développement et oublié. Ça retire tout le site de l'accès au crawl de tous les moteurs de recherche.

Des règles multiples pour le même agent qui se contredisent. Un Allow pour /blog/ combiné à un Disallow pour /blog/category/ est correct (la règle la plus spécifique gagne). Mais un Allow pour / combiné à un Disallow pour / sur le même agent est ambigu.

Étape 6 : vérifier la fraicheur (15 secondes)

Quand le robots.txt a-t-il été mis à jour pour la dernière fois ? Si le site a changé significativement — nouveaux types de contenu, nouveaux plugins, une boutique WooCommerce ajoutée, une migration de HTTP à HTTPS — le robots.txt devrait refléter ces changements.

Un robots.txt écrit pour un site vitrine de 50 pages ne sert pas un site de contenu de 5 000 pages. Un robots.txt qui date d'avant l'ère des robots IA n'adresse pas GPTBot, ClaudeBot, ni aucun des agents apparus depuis 2023.

Que faire avec les résultats

Si l'audit a révélé des problèmes, deux chemins sont possibles. On peut modifier manuellement le fichier et redéployer, ce qui nécessite de comprendre la syntaxe robots.txt et de tester chaque changement. Ou on peut utiliser un outil comme Better Robots.txt qui génère le fichier à partir d'une configuration guidée, avec une étape de prévisualisation qui montre exactement ce qui changera avant la mise en ligne.

Dans les deux cas, les cinq minutes passées à lire le fichier actuel sont les cinq minutes les plus précieuses du cycle de maintenance SEO technique. Un robots.txt mal configuré peut endommager silencieusement l'indexation, l'efficacité du crawl et la posture de gouvernance IA — et la seule façon de le détecter est de regarder.