Robots.txt : Google élargit sa liste de directives non supportées

Un fichier robots.txt de 12 lignes peut neutraliser le crawl de 40 000 pages sans déclencher la moindre alerte dans Search Console. C'est exactement ce que Google tente d'adresser en élargissant sa liste de directives robots.txt non supportées, en s'appuyant sur les données massives de HTTP Archive pour identifier les erreurs que des millions de sites commettent silencieusement.

Ce que Google prépare : les données HTTP Archive comme révélateur

L'information, rapportée par Search Engine Journal, part d'une discussion publique sur le dépôt GitHub du protocole robots.txt. L'équipe Google envisage d'utiliser les données crawlées par HTTP Archive — qui scanne régulièrement des millions de sites — pour dresser un inventaire statistique des directives non standard présentes dans les fichiers robots.txt à travers le web.

Le point technique fondamental : le protocole robots.txt, tel que formalisé dans la RFC 9309, ne reconnaît qu'un ensemble très limité de directives. En pratique, seules User-agent, Allow, Disallow et Sitemap sont universellement supportées par les crawlers majeurs. Tout le reste — Crawl-delay, Noindex, Request-rate, Host — est soit ignoré, soit traité de manière inconsistante selon les moteurs.

Ce que Google observe via HTTP Archive, c'est que des centaines de milliers de fichiers robots.txt contiennent des directives qui ne font strictement rien. Et pire : des fautes de frappe sur Disallow qui transforment une règle de blocage en ligne ignorée.

Le problème des fautes de frappe sur Disallow

Google envisage spécifiquement d'élargir sa tolérance aux variantes orthographiques de Disallow. C'est loin d'être anecdotique. Voici un robots.txt réel qu'on rencontre en production :

User-agent: *
Dissallow: /admin/
Disalow: /checkout/
Disallow: /api/
Crawl-delay: 10
Noindex: /staging/

Dans cet exemple, seule la ligne Disallow: /api/ est effectivement interprétée par Googlebot. Les répertoires /admin/ et /checkout/ sont crawlés librement — la faute de frappe rend la directive invisible. Crawl-delay est ignoré par Google (Bing le respecte). Noindex dans robots.txt n'a jamais été un standard et Google a officiellement cessé de le supporter depuis le 1er septembre 2019.

Le propriétaire du site pense avoir bloqué trois répertoires. En réalité, il n'en a bloqué qu'un.

Pourquoi HTTP Archive change la donne

Jusqu'ici, Google documentait les directives non supportées de manière réactive. L'approche HTTP Archive est proactive : analyser les robots.txt de millions de sites pour quantifier la prévalence de chaque erreur. Si Dissallow apparaît sur 0,3 % des sites analysés (soit potentiellement des dizaines de milliers de domaines), Google peut décider d'interpréter cette variante comme un Disallow valide, ou au minimum de l'ajouter à sa documentation comme erreur courante à éviter.

HTTP Archive utilise BigQuery pour exposer ses datasets. Vous pouvez vous-même requêter les données pour analyser la prévalence de certaines directives :

SELECT
  REGEXP_EXTRACT(body, r'(?mi)^([\w-]+):') AS directive,
  COUNT(*) AS occurrences
FROM
  `httparchive.response_bodies.2026_04_01_desktop`
WHERE
  url LIKE '%/robots.txt'
  AND status = 200
GROUP BY directive
ORDER BY occurrences DESC
LIMIT 50

Cette requête extrait le nom de chaque directive présente dans les robots.txt crawlés par HTTP Archive et les classe par fréquence. C'est exactement le type d'analyse que l'équipe Google utilise pour prioriser les directives à documenter ou à tolérer.

L'inventaire des directives non supportées : ce qui est ignoré et ce qui est dangereux

Pour un Lead SEO technique, la question n'est pas "quelles directives existent" mais "quelles directives sont silencieusement ignorées sur mes sites en production". Voici un inventaire technique avec le comportement réel de Googlebot.

Directives complètement ignorées par Google

Directive	Origine	Comportement Googlebot
`Crawl-delay`	Extension Yandex/Bing	Ignorée. Aucun effet sur le crawl rate.
`Noindex`	Convention non standard	Ignorée depuis septembre 2019.
`Request-rate`	Proposition abandonnée	Ignorée.
`Visit-time`	Proposition abandonnée	Ignorée.
`Host`	Extension Yandex	Ignorée.
`Clean-param`	Extension Yandex	Ignorée.

Fautes de frappe documentées et candidates à l'expansion

