Crawlers Google non documentés : impact SEO technique

Ce que Gary Illyes a réellement dit — et pourquoi ça change la donne

Gary Illyes, analyste chez Google Search, a déclaré lors d'une intervention récente que Google déploie des centaines de crawlers qui ne sont pas documentés publiquement. La documentation officielle de Google sur les crawlers liste environ 15 user agents : Googlebot, Googlebot-Image, Googlebot-News, AdsBot, APIs-Google, etc. Mais ces 15 ne représentent qu'une fraction visible de l'infrastructure de crawl réelle.

Cette déclaration, relayée par Search Engine Journal, n'est pas une surprise pour ceux qui analysent leurs server logs depuis des années. Vous avez probablement déjà vu des requêtes provenant d'IPs Google avec des user agents atypiques, des patterns de crawl qui ne correspondent à aucun bot documenté, ou des pics de crawl inexpliqués sur des endpoints que Googlebot "standard" ne devrait pas toucher.

Le vrai problème : si vous basez votre stratégie de robots.txt uniquement sur les user agents documentés, vous contrôlez peut-être 10% du trafic de crawl réel que Google envoie sur votre infrastructure.

L'anatomie du crawl Google : bien au-delà de Googlebot

Les crawlers documentés vs. la réalité des logs

La documentation officielle catégorise les crawlers en trois groupes : ceux qui respectent robots.txt, ceux qui ne le respectent pas (comme AdsBot), et les "fetchers déclenchés par l'utilisateur" (comme Feedfetcher). Mais cette taxonomie est incomplète par design.

Google opère des dizaines de produits qui ont besoin d'accéder au contenu web : Google Shopping, Google Flights, Google Scholar, les Rich Results testing tools, les systèmes de détection de spam, les pipelines de données pour les modèles de langage, les systèmes de vérification de structured data en production. Chacun de ces systèmes peut avoir son propre crawler — ou plusieurs.

Voici un exemple concret de ce que vous pouvez observer dans vos access logs Apache/Nginx sur un e-commerce de 20 000 pages :

# Extraction des user agents Google uniques sur 30 jours
zcat /var/log/nginx/access.log.*.gz | \
  grep -i 'google' | \
  awk -F'"' '{print $6}' | \
  sort -u | head -40

# Résultat typique (extrait) :
# Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
# Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.6422.175 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
# Googlebot-Image/1.0
# Mediapartners-Google
# AdsBot-Google (+http://www.google.com/adsbot.html)
# APIs-Google (+https://developers.google.com/webmasters/APIs-Google.html)
# Google-Safety
# Google-Site-Verification/1.0
# GoogleOther
# FeedFetcher-Google; (+http://www.google.com/feedfetcher.html)
# Google-Read-Aloud
# googleweblight
# Google-InspectionTool/1.0
# Mozilla/5.0 (compatible; Google-Extended)
# [+ 8 à 15 autres user agents non documentés ou génériques]

Le fait marquant : sur un site réel, vous trouverez régulièrement entre 20 et 30 user agents distincts associés à des IPs Google (vérifiables par reverse DNS sur *.googlebot.com ou *.google.com). La documentation officielle n'en couvre qu'une partie.

GoogleOther et Google-Extended : les crawlers "passerelles"

Deux crawlers méritent une attention particulière. GoogleOther est décrit par Google comme un crawler générique utilisé pour des tâches diverses qui ne sont pas liées à l'indexation Search. Google-Extended a été introduit en septembre 2023 spécifiquement pour permettre aux éditeurs de contrôler l'accès de leurs contenus pour l'entraînement des modèles d'IA de Google (Gemini, etc.).

Ces deux crawlers sont documentés, mais leur comportement réel est opaque. GoogleOther est devenu une sorte de fourre-tout : quand vous bloquez GoogleOther dans robots.txt, vous bloquez potentiellement des dizaines de systèmes internes qui l'utilisent comme user agent par défaut. Et les "centaines de crawlers non documentés" mentionnés par Illyes ? Il est probable qu'une partie d'entre eux se présentent sous ces identifiants génériques, rendant leur identification individuelle impossible côté serveur.

Détection et analyse : identifier ce qui crawle réellement votre site

