Analyse de logs SEO : le seul endroit où le crawl de Google est visible

Le fichier pèse quelques centaines de mégaoctets. Une ligne par requête reçue, des millions de lignes, aucune mise en forme.

C'est le seul document où le passage de Google sur votre site est un fait et non une hypothèse.

Tout le reste en donne une version arrangée. La Search Console résume et échantillonne.

Les outils de crawl simulent un robot, ils n'observent pas le vrai. Votre analytics ignore les bots par construction.

L'analyse de logs SEO consiste à lire ce fichier brut pour comprendre comment les moteurs de recherche crawlent un site web. Quelles URLs Googlebot visite, à quelle fréquence, avec quel code de réponse, et lesquelles il n'a jamais ouvertes.

Ce qu'une ligne de log serveur dit exactement

Chaque fois qu'un navigateur ou un robot demande une page, le serveur écrit une ligne. Apache et Nginx écrivent le même format, appelé combined.

Voici à quoi ressemble un passage de Googlebot :

66.249.66.1 - - [12/Aug/2026:09:14:22 +0200] "GET /blog/audit-technique-seo HTTP/1.1" 200 18342 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Sept informations utiles, dans un ordre fixe.

Champ	Apache	Nginx	Ce qu'on en fait
66.249.66.1	%h	$remote_addr	Vérifier que c'est un vrai Googlebot
[12/Aug/2026:09:14:22 +0200]	%t	$time_local	Fréquence et horaires de passage
"GET /blog/... HTTP/1.1"	\"%r\"	"$request"	L'URL exacte demandée
200	%>s	$status	Répartition 200 / 301 / 404 / 5xx
18342	%b	$body_bytes_sent	Poids réellement servi au robot
"-"	\"%{Referer}i\"	"$http_referer"	Peu exploitable sur un robot
"...Googlebot/2.1..."	\"%{User-agent}i\"	"$http_user_agent"	Qui crawle : Google, Bing, un bot IA

Les deux directives officielles, pour vérifier la configuration de votre serveur :

# Apache
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined

# Nginx
log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent"';

Un fichier de logs, c'est cette ligne répétée. Rien de plus.

Pourquoi la Search Console ne remplace pas vos fichiers logs

Le rapport « Statistiques sur l'exploration » de la Search Console est gratuit, déjà branché sur votre site, et il donne une première lecture honnête du crawl. Il a quatre limites que Google documente lui-même.

Il couvre 90 jours glissants. Il agrège : des totaux par code de réponse, par type de fichier, par type de Googlebot, jamais la liste de vos URLs.

En cliquant, vous obtenez des exemples d'URL que la documentation qualifie explicitement de non complets. Et le rapport n'existe que pour les propriétés situées à la racine du domaine.

Ajoutez une cinquième limite, qui n'est pas une limite mais un périmètre : la Search Console ne parle que de Google.

	Search Console	Logs serveur
Fenêtre	90 jours	Ce que garde l'hébergeur
Granularité	Agrégée, exemples partiels	Chaque requête, à la seconde
URL exacte crawlée	Échantillon	Exhaustive
Bingbot, GPTBot, ClaudeBot	Absents	Présents
Périmètre	Propriétés racine	Tout le serveur, sous-domaines compris
Requêtes bloquées par un pare-feu	Invisibles	Visibles selon l'étage du log

Les deux ne s'opposent pas. La Search Console dit qu'un problème existe, les logs disent sur quelles URLs.

Où sont vos logs, et combien de temps votre hébergeur les garde

Sur un serveur Linux classique, vos données de logs sont à un endroit prévisible : /var/log/apache2/access.log pour Apache, /var/log/nginx/access.log pour Nginx. Les jours précédents sont archivés à côté, compressés en .gz.

Sur un hébergement mutualisé, il n'y a pas d'accès SSH. Le panneau d'administration propose parfois un téléchargement des logs bruts, parfois seulement des statistiques pré-mâchées, auquel cas l'analyse est hors de portée. Autant le savoir avant de promettre un audit.

La rétention est le deuxième mur. Beaucoup d'hébergeurs purgent à trente jours.

Le cadre légal fixe l'autre borne. La CNIL recommande de conserver les journaux entre six mois et un an, dans sa recommandation de novembre 2021. Ces fichiers contiennent des adresses IP, donc des données personnelles : ils relèvent du RGPD, avec une finalité limitée à la sécurité.

Dernier piège, celui qui fausse le plus de diagnostics. Si un pare-feu applicatif ou un CDN filtre le trafic en amont, ce qu'il bloque n'atteint jamais votre serveur. Un robot autorisé dans le robots.txt peut donc être rejeté avant même d'arriver, sans laisser la moindre trace dans le log applicatif.

Vérifier que c'est bien Googlebot avant d'en tirer une conclusion