La liste actuelle des variantes que Google pourrait commencer à tolérer (ou au moins documenter explicitement) :

Dissallow (double 's')
Disalow (un seul 'l')
Diallow (absence du 's')
Dissalow (double 's' + un seul 'l')
Useragent (sans tiret)
User agent (espace sans tiret)

Le cas Noindex : un héritage toxique

Le retrait du support de Noindex dans robots.txt en 2019 a laissé un héritage problématique. Des milliers de sites continuent de l'utiliser en pensant empêcher l'indexation de certaines sections. La directive correcte passe par l'en-tête HTTP X-Robots-Tag ou la balise meta robots dans le HTML :

<!-- Dans le <head> de la page -->
<meta name="robots" content="noindex, follow">

Ou via un en-tête HTTP (utile pour les PDF, images, et autres ressources non-HTML) :

# Configuration Nginx pour les fichiers du répertoire /staging/
location /staging/ {
    add_header X-Robots-Tag "noindex, nofollow" always;
}

Si vous avez hérité d'un robots.txt contenant Noindex:, vous avez potentiellement des pages indexées que vous croyez exclues. Vérifiez immédiatement avec site:votredomaine.com/staging/ dans Google.

Audit de votre robots.txt : méthodologie complète

Un robots.txt mal formé ne génère aucune erreur visible. Pas d'alerte Search Console, pas de log d'erreur serveur, pas de page blanche. Le site fonctionne parfaitement — mais le crawl est soit trop permissif, soit cassé.

Étape 1 : Validation syntaxique

Google fournit un testeur de robots.txt dans Search Console. Cet outil valide la syntaxe et simule le comportement de Googlebot sur des URLs spécifiques. Mais il ne détecte pas les directives non supportées — il les ignore silencieusement, exactement comme Googlebot.

Pour une validation plus stricte, utilisez le parser robots.txt open source de Google :

# Installation du parser Google robots.txt
git clone https://github.com/google/robotstxt.git
cd robotstxt
cmake -B build
cmake --build build

# Test d'une URL contre votre robots.txt
./build/robots /chemin/vers/robots.txt "Googlebot" "https://votresite.com/admin/page"

Ce parser est la même logique que Googlebot utilise en production. Si une directive est ignorée par ce parser, elle est ignorée par Google. Point final.

Étape 2 : Détection des directives non standard

Un script rapide pour auditer votre robots.txt et signaler les directives suspectes :

#!/usr/bin/env python3
"""Audit robots.txt : détecte les directives non standard et les fautes de frappe."""

import re
import sys
from difflib import get_close_matches

VALID_DIRECTIVES = {'user-agent', 'disallow', 'allow', 'sitemap'}
KNOWN_UNSUPPORTED = {'crawl-delay', 'noindex', 'host', 'request-rate', 'visit-time', 'clean-param'}
DISALLOW_TYPOS = ['dissallow', 'disalow', 'diallow', 'dissalow', 'disallaw', 'disalllow']

def audit_robots_txt(filepath: str) -> list[dict]:
    issues = []
    with open(filepath, 'r') as f:
        for line_num, line in enumerate(f, 1):
            line = line.strip()
            if not line or line.startswith('#'):
                continue

            match = re.match(r'^([a-zA-Z\-]+)\s*:', line)
            if not match:
                issues.append({
                    'line': line_num,
                    'severity': 'error',
                    'message': f'Ligne mal formée : "{line}"'
                })
                continue

            directive = match.group(1).lower()

            if directive in VALID_DIRECTIVES:
                continue

            if directive in KNOWN_UNSUPPORTED:
                issues.append({
                    'line': line_num,
                    'severity': 'warning',
                    'message': f'Directive non supportée par Google : "{match.group(1)}"'
                })
            elif directive in DISALLOW_TYPOS:
                issues.append({
                    'line': line_num,
                    'severity': 'critical',
                    'message': f'Faute de frappe probable sur Disallow : "{match.group(1)}" — cette ligne est IGNORÉE'
                })
            else:
                close = get_close_matches(directive, VALID_DIRECTIVES | KNOWN_UNSUPPORTED, n=1, cutoff=0.6)
                suggestion = f' (vouliez-vous dire "{close[0]}" ?)' if close else ''
                issues.append({
                    'line': line_num,
                    'severity': 'warning',
                    'message': f'Directive inconnue : "{match.group(1)}"{suggestion}'
                })

    return issues