Mise en place d'une analyse de logs orientée crawlers

L'outil le plus fiable pour comprendre le crawl réel reste l'analyse de server logs. Ni Search Console, ni Screaming Frog ne vous donneront cette vision. Search Console agrège les données de crawl et ne montre que Googlebot "classique". Screaming Frog crawle depuis votre machine — il ne vous dit rien sur ce que Google fait réellement.

Voici un script Python minimaliste pour extraire et catégoriser le trafic de crawl Google à partir de logs Nginx au format combined :

#!/usr/bin/env python3
"""
google_crawler_audit.py
Analyse les access logs Nginx pour identifier et catégoriser
tous les crawlers Google, documentés ou non.
"""

import re
import socket
import sys
from collections import defaultdict, Counter
from functools import lru_cache

# Pattern pour parser le format combined Nginx
LOG_PATTERN = re.compile(
    r'(?P<ip>\S+) \S+ \S+ \[(?P<date>[^\]]+)\] '
    r'"(?P<method>\S+) (?P<path>\S+) \S+" '
    r'(?P<status>\d+) (?P<size>\d+) '
    r'"(?P<referer>[^"]*)" "(?P<ua>[^"]*)"'
)

# User agents Google documentés (mars 2026)
DOCUMENTED_CRAWLERS = {
    'Googlebot', 'Googlebot-Image', 'Googlebot-News',
    'Googlebot-Video', 'Storebot-Google', 'Google-InspectionTool',
    'GoogleOther', 'GoogleOther-Image', 'GoogleOther-Video',
    'Google-Extended', 'AdsBot-Google', 'AdsBot-Google-Mobile',
    'APIs-Google', 'Mediapartners-Google', 'FeedFetcher-Google',
    'Google-Safety', 'Google-Read-Aloud', 'Google-Site-Verification',
}

@lru_cache(maxsize=10000)
def is_google_ip(ip: str) -> bool:
    """Vérifie via reverse DNS si l'IP appartient à Google."""
    try:
        hostname = socket.gethostbyaddr(ip)[0]
        return hostname.endswith(('.googlebot.com', '.google.com'))
    except (socket.herror, socket.gaierror):
        return False

def classify_ua(ua: str) -> tuple[str, bool]:
    """Retourne (nom_du_crawler, est_documenté)."""
    for known in DOCUMENTED_CRAWLERS:
        if known.lower() in ua.lower():
            return known, True
    if 'google' in ua.lower():
        return ua[:80], False  # Tronquer pour lisibilité
    return 'non-google', True

def analyze_logs(logfile: str):
    stats = defaultdict(lambda: {'hits': 0, 'paths': Counter(), 'statuses': Counter()})
    undocumented_uas = set()

    for line in open(logfile, 'r', errors='replace'):
        match = LOG_PATTERN.match(line)
        if not match:
            continue
        
        data = match.groupdict()
        ua = data['ua']
        
        if 'google' not in ua.lower():
            continue
        
        # Vérification DNS (coûteux, mais indispensable pour éviter les faux positifs)
        if not is_google_ip(data['ip']):
            continue
        
        crawler_name, is_documented = classify_ua(ua)
        stats[crawler_name]['hits'] += 1
        stats[crawler_name]['paths'][data['path']] += 1
        stats[crawler_name]['statuses'][data['status']] += 1
        
        if not is_documented:
            undocumented_uas.add(crawler_name)

    # Rapport
    print(f"\n{'='*70}")
    print(f"AUDIT CRAWLERS GOOGLE — {logfile}")
    print(f"{'='*70}\n")
    
    for crawler, data in sorted(stats.items(), key=lambda x: -x[1]['hits']):
        doc_status = "⚠ NON DOCUMENTÉ" if crawler in undocumented_uas else "✓ documenté"
        print(f"\n{crawler} [{doc_status}]")
        print(f"  Hits: {data['hits']}")
        print(f"  Status codes: {dict(data['statuses'].most_common(5))}")
        print(f"  Top paths:")
        for path, count in data['paths'].most_common(5):
            print(f"    {count:>6}  {path}")

if __name__ == '__main__':
    analyze_logs(sys.argv[1])

