J'avoue, quand j'ai ouvert mon premier fichier log serveur il y a des années, j'ai cru que c'était un bug. Des lignes, des lignes, des lignes. Rien que des lignes. Impossible d'y voir autre chose qu'un bruit blanc numérique.
Pourtant, ce fichier contient tout. Chaque visite de Googlebot, chaque requête échouée, chaque page que le robot a jugée — ou pas — digne d'être explorée. Et c'est là que commence la vraie chasse aux anomalies.
Pourquoi analyser les logs serveur est crucial
Avouons-le, la plupart des webmasters passent à côté. Ils regardent Google Search Console, c'est déjà bien. Mais les logs, c'est le niveau supérieur. C'est la vérité brute du serveur, sans filtre, sans interprétation.
Un log de serveur web, pour rappel, « conserve un enregistrement des tendances de trafic et des erreurs », comme le rappelle Elastic. C'est l'historique principal de tout ce qui se passe. Et pour le crawl, c'est une mine d'or.
Pourquoi ? Parce que Googlebot ne vous dit pas tout. Search Console vous montre une vision lissée. Les logs, eux, vous montrent chaque seconde de l'exploration : l'URL visitée, l'heure exacte, le statut HTTP, l'agent utilisateur. Et c'est dans ces détails que se cachent les anomalies.
Le problème, c'est que la plupart des gens ne savent pas quoi chercher. Ils ouvrent le fichier, voient des milliers de lignes, et referment. Je l'ai fait. Pendant des mois.
Qu'est-ce qu'une anomalie de crawl ?
Une anomalie de crawl, c'est un comportement inattendu du robot d'indexation. Le « robot explore régulièrement le web en suivant tous les liens qu'il trouve et analyse les pages jugées intéressantes », explique la CNIL. C'est le fonctionnement normal.
L'anomalie, c'est quand ce fonctionnement dérape.
J'ai passé des nuits à corréler des logs avec des données Google Search Console, et voici les 4 types d'anomalies que j'ai rencontrées le plus souvent :
- Les pics soudains de crawl : Googlebot débarque sur votre serveur 5 fois plus que d'habitude. Résultat, le serveur ralentit, les vrais utilisateurs trinquent, et vous perdez des ventes. Je l'ai vu arriver après un redesign : en 24 heures, le nombre de requêtes par seconde est passé de 12 à 47.
- Les boucles de redirection : le robot tourne en rond sur des URLs qui se redirigent entre elles. Ça bouffe du budget crawl, ça n'indexe rien. Et Google n'aime pas.
- Les patterns anormaux d'User-Agent : vous voyez un « Googlebot » qui crawl comme jamais, mais le User-Agent est bizarre. Parfois, c'est un faux. D'autres fois, c'est un vrai Googlebot qui se fait passer pour un mobile, ce qui peut provoquer des comportements inattendus.
- Des erreurs 404 ou 500 qui grimpent en flèche : normalement, un taux d'erreur 404 sous les 2-3 %, c'est acceptable. Au-delà de 5 %, c'est une alerte. Si vous voyez 12 % un matin, il y a un problème.
Comment reconnaître un pattern de crawl anormal
La première chose que je fais quand je soupçonne une anomalie, c'est de regarder le nombre de requêtes par heure. Un graphique tout plat, et soudain un pic 3 fois plus haut ? Intéressant. Mais attention : un pic peut être normal (Google découvre un nouveau contenu, une mise à jour d'algorithme le fait recrawler massivement). Ce qui est anormal, c'est le pic qui ne redescend pas, ou qui revient toutes les 3 heures comme un métronome.
Là, je vérifie les User-Agents. Un bon réflexe : comparer la répartition des User-Agents dans les logs avec celle de Search Console. Si l'une montre 30 % de « Googlebot Mobile » et l'autre 5 %, il y a incohérence. J'ai déjà trouvé un bot chinois qui se faisait passer pour Googlebot en changeant son User-Agent.
Mon conseil : regardez aussi les temps de réponse. Une page qui met 3 secondes à répondre au lieu de 200 ms, c'est un signal que quelque chose cloche. Parfois, c'est juste le serveur qui souffre. Parfois, c'est une attaque DDoS déguisée en crawl.Les outils pour analyser les logs
Franchement, analyser des logs à la main, c'est possible sur un petit site. Au-delà de 50 000 requêtes par jour, ça ne tient plus. Il faut des outils.
ELK Stack : la référence
Elasticsearch, Logstash, Kibana. Le trio infernal. Vous ingérez vos logs dans Logstash, vous les stockez dans Elasticsearch, et vous visualisez tout dans Kibana. C'est puissant. C'est aussi un peu lourd à mettre en place si vous n'avez jamais fait de DevOps.
Ma première installation ELK a mis 3 jours à être opérationnelle. Et j'ai passé une semaine à configurer les bons dashboards. Mais une fois que c'est fait, vous avez une vision temps réel de tout le crawl. Vous pouvez filtrer par User-Agent, par code statut, par URL. Vous pouvez configurer des alertes : « Si le nombre de 404 dépasse 5 % du total des requêtes Googlebot, envoie un email. »
Points clés à retenir
- Les logs serveur contiennent la vérité brute du crawl, sans filtre Search Console
- Une anomalie de crawl n'est pas juste un pic de requêtes : c'est un pattern qui dure, qui se répète ou qui provoque une dégradation des performances
- Le taux d'erreur 404 au-dessus de 5 % est un seuil d'alerte fiable
- La corrélation logs + Search Console + données business permet d'isoler les anomalies contextuelles
- ELK Stack, GoAccess ou un script Python sont les outils les plus efficaces
- Automatisez les alertes : un humain ne peut pas surveiller 50 000 requêtes par jour
Le bon vieux script Python
J'ai un petit script qui lit les logs, les parse avec une regex et calcule des métriques simples : nombre de requêtes par minute, top 10 des URLs les plus crawllées, répartition des statuts HTTP. Il tourne toutes les heures sur un VPS et m'envoie un rapport par email si quelque chose cloche.
Ça m'a coûté 2 heures de code. Et ça m'a sauvé un jour où 50 000 URLs en erreur 301 étaient crawlées en boucle. Sans ça, Google aurait perdu des jours là-dessus.
L'approche minimaliste : si vous n'avez pas le temps de monter un ELK, GoAccess est un bon compromis. C'est un analyseur de logs en ligne de commande qui génère un rapport HTML. Vous le lancez, il vous sort le nombre de requêtes par IP, par URL, par statut. Simple et efficace. Je l'ai utilisé pendant un an avant de passer à ELK.Comment automatiser la détection
Le secret, c'est de fixer des seuils. Sans seuil, vous noyez votre équipe dans des alertes. Avec des seuils, vous ne recevez que ce qui mérite votre attention.
Voici les seuils que j'utilise :
| Métrique | Seuil d'alerte | Action |
|---|---|---|
| Nombre de requêtes Googlebot / heure | + 300 % par rapport à la moyenne | Vérifier le User-Agent, le type de contenu crawlée |
| Taux d'erreur 404 | > 5 % | Identifier les URLs mortes, corriger les redirections |
| Taux d'erreur 500 | > 1 % | Contacter l'hébergeur, vérifier les logs d'erreur applicative |
| Temps de réponse moyen aux requêtes Googlebot | > 1000 ms | Optimiser les pages lentes, vérifier le cache |
| Nombre d'URLs crawlées une seule fois | > 20 % du total | Vérifier les sitemaps, les liens internes |
Ces seuils ne sont pas universels. Un site e-commerce avec 100 000 pages peut avoir une moyenne de 2000 requêtes/heure. Un blog avec 400 articles, plutôt 50. L'important, c'est de connaître votre baseline.
Pour la définir, je prends les 30 derniers jours. Je calcule la moyenne et l'écart-type. Une valeur au-dessus de la moyenne plus 3 fois l'écart-type, c'est une anomalie. Automatique.
Corrélation logs + Search Console : pourquoi c'est indispensable
C'est l'étape que la plupart des gens sautent. Et c'est une erreur.
Imaginez : vous voyez dans vos logs que Googlebot crawl 30 % moins de pages qu'il y a une semaine. Alerte ? Pas forcément. Peut-être que vous avez simplement enlevé du contenu. Mais si Search Console vous montre que le nombre de pages indexées a chuté de 50 %, là, il y a un vrai problème.
La corrélation, c'est ça : croiser les logs avec une source externe pour donner du contexte à l'anomalie.
Je le fais avec un script qui extrait les données de Search Console via l'API, et les compare aux métriques des logs. Quand les deux divergent de manière significative, je creuse. Ça m'a déjà permis de découvrir un plugin de cache qui bloquait le crawl sur la version mobile du site.
Erreurs courantes à éviter
J'en ai commis quelques-unes. Voici les plus fréquentes.
Analyser les logs sans contexte : vous regardez un pic de requêtes à 3h du matin et vous paniquez. Mais ce pic, c'est peut-être juste la mise à jour quotidienne de votre base de données qui a généré des appels internes. Vérifiez d'abord. Oublier de filtrer les User-Agents : les logs contiennent tout le trafic, pas seulement Googlebot. Si vous ne filtrez pas, vous analysez du bruit. J'ai passé une heure à chercher une anomalie qui était en fait un crawler de Bing. Sympa. Se fier uniquement aux logs : les logs vous disent ce que le serveur a vu. Pas ce que Google a compris. Une URL renvoie un 200, mais Google l'a peut-être ignorée à cause d'un contenu dupliqué. Les logs ne vous le diront pas. Il faut toujours croiser. Ne pas automatiser les alertes : analyser des logs à la main tous les jours, c'est du gâchis de temps. Et vous finirez par ne plus le faire. Mettez en place un système d'alerte automatique. Même un petit script qui vous envoie un email le matin si le nombre de 404 a augmenté de 50 % par rapport à la veille. C'est simple, et ça marche.Conclusion
L'analyse des logs serveur pour détecter les anomalies de crawl, ce n'est pas un luxe de geek. C'est un outil de diagnostic précis pour tous ceux qui veulent comprendre ce que Googlebot fait réellement sur leur site. Les logs ne mentent pas. Ils montrent chaque seconde de l'exploration, chaque erreur, chaque ralentissement.
Mais attention : ce n'est pas une baguette magique. Les logs ne vous disent pas pourquoi une page n'est pas indexée. Ils vous disent seulement qu'elle a été crawlée. Le « pourquoi », c'est à vous de le chercher.
Alors, commencez petit. Ouvrez vos logs avec GoAccess. Regardez les 10 URLs les plus crawlées par Googlebot. Calculez le taux d'erreur 404. Si quelque chose cloche, vous saurez quoi chercher. Et avec le temps, vous développerez ce réflexe : « Tiens, le nombre de requêtes a doublé par rapport à hier midi. Pourquoi ? »
C'est là que commence la vraie connaissance du crawl. Pas dans un tableau de bord tout propre. Dans les anomalies.
