Être alerté quand le robots.txt change

Une alerte de changement du robots.txt vous prévient quand les règles d'exploration d'un site ont été modifiées, pour qu'un Disallow: / égaré soit annulé avant de priver le site de son exploration. Le robots.txt est un simple fichier texte capable d'empêcher Googlebot de demander la moindre URL d'un domaine, et rien sur le site n'a l'air cassé quand cela arrive.

Le scénario classique se déroule ainsi. Un déploiement recopie la configuration de préproduction en production, le Disallow: / passe en ligne, et le site continue de se charger normalement, pour les visiteurs comme pour les outils de surveillance de disponibilité. Les impressions commencent à baisser dans la Search Console une ou deux semaines plus tard, et c'est seulement là que quelqu'un ouvre le fichier. Ce guide explique comment l'apprendre plus tôt. Pour lire et valider le fichier lui-même, commencez par comment vérifier le robots.txt.

Quelles modifications du robots.txt méritent une alerte

Beaucoup de modifications du robots.txt sont sans danger, comme un plugin qui ajoute une règle pour son propre chemin d'administration. Voici celles qui justifient d'agir le jour même.

Modification	Effet	Urgence
Disallow: / sous User-agent: *	Bloque toutes les URL pour tous les robots	À traiter comme un incident
Nouveau Disallow sur un répertoire de contenu comme /blog/ ou /products/	Retire toute une section de l'exploration	Le jour même
Nouveau groupe User-agent: Googlebot	Googlebot ne suit plus que ce groupe et ignore les règles de *	Le jour même, en lisant son contenu
Le fichier se met à renvoyer une erreur 5xx	Google suspend l'exploration, puis s'appuie sur une copie en cache	Le jour même
Fichier supprimé ou renvoyant un 404	Google considère le site comme sans restriction, et la ligne Sitemap: disparaît	À vérifier, rarement urgent
Ligne Sitemap: supprimée ou pointant vers une ancienne URL	Les nouvelles pages sont découvertes plus lentement	Faible
Règles ajoutées pour GPTBot, ClaudeBot, PerplexityBot ou Google-Extended	Bloque les robots d'IA, sans effet sur la recherche Google	Confirmer que c'était voulu

Le groupe Googlebot piège souvent ceux qui l'ajoutent. Quelqu'un crée pour Googlebot un groupe contenant un seul Disallow: /search et, comme Googlebot ignore désormais le groupe *, les règles sur /cart/ et /checkout/ qui s'appliquaient à lui ne s'appliquent plus. Recopiez l'ensemble des règles dans le nouveau groupe, sans quoi il sera plus permissif que prévu.

Le blocage des robots d'IA traduit parfois une décision de principe, et parfois un réglage par défaut activé par un plugin de sécurité ou SEO sans que personne l'ait validé. Dans les deux cas, le client doit être au courant.

Une page bloquée peut quand même être indexée

Le robots.txt contrôle l'exploration, le noindex contrôle l'indexation. Une URL bloquée dans le robots.txt peut quand même apparaître dans les résultats, généralement sans description, parce que Google la connaît par des liens sans avoir jamais eu le droit de la récupérer. La Search Console la classe en « Indexée malgré le blocage par le fichier robots.txt ».

Le piège consiste à combiner les deux. Mettez un noindex sur une page et bloquez-la aussi dans le robots.txt : Google n'explore jamais la page, ne lit jamais le noindex, et l'URL peut rester indexée. Pour retirer une page des résultats, laissez-la explorable et servez un noindex. Le guide sur la balise noindex couvre ce volet.

Ce que la Search Console vous dit, et quand

Le rapport robots.txt de la Search Console (Paramètres > robots.txt) affiche les versions récupérées par Google, leur date de récupération et le résultat : succès ou problèmes d'analyse. Il est utile pour diagnostiquer une fois que vous savez qu'il y a un souci, mais il ne vous envoie pas d'e-mail quand une ligne change. Le premier signal automatique est en général une hausse de « Bloquée par le fichier robots.txt » dans le rapport Pages, qui n'apparaît qu'une fois que Google a réexploré des URL avec les nouvelles règles. Google garde aussi le robots.txt en cache jusqu'à 24 heures, si bien que sa propre récupération peut avoir un jour de retard sur la modification.

Mettre en place une vérification simple vous-même

Avec quelques sites et un accès à un serveur, un petit script lancé toutes les heures par cron couvre l'essentiel :

#!/bin/sh
URL="https://example.com/robots.txt"
DIR="/var/lib/robots-watch"
mkdir -p "$DIR" && touch "$DIR/last.txt"
STATUS=$(curl -s -o "$DIR/new.txt" -w "%{http_code}" "$URL")
if [ "$STATUS" != "200" ]; then
  echo "robots.txt returned $STATUS" | mail -s "robots.txt error" you@example.com
  exit 1
fi
if ! cmp -s "$DIR/new.txt" "$DIR/last.txt"; then
  diff "$DIR/last.txt" "$DIR/new.txt" | mail -s "robots.txt changed" you@example.com
fi
mv "$DIR/new.txt" "$DIR/last.txt"

Il vérifie le code de statut en plus du contenu, ce qui a son importance, car un 5xx persistant est aussi grave qu'une mauvaise règle. Ses faiblesses apparaissent à mesure que la liste de sites s'allonge. Il faut une entrée par site et un envoi d'e-mails qui fonctionne, vous n'apprenez rien des changements de noindex ou de sitemap causés par le même déploiement, et personne ne remarque si la tâche cron cesse de tourner.

Recevoir l'alerte avec Deltio

Lors de sa vérification quotidienne, Deltio récupère le robots.txt de chaque site que vous ajoutez, le compare à la version de la vérification précédente et envoie une alerte sur Slack et par e-mail pour ce site quand il a changé. Le même passage contrôle le noindex, les canonical, les titles et les URL du sitemap : un déploiement de préproduction qui casse plusieurs choses à la fois arrive donc sous la forme d'un seul ensemble d'alertes. Les alertes de changement SEO détaillent tout ce qui est couvert.

La fréquence est la vraie limite. Avec une vérification quotidienne, une modification faite juste après un passage n'est signalée que le lendemain, alors qu'un script horaire comme celui ci-dessus la repérerait plus tôt. Compte tenu de la mise en cache du fichier par Google et du temps nécessaire à une nouvelle exploration, une alerte le jour même ou le lendemain arrive normalement avant que les dégâts ne se voient dans la Search Console.

Pour un premier site, choisissez celui qui vous inquiète le plus, qu'il s'agisse du site qui déploie le plus souvent ou de celui dont les développeurs vous tiennent le moins informé. Tous les plans comprennent un essai gratuit de 14 jours.