Ce que Gary Illyes a réellement dit — et pourquoi ça change la donne
Gary Illyes, Senior Search Analyst chez Google, a confirmé lors d'une intervention récente que Google déploie des centaines de crawlers qui ne figurent dans aucune documentation publique. La liste officielle des crawlers Google ne recense qu'une vingtaine d'user agents — Googlebot, Googlebot-Image, Googlebot-News, AdsBot, etc. Le reste opère dans l'ombre.
Ce n'est pas une révélation anodine. Si vous gérez un site de 10 000+ pages et que vous prenez des décisions de filtrage basées uniquement sur les user agents documentés, vous travaillez avec une vision partielle de ce qui se passe réellement sur votre infrastructure. Vos logs serveur contiennent probablement des dizaines de hits de crawlers Google que vous n'avez jamais identifiés comme tels.
L'implication directe : votre stratégie de gestion du crawl budget, vos règles robots.txt et vos configurations de rate limiting méritent une réévaluation complète.
L'écart entre documentation et réalité dans vos access logs
Ce que la documentation officielle couvre
La page Google Crawlers liste des user agents comme :
Googlebot(web search)Googlebot-ImageGooglebot-VideoGooglebot-NewsAdsBot-GoogleMediapartners-GoogleAPIs-GoogleFeedFetcher-GoogleGoogle-InspectionTool
Chacun a un user agent string documenté, des plages IP vérifiables via DNS reverse, et un comportement décrit. Pour Googlebot, le user agent ressemble à ça :
Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Ce qui manque dans vos analyses
Le problème concret : quand vous filtrez vos logs serveur pour analyser le comportement de Google, vous utilisez probablement un grep basique ou un filtre dans Screaming Frog Log File Analyser. Si votre regex ne capture que les user agents documentés, vous ratez potentiellement une part significative de l'activité Google.
Voici un script d'analyse que vous pouvez exécuter sur vos access logs Nginx pour identifier les hits provenant des plages IP de Google mais ne correspondant à aucun user agent documenté :
#!/bin/bash
# Étape 1 : Extraire les IPs uniques qui contiennent "Google" ou "google" dans le UA
zcat /var/log/nginx/access.log.*.gz | \
awk -F'"' '$6 ~ /[Gg]oogle/ {print $1}' | \
awk '{print $1}' | sort -u > /tmp/google_ips.txt
# Étape 2 : Vérifier le reverse DNS pour confirmer l'appartenance à Google
while IFS= read -r ip; do
host=$(dig -x "$ip" +short 2>/dev/null)
if echo "$host" | grep -qiE '(googlebot|google)\.com\.$'; then
echo "VERIFIED: $ip -> $host"
fi
done < /tmp/google_ips.txt > /tmp/verified_google_ips.txt
# Étape 3 : Extraire les user agents de ces IPs vérifiées
while IFS= read -r line; do
ip=$(echo "$line" | awk '{print $2}')
zcat /var/log/nginx/access.log.*.gz | \
grep "^$ip " | \
awk -F'"' '{print $6}' | sort -u
done < /tmp/verified_google_ips.txt > /tmp/google_unknown_uas.txt
# Étape 4 : Filtrer ceux qui ne matchent aucun crawler documenté
grep -viE '(Googlebot|AdsBot|Mediapartners|FeedFetcher|APIs-Google|Google-InspectionTool|Storebot|GoogleOther)' \
/tmp/google_unknown_uas.txt > /tmp/undocumented_google_crawlers.txt
echo "Crawlers Google non documentés trouvés :"
cat /tmp/undocumented_google_crawlers.txtSur un site e-commerce de 18 000 pages que j'ai audité récemment, ce type d'analyse a révélé 7 user agents distincts provenant de plages IP Google vérifiées, qui ne correspondaient à aucun crawler de la documentation officielle. Ces crawlers représentaient environ 12% du volume total de hits Google sur une période de 30 jours.
La vérification DNS inverse reste le seul outil fiable
Google documente cette méthode : résolution DNS inverse suivie d'une résolution directe pour confirmer que l'IP appartient bien à googlebot.com ou google.com. C'est la seule méthode fiable pour identifier un vrai crawler Google, documenté ou non.
# Vérification en deux étapes d'une IP suspecte
# Étape 1 : DNS inverse
dig -x 66.249.66.1 +short
# Résultat attendu : crawl-66-249-66-1.googlebot.com.
# Étape 2 : DNS direct pour confirmer
dig crawl-66-249-66-1.googlebot.com +short
# Résultat attendu : 66.249.66.1Si les deux résultats sont cohérents et que le domaine est googlebot.com ou google.com, c'est un vrai crawler Google — même s'il n'est dans aucune documentation.
Pourquoi Google déploie des crawlers non documentés
L'information brute de Gary Illyes prend tout son sens quand on comprend l'architecture interne de Google Search.
Des crawlers spécialisés pour des tâches internes
Google n'est pas un monolithe. Le pipeline de search repose sur des dizaines de systèmes interconnectés : indexation, rendering, évaluation de la qualité, détection de spam, analyse des données structurées, test de Core Web Vitals, vérification des structured data en production, etc.
Chaque système peut avoir besoin de re-fetcher des pages pour des raisons spécifiques. Un crawler dédié à la vérification des claims dans les données structurées ClaimReview n'a pas les mêmes patterns d'accès que Googlebot principal. Un système interne de quality assurance qui vérifie que les résultats de recherche pointent toujours vers du contenu pertinent a besoin de son propre agent.
La raison pour laquelle ces crawlers ne sont pas documentés est pragmatique : ils sont à usage interne, leur comportement peut changer à tout moment, et Google ne veut pas s'engager sur une interface stable pour des systèmes expérimentaux ou transitoires.
L'hypothèse des crawlers de machine learning
Avec l'essor des AI Overviews et du Search Generative Experience, Google a besoin de collecter des données d'entraînement et de validation en permanence. Des crawlers dédiés au fetching de contenu pour les pipelines ML seraient cohérents avec cette déclaration. Ces crawlers auraient des patterns très différents de Googlebot classique : ils pourraient cibler des types de contenu spécifiques, ignorer le robots.txt (si Google les considère comme des outils internes et non des "crawlers de search"), et avoir des fréquences de passage erratiques.
C'est un point de vigilance majeur. Si certains de ces crawlers non documentés ne respectent pas les directives robots.txt destinées à Googlebot, votre stratégie de contrôle du crawl devient partiellement inefficace. La documentation Google précise que seuls les crawlers identifiés comme respectant robots.txt le font effectivement — pour les autres, c'est le flou.
Impact concret sur votre gestion du crawl budget
Scénario : un média en ligne à 25 000 pages
Prenons un site média qui publie 50 articles/jour, avec un historique de 25 000 URLs indexées. Les logs montrent un volume quotidien moyen de 15 000 hits Googlebot. Le SEO lead a optimisé son robots.txt pour bloquer les facettes, les pages d'auteur paginées, et les archives par date.
En analysant les logs avec la méthode DNS reverse décrite plus haut, l'équipe découvre 3 200 hits quotidiens supplémentaires provenant de crawlers Google non documentés. Ces hits ciblent majoritairement :
- Les pages AMP (que le site a désactivées depuis 18 mois)
- Les endpoints JSON-LD autonomes (les pages de données structurées servies via des routes API)
- Des URLs avec des paramètres UTM que Google est censé ignorer
Soit 21% du crawl total de Google qui échappe à l'analyse standard. Sur un mois, ça représente ~96 000 requêtes non comptabilisées, avec un impact mesurable sur la charge serveur et la fraîcheur du crawl des pages importantes.
Le problème du rate limiting
Si vous avez configuré un rate limit pour Googlebot dans votre Nginx ou votre CDN, les crawlers non documentés peuvent utiliser des user agents différents et contourner vos règles sans que ce soit intentionnel de la part de Google.
# Configuration Nginx typique de rate limiting pour Googlebot
# PROBLÈME : ne capture que les UAs documentés
map $http_user_agent $is_googlebot {
default 0;
"~*Googlebot" 1;
"~*AdsBot-Google" 1;
"~*Mediapartners-Google" 1;
"~*FeedFetcher-Google" 1;
"~*APIs-Google" 1;
"~*Google-InspectionTool" 1;
"~*GoogleOther" 1;
"~*Storebot-Google" 1;
}
# MEILLEURE APPROCHE : combiner UA + plages IP Google
# Utiliser les plages IP publiées par Google dans un fichier GeoIP custom
# https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot
geo $is_google_ip {
default 0;
# Plages IP Googlebot (à mettre à jour régulièrement)
66.249.64.0/19 1;
64.233.160.0/19 1;
72.14.192.0/18 1;
209.85.128.0/17 1;
216.239.32.0/19 1;
# ... Récupérer la liste complète via :
# curl https://developers.google.com/search/apis/ipranges/googlebot.json
}
limit_req_zone $binary_remote_addr zone=google_crawl:10m rate=5r/s;
server {
# Appliquer le rate limit uniquement sur les IPs Google vérifiées
if ($is_google_ip) {
set $limit_key $binary_remote_addr;
}
location / {
limit_req zone=google_crawl burst=10 nodelay;
# ...
}
}L'approche par IP est plus robuste que l'approche par user agent, précisément parce qu'elle capture tous les crawlers Google — documentés ou non. Google publie ses plages IP à cette adresse, et vous devriez automatiser la mise à jour de cette liste.
Adapter votre monitoring et votre robots.txt
La faille du wildcard user-agent
Votre robots.txt est probablement structuré avec des directives spécifiques pour Googlebot et un User-agent: * en fallback. La question cruciale : à quel user-agent les crawlers non documentés de Google répondent-ils ?
Deux possibilités :
- Ils s'identifient comme
Googlebotdans leur user agent string → vos directivesUser-agent: Googlebots'appliquent - Ils utilisent un user agent unique non documenté → seules les directives
User-agent: *s'appliquent
Si vous avez des règles plus permissives dans User-agent: * que dans User-agent: Googlebot (ce qui est rare mais arrive dans des configurations complexes), ces crawlers pourraient accéder à des sections que vous pensiez bloquées pour Google.
La recommandation : vérifiez que vos directives User-agent: * sont au moins aussi restrictives que celles de User-agent: Googlebot pour les sections sensibles.
# robots.txt - Structure défensive recommandée
# Bloquer d'abord globalement les sections sensibles
User-agent: *
Disallow: /api/
Disallow: /admin/
Disallow: /checkout/
Disallow: /search?
Disallow: /tmp/
# Puis définir les exceptions spécifiques pour Googlebot
User-agent: Googlebot
Disallow: /api/
Disallow: /admin/
Disallow: /checkout/
Disallow: /search?
Disallow: /tmp/
# Autoriser explicitement les sections que vous VOULEZ voir crawlées
Allow: /api/products-feed
Allow: /
Sitemap: https://www.votresite.com/sitemap-index.xml
Monitorer l'inconnu dans Search Console
La Search Console ne vous montrera que l'activité des crawlers qui alimentent le rapport de couverture. Les crawlers non documentés n'apparaissent probablement pas dans les stats de crawl de la GSC — ou ils sont agrégés avec Googlebot sans distinction.
C'est précisément là que l'analyse de logs bruts devient indispensable. L'API URL Inspection vous donne le point de vue de Google sur une URL donnée, mais elle ne vous dit pas quels crawlers l'ont visitée ni combien de fois.
Pour un monitoring continu, un outil comme SEOGard peut détecter des anomalies dans les patterns de crawl — un pic soudain de hits provenant de plages IP Google avec des user agents inhabituels est exactement le type de signal qu'un monitoring automatisé capture et qu'une vérification manuelle hebdomadaire rate.
Les implications pour le JavaScript SEO et le rendering
La déclaration de Gary Illyes prend une dimension supplémentaire quand on la croise avec le pipeline de rendering de Google.
Le WRS et les crawlers de pré-validation
Le Web Rendering Service (WRS) de Google fonctionne en deux passes : un premier crawl pour récupérer le HTML, puis un second passage pour exécuter le JavaScript et capturer le DOM rendu. Ce qu'on sait moins, c'est que des crawlers intermédiaires peuvent intervenir entre ces deux étapes — par exemple pour vérifier la disponibilité des ressources JS/CSS avant d'allouer des ressources de rendering.
Si votre site repose sur du SSR ou du prerendering, ces crawlers intermédiaires non documentés pourraient fetcher vos pages et obtenir la version SSR, puis un autre crawler non documenté pourrait tester la version CSR pour comparer. Ce double crawl invisible consomme du crawl budget sans que vous en ayez conscience.
Pour les sites React qui utilisent du prerendering conditionnel, c'est un point critique : si votre mécanisme de prerendering se base sur la détection du user agent Googlebot, les crawlers non documentés recevront la version CSR non-prerendered. Votre contenu pourrait ne pas être correctement indexé par ces systèmes secondaires.
// middleware.ts (Next.js) - Détection de bot par IP plutôt que par UA
import { NextRequest, NextResponse } from 'next/server';
// Plages IP Google (simplifiées - utiliser la liste complète en production)
const GOOGLE_IP_RANGES = [
{ start: '66.249.64.0', end: '66.249.95.255' },
{ start: '64.233.160.0', end: '64.233.191.255' },
{ start: '72.14.192.0', end: '72.14.255.255' },
{ start: '209.85.128.0', end: '209.85.255.255' },
];
function ipToNumber(ip: string): number {
return ip.split('.').reduce((acc, octet) => (acc << 8) + parseInt(octet), 0) >>> 0;
}
function isGoogleIP(ip: string): boolean {
const ipNum = ipToNumber(ip);
return GOOGLE_IP_RANGES.some(range => {
const start = ipToNumber(range.start);
const end = ipToNumber(range.end);
return ipNum >= start && ipNum <= end;
});
}
export function middleware(request: NextRequest) {
const clientIP = request.headers.get('x-forwarded-for')?.split(',')[0]?.trim()
|| request.ip || '';
// Détecter TOUS les crawlers Google par IP, pas seulement par UA
const isGoogleCrawler = isGoogleIP(clientIP);
// Forcer le SSR complet pour tous les crawlers Google
if (isGoogleCrawler) {
const response = NextResponse.next();
response.headers.set('X-Robots-Tag', 'all');
response.headers.set('X-Google-Crawler-Detected', 'true');
// Désactiver le streaming pour garantir un HTML complet
response.headers.set('X-SSR-Mode', 'full');
return response;
}
return NextResponse.next();
}Cette approche par IP est plus résiliente que la détection par user agent, car elle capture l'ensemble des crawlers Google, y compris ceux dont l'identité n'est documentée nulle part.
Ce que vous devez faire maintenant
Audit immédiat en 4 étapes
1. Analysez vos logs sur 30 jours avec la méthode DNS reverse pour identifier tous les crawlers Google, documentés ou non. Comptez le ratio hits documentés vs non documentés.
2. Vérifiez la cohérence de votre robots.txt entre les directives User-agent: Googlebot et User-agent: *. Si un crawler non documenté utilise un UA qui ne matche pas Googlebot, seul le wildcard s'applique.
3. Basculez votre détection de bot (prerendering, rate limiting, analytics serveur) d'une approche user-agent vers une approche IP-based en utilisant les plages officielles publiées par Google.
4. Mettez en place un monitoring continu des patterns de crawl par IP. Un changement dans la distribution des crawlers Google sur votre site est un signal précoce de modification algorithmique — les nouveaux crawlers non documentés précèdent souvent les changements visibles dans les SERPs.
Ce que ça signifie pour l'avenir du SEO technique
La déclaration de Gary Illyes confirme ce que les SEO techniques suspectaient depuis longtemps : la surface visible de l'infrastructure de crawl Google n'est que la partie émergée. Avec l'expansion des AI Overviews et la complexification du pipeline search, le nombre de crawlers non documentés va probablement augmenter.
Les équipes qui ne monitorent que les user agents connus vont perdre en visibilité sur le comportement réel de Google sur leur site. Celles qui investissent dans l'analyse de logs par vérification DNS et dans le monitoring des cinq couches d'infrastructure garderont un temps d'avance.
La leçon fondamentale est simple : ne faites jamais confiance à la documentation comme source unique de vérité. Vos logs serveur sont la seule source fiable de ce qui se passe réellement sur votre infrastructure. Automatisez leur analyse, mettez en place des alertes sur les anomalies de crawl, et traitez chaque IP Google vérifiée comme un crawler de première importance — qu'il ait un nom officiel ou non.