Tu ouvres Google Search Console, tu vas dans Crawl stats pour comprendre un pic de crawl, et… le sélecteur de dates te fait n’importe quoi. Impossible d’isoler une journée, de comparer proprement avant/après, bref tu te retrouves à commenter un graphe que tu ne peux même pas manipuler.
Le piège, c’est de rester bloqué là-dessus. Si tu dois expliquer un incident (ou rassurer un client) tu n’as pas besoin de l’UI de GSC pour connaître la réalité. Tu as besoin de preuves. Et les preuves, c’est ton trafic HTTP réel côté CDN, load balancer ou serveur. Donc on bascule sur les logs, on reconstruit 2–3 métriques utiles, et on arrête de « lire du thé » dans un rapport cassé.
Bug du sélecteur de dates dans Crawl stats : le bon réflexe, c’est de ne pas sur-interpréter
Quand Crawl stats est bancal, le problème n’est pas juste « c’est pénible ». Le vrai risque, c’est de sur-interpréter. Tu crois comparer deux périodes alors que le filtre n’a pas bougé. Tu penses être sur 24h, tu es sur 7 jours. Tu tires une conclusion sur une hausse des 5xx alors que tu regardes en fait un mix de jours.
Mon avis là-dessus est simple : tant que tu n’es pas capable de reproduire la même vue deux fois, tu ne fais pas d’analyse, tu fais de la narration. Pour un diagnostic, surtout quand ça parle de crawl budget, de surcharge serveur, de spikes, il te faut une source « bête et méchante » qui ne dépend pas d’une interface. Les logs remplissent exactement ce rôle.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Ce que tu veux vraiment mesurer quand tu « analyses un pic de crawl »
Dans 90% des cas, la question derrière « pourquoi Googlebot a crawlé plus ? » se résume à : est-ce que c’est un changement côté Google (rythme, découverte d’URLs, recrawl) ou est-ce que c’est un changement côté site (nouveaux liens internes, facettes qui explosent, infinite URLs, variations d’HTTP, cache qui tombe, latence qui grimpe) ?
Pour trancher, tu n’as pas besoin de 50 dimensions. Tu veux trois axes solides. Un volume (combien de requêtes bot), une qualité de réponse (codes HTTP, et en particulier 2xx/3xx/4xx/5xx), et une capacité (temps de réponse, idéalement un percentile genre p95 pour voir les mauvaises queues). Si tu ajoutes un quatrième axe, prends la « surface touchée » : quels chemins / templates ont pris cher, parce que ça t’amène directement au code ou à la config fautive.
Récupérer des logs exploitables (origin, CDN, WAF) sans te tirer une balle dans le pied
Avant de parser quoi que ce soit, il faut savoir d’où viennent tes chiffres. Des logs Nginx/Apache sur l’origin, c’est parfait pour voir ce que ton serveur a réellement servi, mais ça ne voit pas ce que le CDN a absorbé. Des logs CDN (Cloudflare, Fastly, Akamai…), c’est parfait pour observer le trafic « vu de l’extérieur », mais tu dois comprendre ce qui est considéré comme un hit, un miss, un edge error, et comment la plateforme logge les statuts (parfois tu as un statut edge et un statut origin).
Ce que je fais en incident, c’est simple : si le sujet est « mon site est en PLS / j’ai des 5xx », je pars d’abord sur l’origin ou le load balancer. Si le sujet est « Googlebot semble s’exciter / je suspecte un crawl inflation », je commence côté CDN parce que c’est là que tu vois le volume réel et les patterns d’URL, même quand ton cache te protège.
Dernier point terrain : ne te contente pas du user-agent « Googlebot ». Il y a du spoof, et tu peux vite raconter n’importe quoi. Si tu es dans un contexte sensible (attaque, scraping, coût infra), tu valides les IP via la méthode officielle de reverse DNS puis forward DNS. Si tu es juste en train d’expliquer un pic raisonnable et que tu as déjà des signaux cohérents (IP ranges connues, comportement propre, taux d’erreurs faible), tu peux démarrer avec le user-agent, puis durcir si besoin.
Recréer un mini “Crawl stats” à partir des logs : volume, statuts, latence p95
L’objectif n’est pas de refaire Search Console. L’objectif, c’est d’obtenir un graphe que tu peux défendre. Un CSV qui contient, par heure ou par jour : nombre de requêtes Googlebot, répartition des codes HTTP, et temps de réponse (ou au minimum une latence moyenne, mais le p95 est bien plus parlant dès que ça dégrade).
Sur un Nginx en log format classique (avec le request time), tu peux déjà sortir un premier niveau d’info en 2 minutes. C’est brut, mais ça donne une direction, surtout si tu filtres sur une fenêtre temporelle précise.
# Exemple simple : volume + statuts pour Googlebot depuis un access.log Nginx
# À adapter selon ton format de logs, et idéalement à exécuter sur une fenêtre de temps
grep -i 'Googlebot' /var/log/nginx/access.log \
| awk '{print substr($4,2,12), $9}' \
| sort \
| uniq -c \
| head -n 50
# substr($4,2,12) prend un bout du timestamp : "10/Mar/2026"
# $9 c’est le status code dans le format combined classiqueCe genre de commande ne te donnera pas le p95. Mais elle te dira vite si ton pic est corrélé à une hausse de 5xx, ou si c’est « juste » plus de 200/304. Et ça, c’est déjà un énorme tri. Pour la latence p95, tu passes sur un vrai traitement (SQL, notebook, BigQuery, ClickHouse, même un script), parce que tu veux éviter les moyennes trompeuses.
Si tu as des logs dans BigQuery (cas assez courant via export CDN), une requête SQL basique te sort directement une vue exploitable par jour, avec un p95. Et là tu n’es plus dans l’approximation.
-- Exemple BigQuery : métriques journalières Googlebot
-- Suppose des colonnes: ts (timestamp), user_agent, status, request_path, response_time_ms
SELECT
DATE(ts) AS day,
COUNT(*) AS googlebot_hits,
COUNTIF(status BETWEEN 200 AND 299) AS s2xx,
COUNTIF(status BETWEEN 300 AND 399) AS s3xx,
COUNTIF(status BETWEEN 400 AND 499) AS s4xx,
COUNTIF(status BETWEEN 500 AND 599) AS s5xx,
APPROX_QUANTILES(response_time_ms, 100)[OFFSET(95)] AS p95_ms
FROM `project.dataset.logs`
WHERE LOWER(user_agent) LIKE '%googlebot%'
AND ts >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
GROUP BY day
ORDER BY day DESC;Une fois que tu as ça, tu peux répondre proprement à la question qui compte : « on a eu +80% de crawl, mais on est restés à 0,2% de 5xx et le p95 n’a pas bougé » (donc pas un incident infra), ou au contraire « le p95 explose et les 5xx suivent » (donc ton serveur a suffoqué, et Googlebot a probablement reculé ensuite).
Trouver la cause réelle : les patterns qui reviennent (et qui font mal)
Quand tu as le volume et les statuts, tu passes à la partie utile : qu’est-ce que Googlebot a tapé ? Là, les logs sont imbattables, parce que tu peux regrouper par chemins, paramètres, types de pages, et voir la signature du problème.
Le cas le plus fréquent que je vois, c’est la génération d’URLs quasi infinies. Une facette e-commerce trop permissive, une combinaison de filtres indexables, des paramètres qui créent des pages distinctes sans valeur, ou un moteur de recherche interne crawlable. Tu peux ne rien voir côté UI, mais côté logs tu vois des milliers d’URLs uniques qui ne devraient même pas exister. Et si en plus elles renvoient 200, tu as offert à Google une aire de jeu illimitée.
Autre classique : le thundering herd après un purge de cache ou une mauvaise config de cache-control. Googlebot repasse, le CDN miss, ton origin encaisse tout d’un coup, la latence grimpe, puis arrivent les timeouts et les 5xx. Le crawl spike n’est pas « la cause », c’est le révélateur. Si tu vois dans tes logs une hausse des MISS, une baisse des HIT, ou des requêtes qui tapent toujours les mêmes pages lourdes, tu as une piste très concrète.
Il y a aussi les incidents « plus discrets » : une redirection qui boucle sur un segment d’URLs, un 404 qui devient 200 (soft 404, template d’erreur mal géré), un déploiement qui rend des pages dynamiques non cachables, ou un changement de pagination qui crée des variations d’URL. Ce n’est pas spectaculaire, mais ça suffit à déclencher un recrawl massif, ou à faire gaspiller du budget sur des pages inutiles.
Expliquer le pic (vraiment) : corrélation avec déploiements, infra et changements SEO
Une analyse qui tient debout, ce n’est pas juste « Google a crawlé plus ». C’est un enchaînement de faits. Tu prends ton graphe de hits Googlebot par heure, tu le poses à côté de tes événements réels : déploiements, purges, incidents, changements robots.txt, règles de redirect, mise à jour de sitemap, ou ajout massif de liens internes.
Si tu as un pic à 03:00 et un déploiement à 02:45, tu as déjà un angle. Si tu as un pic à 11:00, et que ton CDN a eu une dégradation régionale à 10:50, pareil. Et si tu n’as aucun événement, mais que tu vois une explosion d’URLs uniques sur une facette, tu as un plan d’action SEO/tech clair : canonicals, noindex, règles de paramètres, internal linking, et parfois un blocage temporaire (proprement documenté) le temps de corriger.
Un mini-dashboard “sans outil” qui marche : CSV + 2 graphes + une routine
Tu n’as pas besoin d’un stack observabilité complet pour être efficace. Ce qui marche bien, même en mode artisanal, c’est un fichier (ou une table) qui contient tes métriques journalières, et deux graphes : le volume Googlebot et le taux de 5xx, avec le p95 en ligne secondaire. Si tu veux aller un cran plus loin, ajoute un top des chemins (ou des templates) les plus crawls, parce que ça accélère chaque investigation.
Le vrai gain arrive quand tu rends ça routinier. Une vérif hebdo de 10 minutes, toujours les mêmes indicateurs, et tu repères les dérives avant qu’elles deviennent un incident. Et quand GSC te refait un caprice, tu ne paniques pas : tu as déjà ton historique ailleurs.
Quand GSC redevient utilisable : comment recoller les morceaux sans te raconter d’histoires
Quand l’UI refonctionne, tu peux réutiliser Crawl stats pour la tendance globale et quelques détails. Mais je te conseille de garder un principe : GSC pour la vision Google, les logs pour la réalité HTTP. Les deux se complètent, mais en cas de conflit, c’est souvent les logs qui te disent ce que ton infra a effectivement servi.
Et surtout, ne cherche pas à faire coller les chiffres au pourcentage près. Entre le CDN, les retries, les 304, les caches, les variations de sampling et les définitions implicites, tu vas perdre du temps à vouloir une égalité parfaite. Ce que tu veux, c’est une explication cohérente, défendable, et actionnable.
Mon avis (tranché) : dépendre d’une UI pour faire du diagnostic, c’est se mettre en risque
Je vois encore trop de diagnostics SEO techniques construits uniquement sur Search Console. Ça marche… jusqu’au jour où le rapport a un bug, ou jusqu’au jour où tu as besoin d’un niveau de détail que l’outil ne donnera jamais (latence p95, cache HIT/MISS, template exact, corrélation avec un deploy).
Si tu fais du SEO un peu sérieux, tu n’es pas obligé de devenir SRE. Mais tu dois avoir une sortie de secours. Un accès logs, même partiel, même via le CDN, et un petit rituel de métriques simples. Ça te sort de la posture « GSC dit X », et ça te remet dans une posture beaucoup plus confortable : « voilà ce qui s’est réellement passé, et voilà ce qu’on corrige ».
