Whitelister Googlebot sans te tirer une balle dans le WAF

Si tu as déjà entendu « on whitelist Googlebot » en réunion, tu sais à quel point ça peut partir en vrille. Dans le meilleur des cas, ça sert juste à nettoyer des logs. Dans le pire, tu viens d’ouvrir une porte VIP à n’importe quel scraper qui sait se faire passer pour Google.

Et comme si ce n’était pas assez, Google a annoncé un changement d’emplacement des fichiers d’IP ranges de ses crawlers. Donc le petit script “vite fait” qui télécharge un JSON depuis une URL hardcodée risque de casser… silencieusement. Ici on remet les choses au carré : où récupérer ces ranges de façon robuste, comment vérifier un vrai Googlebot (sans se raconter des histoires), et à quoi ça sert vraiment en prod (WAF, rate limiting, analytics). Bonus : ce que l’angle « bytes we process » change dans ta manière de servir des pages à un crawler.

Le mythe du « je whitelist Googlebot » (et pourquoi c’est un piège classique)

Whitelister Googlebot, si on parle franchement, ça mélange plusieurs besoins qui n’ont pas du tout le même niveau de risque. Filtrer Google dans tes logs ou dans tes dashboards pour y voir plus clair, c’est plutôt safe. Donner un bypass WAF global parce que « c’est Google », là tu joues avec le feu.

Le problème, c’est que l’User-Agent ne vaut rien. N’importe qui peut envoyer Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) et te faire croire à une visite “officielle”. Si ton “whitelist” se base sur ça, tu n’as pas whiteliste Googlebot, tu as whiteliste les menteurs.

La seule façon raisonnable de faire, c’est de traiter Googlebot comme un client externe qu’on authentifie “indirectement” : tu valides l’IP et tu valides le reverse DNS (et tu fais la vérification dans le bon sens). Ça demande un peu plus de plomberie, mais c’est boring, et boring c’est bien.

IP ranges Google crawlers : la mise à jour qui casse les scripts

Google publie des fichiers listant des plages d’IP pour ses crawlers. Beaucoup d’équipes s’en servent pour enrichir des logs (tagger “googlebot”), pour ajuster du rate limiting, ou pour appliquer des règles WAF plus tolérantes. Le souci, c’est qu’en mars 2026 Google a annoncé un nouvel emplacement pour ces fichiers.

Le point important n’est pas « quel est le nouveau lien » (tu le trouveras dans l’annonce officielle), c’est comment tu consommes ce lien. Si ton code dépend d’une URL figée, sans redirection, sans cache, sans diff, sans alerte, tu finiras par avoir un système faux. Et un système faux en sécurité, ça ne fait pas “un petit bug”, ça fait un incident.

Mon conseil : accepte l’idée que cette ressource peut bouger. Donc ton job, c’est de rendre ton ingestion résiliente (réessais), observable (logs + métriques), et auditable (diff de ce qui change).

Le script qui tient en prod : download, cache, diff, alerte (sans parano inutile)

Ce que tu veux, c’est une tâche planifiée qui télécharge la ressource officielle, met en cache localement, compare au dernier état connu, puis te prévient si ça change. Pas besoin d’en faire un produit, mais il faut au minimum éviter le “je télécharge et j’écrase”, parce que le jour où tu récupères une erreur HTML, un 404, ou un JSON vide, tu as perdu l’historique et tu ne sais même pas ce qui s’est passé.

Le bon pattern est simple : tu stockes le fichier brut (ou une version normalisée), tu gardes un hash, tu fais du conditional request (ETag/If-None-Match si possible), et tu refuses d’appliquer une mise à jour si le contenu est manifestement invalide.

#!/usr/bin/env bash
set -euo pipefail

# Récupère l'URL courante depuis l'annonce Google (ne pas hardcoder "pour toujours").
URL="${GOOGLE_CRAWLER_IP_RANGES_URL:?export GOOGLE_CRAWLER_IP_RANGES_URL}"
STATE_DIR="/var/lib/googlebot-ipranges"
mkdir -p "$STATE_DIR"

HEADERS="$STATE_DIR/headers.tmp"
NEWFILE="$STATE_DIR/ipranges.new.json"
OLDFILE="$STATE_DIR/ipranges.json"
HASHFILE="$STATE_DIR/ipranges.sha256"

ETAG=""
if [[ -f "$STATE_DIR/etag.txt" ]]; then
  ETAG="$(cat "$STATE_DIR/etag.txt")"
fi

# Conditional request si on a un ETag.
CURL_ARGS=( -fsSL --retry 3 --retry-delay 2 -D "$HEADERS" -o "$NEWFILE" "$URL" )
if [[ -n "$ETAG" ]]; then
  CURL_ARGS=( -fsSL --retry 3 --retry-delay 2 -H "If-None-Match: $ETAG" -D "$HEADERS" -o "$NEWFILE" "$URL" )
fi

# Si 304, curl crée quand même un fichier vide selon options; on gère via status code.
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "${CURL_ARGS[@]}")

