Comment analyser les logs serveur pour le SEO et booster vos positions

Un client m'appelle un jour, paniqué : Search Console lui signalait une chute de 40 % des impressions sur ses pages produits. Trois semaines de brainstorming plus tard, on n'avait rien trouvé côté contenu. C'est en ouvrant les logs Nginx de son serveur qu'on a compris. Googlebot passait 60 % de son temps de crawl sur des URL de filtres générés automatiquement, avec des paramètres à rallonge qui ne menaient nulle part. Les vraies pages catégories, elles, étaient crawlées une fois par mois. Voilà ce que Search Console ne vous dira jamais : la façon exacte dont Googlebot se comporte sur votre site. Pour ça, il faut lire les logs serveur.

Où se trouvent les logs et comment y accéder sans se prendre la tête

Avant de parler d'analyse, il faut mettre la main sur les fichiers. Et là, première surprise pour beaucoup : sur un hébergement mutualisé, les logs d'accès ne sont pas toujours visibles par défaut. Sur cPanel, ils se trouvent généralement dans Metrics > Raw Access Logs ou dans le dossier ~/logs de votre compte. Sur un VPS ou un serveur dédié, c'est plus direct :

• Nginx : /var/log/nginx/access.log (et ses versions compressées access.log.1.gz)
• Apache : /var/log/apache2/access.log ou /var/log/httpd/access_log selon la distribution
• Les logs tournent : vous trouverez souvent plusieurs fichiers avec des suffixes numérotés correspondant aux semaines précédentes

Un point que personne ne mentionne assez : la conservation. Par défaut, beaucoup de serveurs ne gardent que 7 à 14 jours de logs. Si vous voulez analyser un trimestre de crawl, il faut soit allonger la rétention, soit archiver vous-même les fichiers. Je me suis fait avoir une fois en voulant comparer janvier et mars : les logs de janvier avaient déjà été écrasés. Depuis, j'automatise une copie hebdomadaire vers un bucket S3. Ça coûte trois euros par mois et ça m'a sauvé la mise plus d'une fois.

SSH ou interface graphique ?

Pour lire quelques lignes, un simple tail -n 100 access.log en SSH suffit. Pour tout ce qui dépasse quelques milliers de lignes, mieux vaut rapatrier les fichiers en local et travailler avec un outil adapté. Les logs bruts sur un site de taille moyenne, c'est vite 500 Mo par mois. Excel n'aime pas du tout.

Comprendre le format d'une ligne de log avant de vouloir l'analyser

Voici une ligne typique de Nginx en format combiné :

66.249.66.1 - - [12/Mar/2026:14:32:07 +0100] "GET /produits/chaussures-running HTTP/1.1" 200 45231 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Décortiquons, parce que chaque champ compte :

1. L'adresse IP (ici dans la plage Googlebot)
2. Le timestamp au format jour/mois/année:heure:minute:seconde fuseau
3. La méthode HTTP et l'URL demandée
4. Le code de statut (200, 404, 301, 500…)
5. Le nombre d'octets transférés
6. Le referer (souvent vide pour les bots)
7. Le user-agent, qui contient l'identité déclarée du visiteur

Ce dernier champ est celui sur lequel tout le monde se focalise. À tort, en partie. Un user-agent, ça se falsifie en une ligne de code. Des scrapers se font passer pour Googlebot tous les jours. Si vous filtrez uniquement sur la chaîne de caractères "Googlebot", vous analysez peut-être le crawl d'un concurrent ou d'un aspirateur de site.

Comment vérifier qu'un Googlebot est authentique ?

La méthode officielle tient en deux temps. D'abord, un reverse DNS sur l'IP : elle doit résoudre vers un domaine en googlebot.com ou google.com. Ensuite, un forward DNS sur ce domaine doit renvoyer la même IP. Si les deux ne correspondent pas, c'est un faux.

En ligne de commande, ça donne quelque chose comme host 66.249.66.1, puis host crawl-66-249-66-1.googlebot.com pour confirmer. Sur 200 000 lignes, c'est évidemment impossible à faire à la main : il faut passer par un script ou un outil qui gère cette double vérification. C'est le premier filtre sérieux à mettre en place, et honnêtement, la moitié des analyses que je vois circuler l'oublient.

Filtrer les robots avec grep, la partie que tout le monde sous-estime

Une fois les logs en local, on attaque le filtrage. Quelques commandes de base qui font 80 % du travail :

• grep "Googlebot" access.log | wc -l : nombre total de visites de Googlebot
• grep "Googlebot" access.log | grep " 404 " | wc -l : combien de ces visites tombent sur des 404
• awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -50 : les 50 URL les plus demandées, tous visiteurs confondus
• grep "Googlebot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -50 : la même chose, mais pour le seul robot de Google

Ce dernier résultat est souvent un électrochoc. Sur un site e-commerce que j'ai audité l'an dernier, les 50 URL les plus crawlées par Googlebot comprenaient 31 pages de filtres à paramètres. Les 19 restantes étaient des fiches produits. Les catégories principales n'apparaissaient même pas dans le top 100. Le budget de crawl était littéralement aspiré par des combinaisons de filtres qui n'avaient aucune valeur SEO.

Combien de budget de crawl gaspillez-vous ?

Pour le mesurer, il faut croiser deux données : le nombre total de requêtes Googlebot sur la période, et le nombre de requêtes qui pointent vers des URL que vous jugez utiles. Le ratio entre les deux, c'est votre taux de gaspillage.

Sur des sites mal structurés, je vois régulièrement des taux entre 40 et 70 %. Sur des sites propres, on descend sous les 15 %. Un écart de cet ordre justifie à lui seul de plonger dans les logs, parce qu'aucun outil tiers ne vous donnera cette information avec une précision comparable.

