Comment vérifier votre robots.txt (et la ligne qui désindexe un site)

Pour vérifier votre robots.txt, ouvrez https://votresite.fr/robots.txt dans un navigateur, lisez chaque groupe User-agent et repérez toute règle Disallow qui couvre des pages que vous voulez voir dans les résultats, à commencer par un Disallow: / isolé. Sur un petit site, cela prend une minute. Confirmez ensuite ce que Google a réellement récupéré dans le rapport robots.txt de la Search Console, car le fichier que vous voyez et celui que Googlebot a reçu ne sont pas toujours identiques.

La plupart des fichiers robots.txt tiennent en quelques lignes, et c'est justement pour cela que presque personne ne les lit. Ils s'appliquent pourtant à tout l'hôte : une seule ligne erronée touche chaque URL.

Exploration, pas indexation

Le robots.txt indique aux robots quelles URL ils peuvent demander. Il ne décide pas de ce qui apparaît dans les résultats de recherche. Une URL bloquée dans le robots.txt peut quand même être indexée si d'autres pages font un lien vers elle ; Google l'affiche alors sans description, et la Search Console la classe en « Indexée malgré le blocage par le fichier robots.txt ».

Ce point compte dès qu'on se sert du robots.txt pour cacher des pages. Si vous bloquez une page et que vous lui ajoutez aussi un noindex, Google ne peut pas l'explorer, ne voit jamais le noindex, et l'URL peut rester dans l'index. Pour retirer une page des résultats, laissez-la explorable et servez un noindex. La balise noindex expliquée traite ce volet.

Où trouver le fichier

Le robots.txt se trouve toujours à la racine d'un hôte, par exemple https://example.com/robots.txt. Ses règles ne valent que pour le protocole, l'hôte et le port qui le servent : https://shop.example.com a donc besoin de son propre fichier.

Sur beaucoup de plateformes, il n'y a aucun fichier physique à ouvrir. WordPress génère un robots.txt virtuel tant que vous n'en déposez pas un vrai à la racine du site, et des plugins SEO comme Yoast et Rank Math permettent de le modifier depuis l'administration. Shopify sert un fichier par défaut que vous pouvez personnaliser en ajoutant un template robots.txt.liquid au thème. Si vous vous connectez en FTP sans trouver le fichier, la raison est généralement là.

Lire le fichier ligne par ligne