if [[ "$STATUS" == "304" ]]; then
  echo "No change (304)"
  exit 0
fi

# Garde-fou: le fichier doit ressembler à du JSON.
python3 - <<'PY'
import json,sys
p=sys.argv[1]
with open(p,'rb') as f:
    json.load(f)
PY
"$NEWFILE"

# Hash + diff simple.
NEWHASH=$(sha256sum "$NEWFILE" | awk '{print $1}')
OLDHASH=""
[[ -f "$HASHFILE" ]] && OLDHASH=$(cat "$HASHFILE")

if [[ "$NEWHASH" == "$OLDHASH" ]]; then
  echo "No change (hash)"
  exit 0
fi

# Swap atomique.
mv "$NEWFILE" "$OLDFILE"
echo "$NEWHASH" > "$HASHFILE"

# Capture le nouvel ETag si présent.
NEW_ETAG=$(awk 'BEGIN{IGNORECASE=1} $1=="etag:"{sub(/\r$/,"",$0); print substr($0,6)}' "$HEADERS" | head -n1 | xargs || true)
if [[ -n "$NEW_ETAG" ]]; then
  echo "$NEW_ETAG" > "$STATE_DIR/etag.txt"
fi

echo "Updated Google crawler IP ranges: $OLDHASH -> $NEWHASH"
# Ici tu branches une alerte: mail, Slack, PagerDuty, peu importe.

Ce script ne fait pas tout, mais il coche les cases qui évitent 80% des galères : il ne “casse” pas l’état précédent, il voit les changements, il réduit les downloads inutiles, et il est dur à tromper avec une réponse invalide. Pour aller plus loin, tu peux normaliser le JSON (tri de clés, tri de tableaux) avant de hasher, pour éviter des faux positifs si le format change sans changer le fond.

Vérifier Googlebot proprement : reverse DNS, puis forward DNS (sinon ça ne vaut rien)

Si tu veux identifier un vrai Googlebot, le seul truc raisonnable est la procédure recommandée par Google : tu pars de l’IP qui t’appelle, tu fais un reverse DNS pour obtenir un hostname, tu vérifies que ce hostname est bien dans un domaine attendu (typiquement .googlebot.com ou .google.com selon le bot), puis tu refais une résolution DNS “forward” de ce hostname et tu vérifies que tu retombes bien sur la même IP.

La double résolution est cruciale. Sans forward check, tu peux te faire avoir par un PTR malicieux. Et non, « ça a l’air de finir par googlebot.com » n’est pas un protocole de sécurité.

import socket

ALLOWED_SUFFIXES = (".googlebot.com", ".google.com")

def is_real_googlebot(ip: str) -> bool:
    try:
        host, _, _ = socket.gethostbyaddr(ip)  # reverse DNS
    except Exception:
        return False

    host = host.rstrip(".")
    if not host.endswith(ALLOWED_SUFFIXES):
        return False

    try:
        addrs = {ai[4][0] for ai in socket.getaddrinfo(host, None)}  # forward DNS
    except Exception:
        return False

    return ip in addrs

# Exemple: print(is_real_googlebot("66.249.66.1"))

Deux nuances terrain. D’abord, faire du DNS en temps réel sur ton chemin de requête web, c’est souvent une mauvaise idée. C’est lent, ça peut timeout, et ça te met une dépendance externe dans la hot path. La bonne approche est généralement d’étiqueter offline (traitement de logs) ou d’utiliser une couche de cache courte (quelques heures) si tu en as vraiment besoin en temps réel.

Ensuite, si tu utilises aussi des IP ranges, ne les mets pas en concurrence avec la vérif DNS : pense-les comme deux outils différents. Les ranges, c’est pratique pour classifier vite et en masse. La vérif reverse/forward, c’est pour l’authentification “logique” quand tu veux être strict.

À quoi ça sert vraiment : logs, analytics, crawl monitoring, et rate limiting intelligent

Le cas d’usage le plus sain, c’est l’observabilité. Tu veux pouvoir répondre à des questions basiques sans te noyer : est-ce que Googlebot crawl plus depuis hier, quelles URLs il tape, combien de 5xx il se prend, est-ce qu’il insiste sur des pages lentes, est-ce que tu renvoies des 403 qui n’ont rien à faire là. Là, étiqueter correctement le trafic Googlebot dans tes logs Nginx/Cloudflare/ALB est extrêmement utile.

Deuxième usage qui marche bien : le rate limiting fin. Pas pour “favoriser Google”, plutôt pour éviter de le punir pour de mauvaises raisons. Exemple classique : tu as un limit par IP trop agressif sur un endpoint public, tu bloques Googlebot au moment où il essaie de rafraîchir ton contenu, et tu te retrouves avec des erreurs de crawl. Si tu sais identifier Googlebot de façon fiable, tu peux lui donner une marge un peu plus haute, ou surtout éviter de le faire passer dans des mécanismes anti-bot qui déclenchent sur des patterns “crawling-like”.