L'étape de vérification DNS (is_google_ip) est critique. Sans elle, vous comptabilisez les bots qui se font passer pour Google — ce qui fausserait complètement l'analyse. Google confirme cette méthode de vérification dans sa documentation sur la vérification de Googlebot.

Scénario réel : un média en ligne de 35 000 pages

Prenons un site média qui publie 80 articles par jour, avec un historique de 35 000 URLs indexées. En analysant 30 jours de logs, voici un profil de crawl typique :

Googlebot mobile : 420 000 hits/mois — le crawler principal, attendu
Googlebot desktop : 38 000 hits/mois — minoritaire depuis le passage au mobile-first
Googlebot-Image : 95 000 hits/mois — crawl des images, souvent oublié dans l'analyse
AdsBot-Google : 12 000 hits/mois — vérifie les landing pages AdSense/AdWords
GoogleOther : 67 000 hits/mois — significatif, et en augmentation constante depuis 2024
Google-Extended : 28 000 hits/mois — crawl lié à l'IA, même sans consentement explicite dans certains cas
User agents non identifiés (IPs Google confirmées) : 43 000 hits/mois

Ce dernier chiffre — 43 000 hits de crawlers Google non identifiables — représente environ 6% du crawl total Google sur ce site. Et ces requêtes touchent des zones spécifiques : pages AMP, endpoints d'API exposés, fichiers JSON-LD isolés, pages de pagination profonde.

Sur un site e-commerce avec des milliers de pages produits, filtres à facettes et variations, ce pourcentage peut monter à 10-15%. C'est du crawl budget consommé par des systèmes dont vous ne connaissez ni le but, ni les règles.

Impact sur le crawl budget et la configuration robots.txt

Le problème du ciblage par user agent

La plupart des configurations robots.txt ciblent des user agents spécifiques :

# robots.txt typique — INSUFFISANT
User-agent: Googlebot
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /search?*

User-agent: AdsBot-Google
Disallow: /internal/

User-agent: GoogleOther
Disallow: /

User-agent: Google-Extended
Disallow: /

Ce fichier semble complet. Il ne l'est pas. Les crawlers non documentés qui n'utilisent aucun des user agents listés tombent dans la règle User-agent: *. Si cette règle est permissive (ou absente), ces crawlers ont accès à l'intégralité du site.

L'approche défensive consiste à inverser la logique :

# robots.txt — approche défensive (whitelist)
# Bloquer tout par défaut
User-agent: *
Disallow: /

# Autoriser explicitement Googlebot principal
User-agent: Googlebot
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /search?*
Allow: /

# Autoriser Googlebot-Image sur les répertoires média
User-agent: Googlebot-Image
Disallow: /admin/
Allow: /

# Bloquer explicitement les crawlers IA
User-agent: GoogleOther
Disallow: /

User-agent: Google-Extended
Disallow: /

# Sitemap
Sitemap: https://media-example.fr/sitemap-index.xml

Le trade-off de cette approche : vous bloquez aussi les crawlers non documentés qui pourraient contribuer à l'indexation ou à l'affichage de rich results. C'est un choix assumé. Si votre priorité est le contrôle du crawl budget sur un gros site, la whitelist est plus sûre. Si vous êtes un petit SaaS de 200 pages, le crawl budget n'est pas votre problème et l'approche permissive reste viable.

Ce que robots.txt ne peut pas faire

Rappel crucial : robots.txt est une directive, pas un mécanisme de sécurité. Certains crawlers Google ne respectent pas robots.txt par design — c'est le cas d'AdsBot quand il vérifie les landing pages publicitaires. Pour les crawlers non documentés, leur comportement vis-à-vis de robots.txt n'est tout simplement pas garanti.

