Analyse des logs de votre site : décrypter les robots, les erreurs et le trafic réel dans Nginx/Apache
1. Pourquoi il ne faut pas se fier au « total des visites »
Beaucoup de webmasters ouvrent leurs logs et se demandent d’abord « combien de requêtes aujourd’hui », avant d’en déduire si les affaires marchent. C’est le premier piège : dans l’access.log par défaut de Nginx, une ligne correspond à une requête HTTP. Un humain qui ouvre votre page d’accueil peut générer 8 à 15 requêtes (HTML, CSS, JS et images comptés séparément), tandis qu’un robot malveillant en envoie des milliers en une minute. Le total ne sert quasiment à rien pour décider.
La conclusion est contre-intuitive :Si votre trafic « explose », il y a huit chances sur dix qu’un robot se soit mis à crawler votre site, pas qu’un client soit arrivé. Le critère est simple : dédupliquez les logs par User-Agent et regardez qui sont les 20 premières sources de requêtes. Si plus de la moitié viennent d’UA de type bot, cette explosion n’a rien à voir avec votre activité. C’est la même logique que Analyse des logs de crawlers IA: d’abord distinguer « qui vous lit », ensuite parler de « combien de lectures ».
| Champ du log (Nginx combined) | Signification | Utilité pour l’analyse |
|---|---|---|
| $remote_addr | IP source | Identifier les IP de datacenters, les scans malveillants, l’origine des robots |
| $request | Méthode + chemin + protocole | Voir quelles URL et quels fichiers sont réellement sollicités |
| $status | Code de statut HTTP | 200 normal, 301 redirection, 404 lien mort, 5xx panne |
| $body_bytes_sent | Octets renvoyés | Repérer les réponses vides et les téléchargements anormaux bloqués |
| $http_referer | Page de provenance | Par quel lien un humain est arrivé |
| $http_user_agent | Identifiant du client | Distinguer navigateurs, robots de moteurs de recherche et robots d’IA |
2. Comment lire : robots, erreurs et trafic humain, trois types de signaux
L’ordre d’analyse recommandé est fixe : « erreurs → robots → humains », jamais l’inverse. Les erreurs pèsent directement sur l’expérience des humains, donc elles passent en premier ; le volume de robots détermine votre budget de crawl et le coût de bande passante ; le trafic humain est la dernière partie qui mérite un examen détaillé. C’est aussi la raison pour laquelle Surveillance et alertes du site place la disponibilité et le taux d’erreurs au premier rang.
Pour repérer les robots, ne vous fiez pas au User-Agent : un crawler malveillant peut usurper celui de Googlebot. La méthode standard est la double vérification : sur l’IP qui se déclare Googlebot, faites une résolution DNS inverse pour confirmer qu’elle vient bien du domaine googlebot.com, puis une résolution directe pour comparer. Un faux crawler ne passe pas cette étape.
| Type de signal | Fourchette saine | Seuil d’intervention | Action |
|---|---|---|---|
| Taux d’erreurs 5xx | Moins de 0,5 % | Plus de 1 % pendant 10 minutes d’affilée | Vérifiez PHP-FPM et les logs backend, tout de suite |
| Part de 404 | Moins de 3 % | Plus de 100 404 par jour sur une même URL | Ajoutez une 301 ou corrigez le maillage interne |
| Part de requêtes de crawlers suspects | 20 % à 40 % | Plus de 60 % et bande passante saturée | Restriction via robots ou WAF |
| Nombre de sessions humaines | Stable d’une semaine sur l’autre | Baisse de plus de 20 % deux semaines de suite | Vérifiez l’indexation et vos campagnes, pas le serveur |
| Part de lectures par des crawlers IA | 5 % à 15 % est normal | Pic de plus de 3 fois | Voyez s’il y a aspiration massive pour l’entraînement |
3. En pratique : d’une commande à un rapport hebdomadaire
En solo, pas besoin d’une plateforme d’analyse de logs coûteuse. La chaîne minimale tient en trois outils : GoAccess pour un rapport visuel hebdomadaire, awk pour les stats horaires, et un audit manuel complet une fois par mois. Voici deux cas directement utilisables.
Cas 1 : trouver les URL qui ont généré le plus d’erreurs aujourd’hui. Dans le dossier des logs Nginx, lancez : awk ‘$9 ~ /^5/ {print $7}’ access.log | sort | uniq -c | sort -rn | head -20. La commande extrait le chemin de toutes les requêtes 5xx, les classe par nombre d’occurrences : le top 20 correspond aux pages à corriger en priorité aujourd’hui.
Cas 2 : voir combien de fois Google et les crawlers IA sont passés aujourd’hui. awk ‘BEGIN{IGNORECASE=1} /Googlebot|GPTBot|ClaudeBot|bingbot/ {print $http_user_agent}’ access.log | sort | uniq -c | sort -rn. En répartissant les résultats par UA, vous voyez la proportion entre le crawler d’indexation de Google et les crawlers de lecture des différentes IA. Sur un site derrière un CDN, tirez les logs d’origine et non les logs en périphérie : voir Accélération mondiale par CDN sur la différence entre origine et cache.
Cas 3 : produire un rapport hebdomadaire pour vous-même. Une fois GoAccess lancé, générez un rapport HTML chaque semaine et regardez quatre groupes de chiffres : la répartition des codes de statut avec la part de 4xx et de 5xx, les dix URL les plus demandées, la courbe de trafic par heure, et la part de crawlers par UA. Consultez ce rapport chaque lundi matin : c’est bien plus efficace que de fouiller les logs au coup par coup. Une habitude à prendre : noter chaque anomalie repérée dans un petit tableau. Trois mois plus tard, les régularités sautent aux yeux.
| Fréquence | Action | Livrable | Durée |
|---|---|---|---|
| Quotidienne | Coup d’œil au tableau de bord des erreurs 5xx | Y a-t-il une panne ou non | 2 minutes |
| Chaque semaine | Rapport GoAccess de la semaine passée | Top chemins, top crawlers, répartition des codes de statut | 10 minutes |
| Mensuel | Audit complet des 404 et des UA anormaux | Liste des liens morts, liste des IP à bloquer | 1 heure |
| Trimestriel | Calibrer la rétention et la rotation des logs | Vérifier que le disque ne sature pas et que l’historique reste consultable | 30 minutes |
4. Pièges : les trois erreurs de lecture les plus fréquentes
Le premier piège consiste à considérer tout code 200 comme normal. Certains plugins attaqués par des scanners malveillants renvoient un 200 accompagné d’une page déguisée : le code est normal mais le contenu a été remplacé. Il faut croiser avec un « nombre d’octets renvoyés anormalement faible » ou une « URL contenant des paramètres qui ne devraient pas y être », et en cas de gravité, appliquer Après un piratage de site la procédure.
Le deuxième piège consiste à ne regarder que le temps réel sans conserver d’historique. Si les logs ne sont pas gérés selon une politique de rotation et de rétention, le disque explose, ou trois mois plus tard, quand on veut savoir « quand la panne de mars a réellement commencé », on ne retrouve rien. Je recommande une rotation quotidienne, 90 jours de données chaudes conservées, puis compression et archivage au-delà.
Le troisième piège consiste à prendre les visites de robots pour un résultat SEO. Que Googlebot vienne dix mille fois ne signifie pas que votre positionnement est bon, cela veut juste dire qu’il explore en boucle. Ce qui compte vraiment pour le SEO, c’est « les pages importantes sont-elles explorées normalement », et cela se lit en croisant avec les données d’indexation, pas en se félicitant du volume de robots. Pour le lien entre performance et exploration, voir Core Web Vitals l’impact sur le taux d’exploration par les robots.
| Contresens | Symptôme visible | Cause réelle | La bonne méthode de vérification |
|---|---|---|---|
| Un pic de trafic est une bonne chose | Le nombre de requêtes triple | Un robot se met à explorer massivement | Dédupliquer par UA pour voir la part de vrais humains |
| Tout est en 200, donc tout va bien | Tous les codes sont normaux | Page déguisée renvoyée après une injection | Vérifier par échantillon les réponses anormalement petites et les paramètres suspects |
| Beaucoup d’explorations Google = bon positionnement | Les requêtes Googlebot sont élevées | Il explore en boucle des pages de faible qualité | Comparer le volume indexé et le positionnement réel |
| Les 404 peuvent être ignorés | La part semble faible | Les vieux liens entrants perdent du poids en continu | Rediriger en 301 les 404 les plus fréquents vers la nouvelle page correspondante |
FAQ — Questions fréquentes
Quelle différence entre les formats de logs Nginx et Apache, et la méthode d’analyse est-elle la même ?
Comment distinguer le vrai Googlebot d’un robot falsifié ?
Combien de temps faut-il conserver les logs pour que ce soit suffisant ?
Faut-il vraiment traiter toutes les erreurs 404 ?
Avec un CDN, les logs serveur restent-ils fiables ?
Voir GPTBot et ClaudeBot crawler dans les logs, est-ce une bonne ou une mauvaise chose ?
Pour conclure
La valeur de l’analyse de logs ne réside pas dans la « consultation du trafic », mais dans le « diagnostic et l’identification ». Pour un site indépendant géré par une seule personne, dix minutes par semaine pour générer un rapport et une heure par mois pour un audit complet suffisent à couvrir 90 % des problèmes courants : où sont les erreurs, où sont les liens morts, quels robots grignotent votre bande passante, et d’où viennent réellement les visiteurs humains.
Trois étapes concrètes : premièrement, uniformisez le format des logs en combined et conservez-les 90 jours avec découpage quotidien ; deuxièmement, alertez dès que le taux d’erreurs 5xx dépasse 1 %, puis traitez les 404 les plus fréquentes ; troisièmement, comptez séparément les robots et les humains, et cessez de vous mentir avec le nombre total de visites. Pour le rythme de maintenance du site, reportez-vous à calendrier de maintenance du site pour organiser le tout avec la liste des six tâches mensuelles.
Une phrase à retenir : les logs serveur ne sont pas un tableau de bord du trafic, mais l’enregistrement d’une scène d’accident — cherchez d’abord où la voiture a frappé, puis comptez combien de voitures ont circulé.