Troisième usage, plus subtil : le debug SEO technique. Quand un client te dit « Google ne voit pas mes pages », c’est une perte de temps monumentale si tu n’as pas la capacité de prouver ce que Googlebot a vraiment fait. Un bon tagging + quelques requêtes dans un système de logs, et tu passes de “ressenti” à “faits”.

WAF : le bypass Googlebot, oui… mais seulement sur un périmètre minuscule

Le bypass WAF, c’est là où les équipes se font mal. La tentation est énorme : tu vois des faux positifs, tu vois du JavaScript challenge, tu vois des 403, et tu te dis « on whitelist Google et on n’en parle plus ». Mauvaise idée si tu l’appliques large.

Si tu dois le faire, fais-le comme un chirurgien. Tu limites à des routes publiques strictes, sans effets de bord, sans write, sans auth, sans endpoints “admin” cachés, sans API interne exposée par erreur. Et tu gardes des règles de sécurité de base actives. Un bot Google ne devrait jamais avoir le pouvoir de contourner des contrôles qui protègent tes données.

Ce que je vise en pratique : un bypass très local pour éviter des challenges anti-bot sur des pages HTML crawlées, et uniquement si j’ai une preuve claire que le WAF gêne l’indexation. Sinon, je préfère corriger la règle WAF elle-même ou travailler sur les signaux qui déclenchent (headers, cookies, patterns d’URL), parce que c’est plus durable.

« Inside Googlebot » et les “bytes we process” : la perf crawl n’est pas qu’une histoire de nombre d’URLs

Le billet « Inside Googlebot » remet un sujet sur la table que beaucoup de devs sous-estiment : Google ne “compte” pas uniquement des pages, il compte aussi des octets à traiter. Donc si tu sers des documents inutilement lourds, tu peux mécaniquement réduire la quantité de contenu que Googlebot va pouvoir récupérer chez toi, à ressources égales.

Sur des sites modernes, la cause n’est pas toujours l’image. Souvent, c’est du HTML gonflé (inline JSON énorme pour hydrater une app), des scripts bloquants, des payloads inutiles sur des pages qui pourraient être sobres, ou des endpoints qui renvoient des variations quasi identiques mais jamais cacheables. Tu ne le vois pas forcément côté navigateur, parce que le navigateur a son cache, ses priorités, et un humain ne navigue pas comme un crawler.

Si tu veux un effet rapide, je regarderais d’abord si tu compresses correctement (Brotli/gzip), si tu renvoies des 304 quand c’est possible (ETag/Last-Modified), si tu évites d’embarquer des blobs de données non utilisés dans le HTML, et si tu ne laisses pas traîner des URLs “infinies” qui génèrent des pages uniques sans valeur (paramètres, filtres, tri). Là, tu gagnes à la fois en perf et en crawl efficiency, sans magie.

Les erreurs que je vois le plus souvent (et comment elles finissent)

L’erreur n°1, c’est de whitelister sur l’User-Agent. Ça finit presque toujours par un jour où tu découvres dans tes logs qu’un scraper a profité du tapis rouge. Parfois, c’est juste du scraping. Parfois, c’est une tentative de contournement plus sale.

L’erreur n°2, c’est de faire reposer un mécanisme de sécurité sur un fichier d’IP ranges récupéré “quand on y pense”. Les ranges changent, les URLs changent, les formats changent. Sans job planifié, sans diff, sans alerte, tu ne sais pas quand tu es devenu faux.

L’erreur n°3, c’est de faire du reverse DNS live sur chaque requête et de se féliciter du résultat. En prod, ça peut te créer de la latence, du load DNS, et des comportements bizarres en cas d’incident côté résolveur. Si tu as besoin d’un signal temps réel, cache-le proprement, et mesure le taux de timeouts.

L’erreur n°4, côté SEO, c’est de “résoudre le crawl” en autorisant tout et n’importe quoi. Googlebot n’a pas besoin d’accéder à tes endpoints write, ni à tes pages admin, ni à des URLs générées à la volée sans intérêt. Tu veux aider l’indexation, pas agrandir ton périmètre d’attaque.

Conclusion : rends l’identification fiable, puis décide ce que tu en fais

Identifier Googlebot, ce n’est pas un objectif en soi. C’est un outil. Donc commence par rendre la donnée vraie (ranges maintenues proprement, reverse/forward DNS quand tu as besoin d’être strict), puis seulement ensuite tu choisis les usages : meilleure lecture des logs, rate limiting plus intelligent, mitigation WAF très ciblée.

Et si tu veux un “next step” utile : une fois que tu sais distinguer Googlebot correctement, regarde ce que tu lui sers vraiment. Le billet « Inside Googlebot » est un bon rappel que chaque kilo inutile que tu renvoies est une petite taxe sur ton crawl. Ça se paye sur la durée.

Sources

• Google Search Central – New Location for the Google Crawlers' IP Range Files
• Google Search Central – Inside Googlebot: demystifying crawling, fetching, and the bytes we process