Si vous avez des endpoints sensibles (APIs internes, pages d'administration, données de staging exposées), la protection doit se faire au niveau serveur :

# Nginx — bloquer l'accès aux endpoints internes indépendamment de robots.txt
location /api/internal/ {
    # Autoriser uniquement les IPs internes
    allow 10.0.0.0/8;
    allow 172.16.0.0/12;
    deny all;
    return 403;
}

location /staging/ {
    # Auth basique en plus du blocage IP
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    
    # Header noindex en backup
    add_header X-Robots-Tag "noindex, nofollow" always;
}

# Rate limiting spécifique pour les bots
map $http_user_agent $is_bot {
    default 0;
    ~*googlebot 1;
    ~*bingbot 1;
    ~*google 1;
}

limit_req_zone $binary_remote_addr zone=bot_limit:10m rate=5r/s;

location / {
    if ($is_bot) {
        set $limit_key $binary_remote_addr;
    }
    limit_req zone=bot_limit burst=20 nodelay;
    # ... reste de la config
}

Les implications pour le rendering et le JavaScript

Les crawlers non documentés font-ils du rendering JS ?

C'est la question la plus sous-estimée. Googlebot principal utilise un moteur de rendering basé sur Chrome (headless) pour exécuter le JavaScript et indexer le contenu généré côté client. Mais qu'en est-il des centaines d'autres crawlers ?

La réponse probable : la majorité ne font pas de rendering JavaScript. Si vous servez un SPA en client-side rendering, ces crawlers voient probablement le HTML initial — c'est-à-dire une page vide ou un squelette avec des <div id="root"></div>.

Les conséquences sont concrètes :

Rich Results validation : les systèmes qui vérifient vos données structurées en production pourraient ne pas voir le JSON-LD injecté via JavaScript
AdsBot quality checks : si vos landing pages AdWords reposent sur du CSR, AdsBot peut évaluer une page vide et dégrader votre Quality Score
Systèmes anti-spam : un crawler anti-spam qui ne voit que du HTML vide pourrait interpréter cela comme du cloaking

C'est un argument supplémentaire — et souvent ignoré — en faveur du SSR ou du prerendering. Le SSR n'est pas uniquement une question d'indexation par Googlebot principal. C'est une question de compatibilité avec l'ensemble de l'écosystème de crawl Google.

Pour vérifier ce que les différents crawlers voient réellement, vous pouvez comparer les réponses serveur :

# Simuler un crawl sans rendering JS (ce que voient la plupart des bots)
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1)" \
  "https://votre-ecommerce.fr/produit/chaussures-running-42" | \
  grep -c '<script'

# Comparer avec le DOM rendu via Chrome headless
npx puppeteer-core --no-sandbox --headless \
  -e "const b=await require('puppeteer').launch({headless:'new'});
      const p=await b.newPage();
      await p.goto('https://votre-ecommerce.fr/produit/chaussures-running-42',{waitUntil:'networkidle0'});
      const html=await p.content();
      console.log(html.length);
      await b.close();"

# Si la taille du HTML diffère significativement (>50%), 
# votre contenu dépend du rendering JS

Stratégie de monitoring : détecter les anomalies de crawl en continu

Pourquoi les audits ponctuels ne suffisent pas