Les robots des moteurs de recherche s'annoncent dans le champ user-agent. Ce champ est du texte libre, personne ne le contrôle, n'importe qui peut donc se déclarer Googlebot.

La vérification officielle tient en deux commandes. D'abord une résolution DNS inverse sur l'adresse IP relevée dans le log :

host 66.249.66.1

Le nom obtenu doit se terminer par googlebot.com, google.com ou googleusercontent.com. Aucun autre domaine n'est valide.

Ensuite, une résolution directe sur ce nom, qui doit renvoyer l'adresse IP de départ. Les deux sens doivent concorder.

Google publie aussi ses plages d'adresses en JSON, ce qui permet de comparer une IP sans passer par le DNS.

Cette étape prend deux minutes et change parfois tout le diagnostic. Une part du crawl que vous observez n'est pas Google.

Les cinq lectures d'une analyse de logs SEO qui changent quelque chose

Une fois le fichier ouvert et les robots vérifiés, cinq questions valent le détour. Les autres sont du confort.

1. Quelles URLs Googlebot visite le plus souvent ? Classez les adresses par nombre de hits sur trente jours, puis posez la liste à côté de vos pages qui rapportent. Quand une page stratégique est visitée une fois par mois et qu'une page de filtre l'est trois fois par jour, le problème est identifié.

2. Quels codes HTTP le robot reçoit-il, et sur quelles sections ? Une 404 dans un menu ne se voit pas depuis le navigateur d'un humain. Une chaîne de trois redirections non plus.

Les logs les sortent par répertoire, ce qui désigne le gabarit fautif plutôt qu'une URL isolée.

3. Quelles pages n'ont jamais été visitées ? C'est le croisement le plus utile de l'exercice, et le seul moyen d'identifier les pages que le robot ignore. Prenez la liste des URLs de votre site, obtenue par un crawl. Retirez-en les URLs présentes dans les logs.

Ce qui reste, ce sont vos pages orphelines, publiées, indexables en théorie, jamais ouvertes par le robot. Presque toujours un problème de maillage interne ou de profondeur. C'est le premier livrable que je sors d'un audit technique SEO.

4. Combien de temps votre serveur met-il à répondre au robot ? Si votre configuration journalise le temps de réponse, comparez les performances jour par jour au volume crawlé. La corrélation est rarement subtile.

5. Googlebot smartphone ou desktop ? Depuis juillet 2024, Google explore l'intégralité du web avec son robot mobile. Voir du Googlebot desktop en majorité dans un log récent n'est pas normal, et mérite une explication.

Le budget crawl ne concerne pas tous les sites

La SERP sur ce sujet vend le budget de crawl à tout le monde. Google, lui, est nettement plus restrictif.

Sa documentation réserve le sujet à deux profils de taille. Les sites de plus d'un million de pages dont le contenu bouge une fois par semaine. Et ceux de plus de dix mille pages qui changent quotidiennement.

Google précise que ces chiffres sont une estimation approximative, pas des seuils exacts. Et ajoute que si vos pages sont explorées le jour de leur publication, la question ne se pose pas.

Un mécanisme, en revanche, concerne tout le monde.

Google appelle ça la limite de capacité d'exploration : le temps qu'il accepte de passer sur votre serveur. Elle monte quand les réponses sont rapides et stables.

Elle baisse quand la latence augmente, quand le serveur renvoie des erreurs 5xx, ou quand il répond 429, le code qui signifie « trop de requêtes ». Un serveur qui souffre est un serveur moins exploré.

Sur un site de deux cents pages, l'enjeu des logs n'est donc pas le budget. C'est de repérer les pages jamais visitées et les erreurs que rien d'autre ne remonte.

Optimiser l'exploration après le diagnostic : robots.txt, sitemap, cache HTTP

Lire les logs ne suffit pas à améliorer votre référencement naturel. Ce sont les trois chantiers qui suivent qui le font, dans cet ordre.

Couper d'abord. Les logs désignent nommément ce qui absorbe l'exploration sans rien rapporter : navigation à facettes, paramètres de tri, résultats de recherche interne, pagination profonde. Selon les cas, ça se règle dans le robots.txt, en noindex, ou en supprimant les liens qui y mènent.

Remonter ensuite. Les pages stratégiques ignorées par le robot doivent se rapprocher de la surface. Un sitemap à jour, des liens depuis des pages déjà bien explorées, moins de clics depuis l'accueil.

Alléger enfin. Google demande explicitement de réactiver le cache HTTP, via les en-têtes ETag ou Last-Modified, pour que le robot cesse de retélécharger des pages inchangées.

Dans sa série « Crawling December » de décembre 2024, l'équipe Search a chiffré la dérive. La part des requêtes servies depuis un cache est tombée de 0,026 % des récupérations dix ans plus tôt à 0,017 % fin 2024.

Une page qui répond « rien n'a changé » coûte une fraction d'une page renvoyée en entier.

