Robots.txt bloqué : Googlebot respecte-t-il vraiment vos interdictions de crawl ?

Pourquoi cette nuance sur le timing du robots.txt change tout ?

La plupart des SEO pensent que modifier leur robots.txt bloque instantanément Googlebot. C'est faux. Google utilise une version en cache de votre fichier robots.txt pendant un délai variable.

Entre le moment où vous modifiez le fichier et celui où Google le recrawle, l'ancien fichier reste la référence. Pendant ce laps de temps, Googlebot continue d'appliquer les anciennes règles. Si vous venez de bloquer /admin/ mais que Google n'a pas encore recrawlé robots.txt, vos pages admin continuent d'être explorées.

Combien de temps dure ce décalage entre modification et prise en compte ?

Google ne communique aucun SLA précis sur la fréquence de crawl du robots.txt. Sur des sites à fort crawl budget, le fichier peut être vérifié plusieurs fois par jour. Sur des petits sites, ça peut prendre plusieurs jours, voire une semaine.

Le problème majeur : vous n'avez aucune garantie de timing. Un site qui bloque d'urgence une zone sensible peut continuer à la voir crawlée pendant 48h ou plus. C'est particulièrement critique pour les sites e-commerce qui doivent bloquer temporairement des sections en restructuration ou pour éviter le gaspillage de crawl budget sur des facettes.

Comment Google gère-t-il concrètement le cache de robots.txt ?

Googlebot maintient une copie en mémoire du robots.txt pour chaque domaine. Avant chaque session de crawl, il vérifie si cette copie est périmée. Si elle l'est, il refetch le fichier. Mais la notion de "périmé" varie selon l'autorité du site et son taux de modification historique.

Un site qui change rarement son robots.txt verra Google le recrawler moins fréquemment. À l'inverse, un site qui modifie régulièrement ses directives obtiendra des refreshs plus rapides. Google apprend de vos patterns. Mais cette logique reste opaque et non documentée officiellement.

• Le robots.txt n'est pas appliqué instantanément après modification — il existe toujours un délai de cache
• La fréquence de recrawl du robots.txt dépend de l'autorité du site et de son historique de modifications
• Forcer le recrawl via Search Console est la seule méthode documentée pour accélérer la prise en compte
• Les anciennes règles restent actives jusqu'au prochain crawl effectif du fichier
• Aucun SLA n'est garanti par Google sur le délai de mise à jour du cache robots.txt

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

Oui, on observe effectivement ce décalage en production. Des logs Apache montrent Googlebot qui continue de crawler des URLs bloquées dans un robots.txt fraîchement modifié. Le délai varie énormément : de quelques heures sur des mastodontes à plusieurs jours sur des sites moyens.

La partie frustrante ? Google ne donne aucun moyen de monitorer l'état du cache côté serveur. Vous modifiez robots.txt, vous attendez, vous scrutez vos logs. C'est artisanal. La fonction "Tester le robots.txt" dans Search Console ne teste que la version actuelle de votre fichier, pas celle en cache chez Google.

Quelles zones d'ombre subsistent dans cette affirmation ?

Mueller parle d'un fichier "récemment modifié", mais aucune définition temporelle claire. Récent, c'est quoi ? 1 heure ? 24 heures ? 7 jours ? Cette imprécision est typique des communications Google : on vous donne le principe, jamais les seuils. [À vérifier] en conditions réelles via vos propres logs.

Autre flou : que se passe-t-il si le fichier robots.txt devient temporairement inaccessible (erreur 500, timeout) ? Google utilise-t-il la dernière version en cache ou considère-t-il qu'il n'y a plus de restriction ? La doc officielle dit que Google suppose aucune restriction en cas d'erreur serveur, ce qui contredit partiellement la logique de cache évoquée ici.

Dans quels cas cette règle ne protège-t-elle pas vraiment vos contenus ?

Le robots.txt ne bloque pas l'indexation, seulement le crawl. Si une URL bloquée reçoit des backlinks externes, Google peut quand même l'indexer avec une description générique. Vous vous retrouvez avec des pages dans l'index sans que Google ait pu en explorer le contenu. Paradoxal mais documenté.

Pire encore : pendant le délai de cache, une URL que vous venez de bloquer peut encore être crawlée ET indexée si elle vient d'apparaître dans votre sitemap XML ou dans le maillage interne. Le timing compte énormément. Si vous restructurez massivement votre site, le décalage robots.txt peut créer des incohérences temporaires dans l'index.

Que faut-il faire concrètement après avoir modifié robots.txt ?

Ne restez pas passif en attendant que Google daigne recrawler votre fichier. Allez dans Search Console → Paramètres → Outil de test du fichier robots.txt. Testez vos nouvelles règles, puis utilisez l'option "Envoyer" (si disponible dans votre interface). Ça ne garantit pas un recrawl immédiat, mais ça envoie un signal.

Ensuite, surveillez vos logs serveur. Cherchez les requêtes Googlebot sur des URLs que vous venez de bloquer. Si elles persistent 48h après modification, vous êtes dans le délai de cache. Notez la durée observée pour anticiper les prochaines modifications.

Quelles erreurs éviter lors de la gestion du robots.txt ?

Ne bloquez jamais des ressources critiques (CSS, JS) nécessaires au rendu de vos pages. Google a besoin de ces fichiers pour comprendre votre contenu. Bloquer /wp-content/themes/ parce que "ça économise du crawl budget" détruit votre indexabilité.

Évitez les modifications fréquentes et erratiques. Si vous changez vos règles toutes les semaines, Google peut augmenter la fréquence de crawl du robots.txt, mais vous perdez en prévisibilité. Planifiez vos modifications par batch logique. Un changement tous les mois est plus sain que dix micro-ajustements hebdomadaires.

Comment vérifier que vos restrictions sont enfin actives ?

Méthode 1 : analysez vos logs Apache/Nginx. Filtrez les user-agent Googlebot et vérifiez qu'ils ne touchent plus les URLs bloquées. Si vous voyez encore des hits après 72h, le cache persiste ou vos règles sont mal écrites.

Méthode 2 : utilisez l'API Indexing de Google (si éligible) pour forcer la suppression des URLs déjà indexées que vous venez de bloquer. Ça ne force pas le recrawl du robots.txt, mais ça nettoie l'index en parallèle. Combiné à une surveillance GSC, ça donne une vision claire de l'état réel.

• Tester le nouveau robots.txt dans Search Console immédiatement après modification
• Surveiller les logs serveur pendant 48-72h pour détecter le moment exact du recrawl
• Ne jamais bloquer CSS/JS critiques pour le rendu
• Grouper les modifications robots.txt au lieu de les fragmenter
• Utiliser noindex + X-Robots-Tag pour les contenus vraiment sensibles, pas robots.txt seul
• Documenter les délais de cache observés sur votre domaine pour anticiper les prochaines modifications