Un audit de logs trimestriel avec Screaming Frog Log Analyzer ou Oncrawl donne une photo à un instant T. Mais le paysage des crawlers Google évolue en continu. De nouveaux crawlers apparaissent (Google-Extended n'existait pas avant septembre 2023), d'autres changent de comportement (GoogleOther a vu son volume augmenter de manière significative en 2024-2025), et des incidents peuvent surgir à tout moment.

Scénario réaliste : vous déployez une nouvelle version de votre site e-commerce un vendredi. Un middleware mal configuré renvoie du 200 avec un body vide pour toutes les requêtes dont le user agent n'est pas dans votre liste blanche. Googlebot principal continue de fonctionner (il est dans la liste), mais tous les autres crawlers Google reçoivent des pages vides. Les systèmes de vérification des rich results cessent de voir vos données structurées product. Deux semaines plus tard, vos rich snippets produits disparaissent des SERP. Le trafic organique baisse de 15%.

Ce type de régression ne se voit pas dans Search Console avant des jours, parfois des semaines. Un outil de monitoring comme SEOGard, qui surveille en continu les réponses serveur et les changements de meta tags, détecte ce type d'anomalie dans les heures qui suivent le déploiement.

Mettre en place des alertes sur les patterns de crawl

Au-delà du monitoring applicatif, vous pouvez configurer des alertes basiques sur vos logs :

#!/bin/bash
# alert_crawl_anomaly.sh — à exécuter via cron toutes les heures
# Détecte les pics de crawl de crawlers Google non standard

LOG="/var/log/nginx/access.log"
THRESHOLD=500  # hits/heure au-delà duquel on alerte
ALERT_EMAIL="[email protected]"

# Compter les hits de crawlers Google non-Googlebot dans la dernière heure
CURRENT_HOUR=$(date -d '1 hour ago' '+%d/%b/%Y:%H')

NON_STANDARD_HITS=$(grep "$CURRENT_HOUR" "$LOG" | \
  grep -i 'google' | \
  grep -iv 'Googlebot/2.1' | \
  grep -iv 'Googlebot-Image' | \
  grep -iv 'Googlebot-News' | \
  wc -l)

if [ "$NON_STANDARD_HITS" -gt "$THRESHOLD" ]; then
  # Extraire les top user agents pour le diagnostic
  TOP_UAS=$(grep "$CURRENT_HOUR" "$LOG" | \
    grep -i 'google' | \
    grep -iv 'Googlebot/2.1' | \
    awk -F'"' '{print $6}' | \
    sort | uniq -c | sort -rn | head -10)

  echo "ALERTE: $NON_STANDARD_HITS hits de crawlers Google non standard
  
Top User Agents:
$TOP_UAS" | mail -s "[SEO] Crawl anomaly detected" "$ALERT_EMAIL"
fi

Ce script est rudimentaire mais efficace en première ligne de défense. Pour une solution plus robuste, les données de logs devraient alimenter un pipeline ELK (Elasticsearch, Logstash, Kibana) ou un équivalent, avec des dashboards dédiés au crawl SEO.

Ce que cette révélation implique pour l'avenir du SEO technique

L'admission de Google sur l'existence de centaines de crawlers non documentés confirme ce que les praticiens SEO techniques observent depuis des années dans leurs logs. Mais elle ouvre aussi des questions inconfortables.

Le contrôle du crawl est une illusion partielle

Vous contrôlez ce que vous pouvez identifier. Si Google utilise des crawlers qui ne s'identifient pas clairement — ou qui se présentent sous des user agents génériques — votre capacité à segmenter et gérer le crawl est structurellement limitée.

La seule stratégie résiliente : rendre votre site crawlable et performant par défaut, plutôt que de tenter de micro-gérer le crawl par user agent. Cela signifie :

Des réponses serveur rapides (<200ms TTFB) pour absorber n'importe quel volume de crawl sans impact utilisateur
Un sitemap XML propre et à jour qui guide tous les crawlers vers vos pages prioritaires
Du HTML côté serveur (SSR/SSG) qui ne dépend pas du rendering JS pour afficher le contenu critique
Des canonicals cohérents qui limitent le crawl des pages dupliquées
Des chaînes de redirections nettoyées qui ne gaspillent pas le crawl budget, quel que soit le crawler

La question de la transparence et du consentement

Google-Extended a été créé pour donner aux éditeurs un levier de contrôle sur l'utilisation de leurs contenus pour l'IA. Mais si des dizaines d'autres crawlers non documentés collectent les mêmes données sous des identifiants différents, ce levier est-il réel ?

C'est une question de gouvernance plus que de technique. Mais en tant que SEO technique, vous devez la poser à vos stakeholders : bloquer Google-Extended ne sert à rien si GoogleOther ou un crawler non identifié fait le même travail. La seule protection technique robuste reste le contrôle d'accès côté serveur (authentification, blocage IP) — pas les directives de crawl.

Le takeaway opérationnel

Le crawl de Google sur votre site est significativement plus complexe que ce que la documentation officielle laisse entrevoir. Les centaines de crawlers non documentés consomment du crawl budget, accèdent à des zones potentiellement sensibles, et ne font probablement pas de rendering JavaScript. Votre réponse doit être structurelle : SSR par défaut, logs analysés en continu, configuration serveur défensive. Un monitoring automatisé — via SEOGard ou un pipeline de logs custom — est le seul moyen de détecter les anomalies de crawl avant qu'elles ne se transforment en pertes de visibilité.