GPTBot, ClaudeBot, PerplexityBot : le crawl que personne ne regarde

Les guides sur l'analyse de logs s'arrêtent aux robots de Google. En 2026, une part croissante des lignes de votre fichier appartient à des robots qui ne pèsent pas sur les résultats de recherche classiques.

Ils s'identifient tous, avec des user-agents publiés par leurs éditeurs.

Robot	Éditeur	Ce qu'il fait
GPTBot	OpenAI	Collecte pour l'entraînement des modèles
OAI-SearchBot	OpenAI	Alimente la recherche dans ChatGPT
ChatGPT-User	OpenAI	Visite déclenchée par un utilisateur
OAI-AdsBot	OpenAI	Contrôle des pages soumises comme annonces
ClaudeBot	Anthropic	Collecte pouvant servir à l'entraînement
Claude-SearchBot	Anthropic	Qualité des résultats de recherche
PerplexityBot	Perplexity	Indexation pour Perplexity

La distinction compte pour arbitrer. Bloquer un robot d'entraînement ne coûte aucune visibilité. Bloquer OAI-SearchBot ou Claude-SearchBot vous retire des résultats de recherche que ces outils construisent, OpenAI documente précisément ce partage entre ses quatre robots.

Vos logs sont le seul endroit où l'on voit comment ces robots interagissent avec votre site. La Search Console ne les montre pas, et votre outil d'analyse d'audience filtre les robots.

Analyser les logs : faut-il un outil, ou trois commandes suffisent-elles

Sur un fichier d'une journée, trois commandes répondent déjà à l'essentiel.

Compter les passages de Googlebot :

grep -c "Googlebot" access.log

Sortir les vingt URLs les plus explorées :

grep "Googlebot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Obtenir la répartition des codes de réponse :

grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Trois lignes, aucune licence, un résultat exploitable en dix minutes.

L'outil devient utile quand la volumétrie dépasse ce qu'un terminal traite confortablement. Et surtout quand il faut croiser les logs avec un crawl du site pour isoler les pages orphelines.

Screaming Frog propose un analyseur de logs gratuit jusqu'à mille lignes et un seul projet, puis à 139 $ par an. Oncrawl et Botify visent des volumétries industrielles et se facturent sur devis. C'est le terrain des sites à forte génération d'URLs, celui que je décris dans mon article sur le consultant SEO SaaS.

Le choix se fait sur le nombre de lignes à traiter, pas sur la richesse de l'interface.

Questions fréquentes

Combien de jours de logs faut-il pour une analyse fiable ?

Trente jours donnent une lecture solide sur la plupart des sites. En dessous de sept, les variations quotidiennes du crawl faussent tout classement de fréquence.

Sur un site à faible trafic, visez plutôt quarante-cinq à soixante jours : le volume de hits compte davantage que la durée.

Mon hébergeur ne me donne pas accès aux logs, que faire ?

Demandez d'abord explicitement l'export des logs bruts au support, beaucoup les fournissent sur demande sans le documenter.

Si c'est refusé, il reste deux options. Passer par un CDN qui journalise le trafic à son niveau, ou basculer sur un serveur avec accès SSH. Sur un mutualisé fermé, l'analyse de logs n'est simplement pas possible.

Les logs serveur sont-ils soumis au RGPD ?

Oui. Une adresse IP est une donnée personnelle, et un fichier de logs en contient une par ligne.

La CNIL recommande une conservation de six mois à un an, avec une finalité limitée à la sécurité. En pratique, une analyse SEO se fait sur des fenêtres bien plus courtes, donc la contrainte est rarement bloquante.

L'analyse de logs sert-elle sur un site de moins de mille pages ?

Oui, mais pas pour la même raison. Le budget de crawl n'est pas votre problème à cette échelle.

Ce que vous y trouverez, ce sont les pages jamais visitées, les erreurs invisibles depuis un navigateur, et le volume réel des robots IA. Trois choses qu'aucun autre outil ne montre.

Analyser vos logs sur votre site

Un fichier de logs ne se discute pas. Il ne donne pas d'avis sur votre maillage, il montre les URLs que Google a ouvertes et celles qu'il a laissées de côté.

J'ai passé huit ans à écrire du Angular et du Java avant de faire du SEO. Ouvrir un terminal et récupérer un access.log fait partie des gestes que je pratiquais déjà. Je m'en sers aujourd'hui pour comprendre ce que Google fait vraiment de vos pages.

Sur un site technique, une stratégie SEO se décide autant dans les logs que dans les mots-clés.

Un seul interlocuteur, pas d'agence. Je regarde vos logs et votre crawl avant qu'on se parle, et je vous cite des URLs précises dès le premier échange. Premier mois remboursé si vous n'êtes pas convaincu.

Réserver un appel de 30 minutes, ou voir le détail de l'accompagnement.