if __name__ == '__main__':
    filepath = sys.argv[1] if len(sys.argv) > 1 else 'robots.txt'
    issues = audit_robots_txt(filepath)
    for issue in issues:
        print(f"[{issue['severity'].upper()}] Ligne {issue['line']}: {issue['message']}")
    if not issues:
        print("Aucun problème détecté.")

Étape 3 : Validation croisée avec les logs serveur

L'audit statique ne suffit pas. Vous devez croiser avec les logs de crawl réels pour vérifier que Googlebot respecte effectivement vos directives. Un article sur l'analyse des logs pour les crawlers IA couvre en détail la méthodologie d'analyse des logs. Appliquez la même logique pour isoler les requêtes Googlebot sur les répertoires que vous pensez avoir bloqués.

Si Googlebot crawle /admin/ alors que votre robots.txt contient Dissallow: /admin/, vous avez votre preuve.

Scénario concret : un e-commerce de 22 000 pages avec un robots.txt corrompu

Prenons un cas réaliste. Un site e-commerce mode sur Magento 2, 22 000 pages produit, 1 800 pages catégorie, 350 pages CMS. Le robots.txt a été édité par trois personnes différentes sur quatre ans.

Le fichier initial

User-agent: *
Disallow: /checkout/
Disallow: /customer/
Dissallow: /catalogsearch/
Disallow: /wishlist/
Noindex: /tag/
Crawl-delay: 5
Disallow: /review/pending/

User-agent: Googlebot
Allow: /media/catalog/
Disalow: /media/tmp/

Sitemap: https://shop-mode.fr/sitemap.xml

L'impact mesuré

Après audit, voici ce qui se passe réellement :

Dissallow: /catalogsearch/ — Ignorée. Googlebot crawle toutes les pages de recherche interne. Sur ce site, la recherche à facettes génère environ 85 000 URLs paramétrées (/catalogsearch/result/?q=robe+rouge&color=45&size=M). Le crawl budget est gaspillé massivement. Dans Search Console, les pages explorées mais non indexées explosent.
Noindex: /tag/ — Ignorée. Les 2 400 pages de tags sont indexées, créent du contenu dupliqué thin, et diluent l'autorité des pages catégorie. Ces pages génèrent en moyenne 12 mots de contenu unique.
Disalow: /media/tmp/ — Ignorée. Les fichiers temporaires d'upload sont crawlés. Pas critique pour le SEO, mais du crawl budget perdu sur des ressources éphémères.
Crawl-delay: 5 — Ignorée par Google. Mais si Bing respecte cette directive, cela signifie un délai de 5 secondes entre chaque requête. Pour 22 000 pages, un crawl complet par Bingbot prendrait théoriquement 22 000 × 5 = 110 000 secondes, soit plus de 30 heures. En pratique, Bing ne recrawlerait jamais l'intégralité du catalogue.

Le fichier corrigé

User-agent: *
Disallow: /checkout/
Disallow: /customer/
Disallow: /catalogsearch/
Disallow: /wishlist/
Disallow: /review/pending/
Disallow: /media/tmp/

User-agent: Googlebot
Allow: /media/catalog/
Disallow: /catalogsearch/

Sitemap: https://shop-mode.fr/sitemap.xml

Les pages de tags (/tag/) sont gérées via <meta name="robots" content="noindex, follow"> dans le template Magento, pas dans robots.txt. Le Crawl-delay est supprimé — le taux de crawl se gère dans Search Console pour Google, et via le Bing Webmaster Tools pour Bing.

Résultat après 6 semaines