Situation	Taux de gaspillage typique	Action prioritaire
Site e-commerce avec filtres ouverts	50 à 70 %	Bloquer les paramètres superflus dans robots.txt ou via balise noindex
Blog avec pagination infinie	30 à 45 %	Limiter la pagination et soigner les liens internes
Site vitrine bien maillé	10 à 20 %	Surveillance périodique, peu de corrections urgentes
Site avec redirections en cascade	Variable, souvent sous-estimé	Nettoyer les chaînes de 301 et corriger les liens internes cassés

Détecter les erreurs et les pages orphelines que personne ne voit

Les logs révèlent deux catégories de problèmes que Search Console affiche en retard, mal ou pas du tout.

Erreurs 404 et 500 crawlées en boucle

Filtrer les codes 4xx et 5xx sur les requêtes Googlebot, c'est souvent l'occasion de découvrir des liens internes cassés oubliés depuis des années. Une URL qui renvoie une 404 et que Googlebot visite encore signifie qu'un lien quelque part pointe vers elle. Tant que ce lien existe, Googlebot reviendra. Et chaque passage, c'est du budget de crawl consommé pour rien.

Le cas des 500 est plus vicieux. Si une page stratégique renvoie des erreurs serveur intermittentes, la fréquence de crawl peut chuter durablement sans qu'aucun rapport ne le signale clairement. J'ai vu un site dont la page de catégorie principale tombait en 503 une fois sur cinq à cause d'une limite de connexion mal configurée. Il a fallu lire les logs pour le voir, parce que les tests manuels tombaient toujours dans le bon créneau.

Pages orphelines : crawlées mais introuvables au clic

Inversement, une URL qui apparaît dans les logs Googlebot mais qui n'est liée depuis nulle part sur votre site est un cas intéressant. Soit elle est dans votre sitemap, soit elle est issue d'un ancien maillage oublié, soit elle est carrément le fruit d'une injection externe. Ces pages méritent un examen au cas par cas : dans le doute, mieux vaut les supprimer ou les rediriger que les laisser polluer votre index.

Les bots IA dans vos logs : le nouveau paramètre à surveiller

Il y a deux ans, je filtrais sur Google, Bing et quelques robots secondaires. Aujourd'hui, mes analyses intègrent systématiquement une liste qui s'allonge chaque trimestre : GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Google-Extended… Ces robots ne se comportent pas comme Googlebot. Ils crawlaient beaucoup, n'indexent pas de la même façon, et leur passage n'a pas de traduction directe dans Search Console.

Ce qui m'intéresse concrètement dans ces données :

• Quelles pages attirent en priorité les moteurs de réponse IA
• Si ces robots accèdent à vos pages, ou s'ils se font bloquer par un pare-feu mal configuré
• Le volume de requêtes par robot : certains sont extrêmement agressifs
• Le ratio de succès (200 contre 403/404) par robot

Sur un site de contenu que je suis depuis quelques mois, GPTBot représente désormais environ 10 % du trafic de robots total, contre 2 % à ses débuts. Ce n'est pas une tendance à ignorer, surtout si votre stratégie d'acquisition commence à regarder du côté des moteurs de réponse.

Passer de l'analyse à l'action : un plan qui tient en trois priorités

Analyser les logs, c'est bien. En tirer un plan chiffré, c'est mieux. Voici la façon dont je procède aujourd'hui, après pas mal de tâtonnements.

1. Bloquer ou désindexer les URL gaspillées. C'est le gain le plus rapide. Sur un site, supprimer 200 URL de filtres du crawl de Googlebot a fait grimper les visites de pages stratégiques de 35 % en six semaines, sans rien changer au contenu.
2. Corriger les chaînes de redirections et les erreurs serveur. Moins spectaculaire, mais ça stabilise la fréquence de crawl sur les pages importantes.
3. Réviser le maillage interne. Une page stratégique peu crawlée est souvent une page peu liée. Les logs vous disent lesquelles. C'est à vous de faire le reste.

Un mot d'avertissement : ne lisez pas les logs tous les jours sans raison. Une fois par mois suffit largement, sauf incident. J'ai passé une période à faire des rapports hebdomadaires, et je finissais par surinterpréter des variations normales. Le bruit statistique existe aussi ici.

Combien de temps avant de voir un effet ?

Comptez deux à huit semaines après une modification structurelle, selon la taille du site et sa fréquence de crawl habituelle. Sur un petit site, les changements sont visibles en deux semaines. Sur un gros catalogue avec des millions d'URL, il faut de la patience. Le pire réflexe, c'est de tout modifier en même temps : vous ne saurez jamais ce qui a fonctionné.

Ce que les logs ne vous diront pas

Il y a une tentation naturelle, quand on commence à lire ses fichiers d'accès, de croire qu'on tient enfin la vérité brute du SEO. Ce n'est pas tout à fait ça. Les logs disent ce que Googlebot a demandé, pas ce qu'il a retenu, ni comment il a classé ce qu'il a retenu. Deux sites avec exactement le même profil de crawl peuvent avoir des positions très différentes, parce que d'autres facteurs entrent en jeu.

Et puis il y a une question qui me travaille depuis quelque temps. Avec la montée des moteurs de réponse, le comportement des crawlers change, les règles du jeu se déplacent. Les logs restent l'un des rares endroits où on peut observer ce déplacement en direct, sans intermédiaire. C'est peut-être pour ça que je continue à les ouvrir chaque mois, même quand tout va bien. Pas pour trouver un problème. Pour voir ce qui arrive.