Un robots.txt se compose de groupes. Chaque groupe commence par une ou plusieurs lignes User-agent, suivies de ses règles :

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /*?s=
Disallow: /cart/

User-agent: GPTBot
Disallow: /

Sitemap: https://example.com/sitemap_index.xml

Lu de haut en bas, cet exemple tient tous les robots à l'écart de /wp-admin/, sauf admin-ajax.php, ainsi que des résultats de recherche interne (?s=) et du panier. GPTBot a son propre groupe et n'a accès à rien. La ligne Sitemap n'appartient à aucun groupe et vaut pour l'ensemble du fichier.

Quelques règles d'interprétation expliquent la plupart des surprises. Un robot n'obéit qu'au groupe le plus spécifique qui correspond à son nom. Googlebot ne trouve ici aucun groupe User-agent: Googlebot, il applique donc * ; s'il existait un groupe Googlebot, il ignorerait complètement les règles de * au lieu de les combiner. Les chemins sont sensibles à la casse : /Blog/ et /blog/ sont deux règles différentes. * correspond à n'importe quelle suite de caractères et $ marque la fin de l'URL, si bien que Disallow: /*.pdf$ bloque les PDF et rien d'autre. Quand un Allow et un Disallow correspondent tous deux à une URL, Google suit la règle la plus longue, donc la plus précise. Un Disallow: vide ne bloque rien du tout.

Google ignore les lignes Crawl-delay et Noindex du robots.txt. Bing, lui, respecte Crawl-delay.

Les deux lignes qui bloquent tout un site

User-agent: *
Disallow: /

Ces deux lignes demandent à tous les robots de ne toucher à aucune URL. C'est la configuration normale d'un site de préproduction ou de développement, et c'est exactement ainsi qu'elle se retrouve sur des sites en ligne : un déploiement recopie le fichier de préproduction, ou une migration embarque toute la configuration. WordPress cache un piège voisin. Cocher « Demander aux moteurs de recherche de ne pas indexer ce site » dans Réglages > Lecture ajoute, dans les versions actuelles, une balise meta robots noindex sur chaque page. Après un lancement, mieux vaut donc contrôler à la fois le fichier et le code source des pages.

Les visiteurs ne remarquent rien. Les pages se chargent, les formulaires s'envoient, la surveillance de disponibilité reste au vert. L'exploration ralentit et, dans les semaines qui suivent, les pages sortent des résultats.

Vérifier votre robots.txt en six étapes

1. Ouvrez directement /robots.txt et regardez le code HTTP en plus du contenu. L'onglet Réseau des DevTools de Chrome l'affiche. Vous devez obtenir un 200 et les règles attendues.
2. Cherchez dans le fichier un Disallow: / seul, ainsi que des règles portant sur des répertoires qui contiennent des pages à positionner, comme /blog/, /products/ ou /category/.
3. Vérifiez que la ligne Sitemap: pointe vers un sitemap qui se charge et qui est bien l'actuel, pas un reste d'un ancien plugin.
4. Dans la Search Console, ouvrez Paramètres > robots.txt. Le rapport liste les fichiers robots.txt trouvés par Google pour les principaux hôtes de la propriété, la date de dernière exploration de chacun, l'état de la récupération et les lignes qu'il n'a pas pu analyser. Après avoir corrigé un problème urgent, vous pouvez y demander une nouvelle exploration.
5. Pour une URL précise, utilisez l'outil Inspection de l'URL. Si l'URL est bloquée, la section consacrée à l'indexation de la page indique « Bloquée par le fichier robots.txt ».
6. Sur un site plus important, lancez un crawler comme Screaming Frog dans son mode par défaut, qui respecte le robots.txt, et passez en revue les URL qu'il signale comme bloquées.

Google a retiré l'ancien outil de test du fichier robots.txt en 2023 : les guides qui vous y renvoient ne sont plus à jour.

Le code de statut compte autant que les règles. Google traite un 404, ou tout autre code 4xx à l'exception du 429, comme s'il n'existait pas de robots.txt, ce qui signifie que tout peut être exploré. Un 5xx est traité autrement : Google interrompt l'exploration pendant un temps, puis se rabat sur une copie en cache tout en continuant d'essayer. Google garde aussi le fichier en cache jusqu'à 24 heures et n'en lit que les 500 premiers Kio ; dans un fichier exceptionnellement long, les règles placées au-delà sont ignorées.

Savoir quand le fichier change

Chacune de ces vérifications vous dit ce que contient le robots.txt aujourd'hui. Aucune ne vous apprend qu'un plugin l'a réécrit mardi ou qu'un changement d'hébergement a restauré une ancienne version. Sur un seul site, vous pouvez le rouvrir après chaque mise en production. Sur un portefeuille de clients où les développeurs déploient sans prévenir, vous ne le ferez pas, et le premier signe d'une mauvaise modification est souvent une baisse de l'exploration dans la Search Console, des semaines plus tard. Le guide des alertes de changement du robots.txt détaille les modifications qui méritent une alerte.

Deltio récupère le robots.txt de chaque site client lors de sa vérification quotidienne, le compare à la version précédente et envoie une alerte Slack ou e-mail pour ce site quand il a changé. Le même passage contrôle le noindex, les canonical et les URL du sitemap, car un déploiement de préproduction en casse souvent plusieurs à la fois. La vérification étant quotidienne, une modification est signalée le jour même ou le lendemain, pas en quelques minutes. Les alertes de changement SEO expliquent comment ces alertes sont définies, et un essai gratuit de 14 jours vous permet d'ajouter un site.