Pages explorées non indexées dans Search Console : passées de 94 000 à 18 000 (l'essentiel des URLs de recherche à facettes ne sont plus crawlées)
Crawl de Googlebot recentré sur les pages produit et catégorie : le rapport de couverture montre une augmentation de 40 % du crawl sur les pages à valeur SEO
2 400 pages de tags retirées de l'index en 3 semaines via le noindex meta

Les implications pour les crawlers IA et les agents

L'expansion de la liste des directives non supportées par Google intervient dans un contexte où les robots ne se limitent plus à Googlebot. Les crawlers d'IA (GPTBot, ClaudeBot, Anthropic, etc.) interprètent eux aussi robots.txt, avec des niveaux de conformité variables.

Si votre robots.txt contient des directives non standard, le comportement diverge entre les crawlers. Un Crawl-delay: 10 sera ignoré par Google, potentiellement respecté par Bing, et le comportement de GPTBot est non documenté.

L'enjeu pour les sites qui veulent contrôler leur visibilité dans les systèmes de recherche agentique est de maintenir un robots.txt parfaitement conforme à la RFC 9309. Tout écart introduit de l'ambiguïté, et l'ambiguïté profite au crawler — pas à vous.

Pour les sites qui doivent gérer des dizaines de user-agents différents, le modèle à adopter est explicite :

# Crawlers de recherche classiques
User-agent: Googlebot
Disallow: /api/
Allow: /api/products

User-agent: Bingbot
Disallow: /api/
Allow: /api/products

# Crawlers IA
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

# Règle par défaut
User-agent: *
Disallow: /api/
Disallow: /internal/

Sitemap: https://votresite.com/sitemap.xml

La question de l'architecture machine-first impose une rigueur nouvelle sur ces fichiers de configuration. Un robots.txt n'est plus un simple garde-fou pour Googlebot — c'est le premier point de contact avec une dizaine de systèmes automatisés qui prennent des décisions en fonction de ce qu'ils lisent.

Monitoring continu : pourquoi l'audit ponctuel ne suffit pas

Un robots.txt validé aujourd'hui peut être cassé demain. Un déploiement qui écrase le fichier, un plugin WordPress qui ajoute des directives non standard, un développeur junior qui corrige une "faute de frappe" en en introduisant une autre.

Les vecteurs de régression les plus courants

Les plugins CMS. Yoast SEO, Rank Math et All in One SEO génèrent dynamiquement le robots.txt dans WordPress. Une mise à jour de plugin peut modifier silencieusement le contenu du fichier. Si vous maintenez un fichier robots.txt physique à la racine ET qu'un plugin génère une version dynamique, le comportement dépend de la configuration du serveur — et le résultat est souvent imprévisible.

Les déploiements CI/CD. Sur une stack moderne (Vercel, Netlify, Docker), le robots.txt est souvent un fichier statique dans le répertoire public/. Un merge accidentel peut écraser le fichier de production avec une version de staging contenant Disallow: /.

Les migrations de serveur. Le passage d'Apache à Nginx (ou inversement) peut modifier le content-type du fichier robots.txt. La RFC 9309 exige text/plain. Un serveur mal configuré qui renvoie text/html peut conduire certains parsers à ignorer le fichier.

Vérifiez le content-type avec :

curl -sI https://votresite.com/robots.txt | grep -i content-type
# Attendu : content-type: text/plain

Screaming Frog comme filet de sécurité

Screaming Frog affiche les directives robots.txt et leur effet sur le crawl dans l'onglet "Directives". Mais il ne détecte pas les directives non standard ignorées — il les affiche sans avertissement. C'est une limitation connue.

Pour un monitoring en continu, un outil comme Seogard détecte automatiquement les modifications de robots.txt entre deux scans et alerte quand une directive de blocage disparaît ou quand une directive non standard est ajoutée. Sur un site de 22 000 pages, la différence entre "détection en 15 minutes" et "détection au prochain audit trimestriel" représente potentiellement des semaines de crawl gaspillé.

Ce que cette évolution révèle sur la direction de Google

L'utilisation de HTTP Archive par Google pour informer ses décisions sur le protocole robots.txt est un signal plus large. Google évolue d'une approche prescriptive ("voici le standard, conformez-vous") vers une approche descriptive ("voici ce que le web fait réellement, adaptons notre interprétation").

C'est cohérent avec la manière dont Google gère déjà le HTML malformé : le parser de Chromium corrige automatiquement les erreurs courantes. La question est de savoir si cette même tolérance va s'étendre au robots.txt — et si oui, quelles sont les limites.

Le risque : si Google commence à interpréter Dissallow comme Disallow, les sites qui utilisaient involontairement cette faute de frappe pourraient voir leur crawl modifié du jour au lendemain. Des pages qui étaient crawlées depuis des années seraient soudainement bloquées. C'est un changement rétroactif potentiellement destructeur pour les sites qui dépendent de ce comportement accidentel.

L'approche la plus probable est que Google documente d'abord ces directives non standard dans sa documentation officielle des spécifications robots.txt, avant d'éventuellement modifier le comportement du parser. La documentation est le premier pas — le changement de comportement viendrait après, avec un délai d'adaptation.

Pour les équipes SEO techniques qui gèrent des patrimoines importants, c'est le moment de lancer un audit complet de tous les fichiers robots.txt en production. Pas dans trois mois — maintenant. Avant que Google ne décide de changer son interprétation et que des directives jusqu'ici ignorées deviennent actives.

Les sites qui ont déjà un monitoring automatisé de leur configuration de crawl sont les mieux positionnés pour absorber ce type de changement. Les autres découvriront le problème quand leur trafic organique aura déjà baissé.