Le journal d’accès de votre serveur note chaque requête reçue, y compris celles de Googlebot, le robot de Google.
Quand une page reste absente de Google, la cause reste floue tant que vous ne lisez pas ces lignes. Dans cet article, nous allons voir comment lire vos logs pour repérer ce qui empêche Google d’explorer et d’indexer votre site.
Qu’est-ce qu’un log serveur ?
Journaux d’accès
Un log serveur est un journal dans lequel le serveur note ce qui s’y passe. Le journal d’accès garde une trace de chaque requête reçue, y compris celles de Googlebot, le robot de Google.
Le journal d’erreurs, lui, note les incidents techniques. Pour votre diagnostic, c’est le journal d’accès qui vous intéresse.
Avant de compter, vérifiez qui enregistre réellement le trafic. Un CDN, ce réseau de serveurs relais, répond souvent depuis son cache sans solliciter votre serveur : ces requêtes n’entrent pas dans vos logs d’origine.
Pour elles, prenez les journaux du CDN. Pour le serveur d’origine, assurez-vous que le journal couvre toutes les machines qui reçoivent le trafic.
Journaux d’erreurs
Le journal d’erreurs garde la trace des incidents : pannes, délais dépassés, fichiers introuvables. Quand le serveur tombe souvent, Googlebot charge moins de pages.
Consultez-le quand une page reste absente de Google ou quand l’exploration chute. Comparez l’heure des erreurs avec celle des baisses : si elles coïncident, la panne vient du serveur.
Un passage de Googlebot dans le journal prouve seulement que la requête a atteint le serveur. Il ne prouve ni qu’une page est indexée, ni pourquoi elle ne l’est pas. Sinon, vous corrigez une cause imaginaire. Pour confronter vos hypothèses aux passages réels, voyez la méthodologie d’audit SEO pour des résultats concrets.
Comment ça marche vraiment : ce qu’une ligne de log enregistre
Une ligne de log Nginx garde l’IP, la date, l’URL, le code de réponse et le user-agent. Avec $request_time, elle ajoute la durée de traitement, en secondes, à la milliseconde près.
Cette durée montre les pages lentes que Googlebot attend. Si une URL reste plus lente que les autres, regardez d’abord le serveur ou l’application. Pour un audit complet, voyez l’audit SEO d’une fusion acquisition.
Plutôt que de lire les lignes une à une, comptez la part de chaque code HTTP et regroupez les URL par famille de gabarit :
- Calculez la part de chaque statut (200, 301, 404, 5xx, 429) dans les requêtes de Googlebot, pour voir ce qui pèse le plus.
- Un 429 signifie que le client a envoyé trop de requêtes sur une période donnée : le serveur limite alors le débit.
- Des 5xx, des 429 ou une hausse du temps de réponse font baisser la capacité d’exploration de Google, qui explore alors moins le site.
Ce qui compte vraiment, par ordre d’importance
Avant de compter les requêtes, vérifiez qu’elles viennent bien de Google. N’importe quel robot peut reprendre le nom Googlebot, donc l’agent utilisateur seul ne suffit pas.
Faites une recherche DNS inverse sur l’adresse IP : ce nom doit finir par googlebot.com, google.com ou googleusercontent.com.
Refaites une recherche DNS directe sur ce nom : elle doit renvoyer la même IP. Sinon, ce sont des usurpations qui faussent vos volumes.
Classez vos constats dans cet ordre :
- Disponibilité : comptez les requêtes en 5xx et en 429. Une hausse réduit la capacité d’exploration, et il n’existe pas de seuil universel au-delà duquel la baisse commence.
- Gaspillage : mesurez la part des requêtes de Googlebot qui vont vers des URL utiles. Si beaucoup de requêtes tombent sur des pages sans valeur, les pages importantes reçoivent moins de visites.
- Couverture : comparez les requêtes de Googlebot au sitemap, aux pages importantes et à un crawl du site. Une page utile que Google visite peu se vérifie en premier.
Par où commencer : préparer et nettoyer les données
Rassemblez les logs de toutes les machines qui reçoivent les requêtes : serveurs d’origine, mandataires inverses et CDN. Vérifiez que tous les fichiers couvrent la même période et qu’aucune machine ne manque.
Chaque ligne doit contenir l’URL demandée, l’heure, le code HTTP et l’agent utilisateur. Notez le fuseau horaire des dates : deux machines sur des fuseaux différents donnent une chronologie fausse. Pour les sites complexes, voyez la checklist d’audit SEO technique.
Pour préparer les données, procédez ainsi :
- Séparez le chemin des paramètres, dans deux colonnes. Dans
/chaussures?couleur=noir&page=2, le chemin est/chaussures. - Vérifiez les paramètres avant de les supprimer ou de les regrouper : deux URLs de même chemin peuvent afficher des contenus différents.
- Regroupez les URLs par familles : produits, catégories, articles, pagination, filtres, recherche interne.
- Écartez les requêtes des outils de surveillance et des tests internes.
- Mettez de côté les requêtes qui se disent Googlebot, et vérifiez leur adresse IP avant de les compter.
Comment savoir quelles pages Google n’explore pas
Comparez les URLs du sitemap, celles du crawl et celles demandées par Googlebot dans les logs. Une page du crawl absente des logs n’a pas été demandée pendant la période étudiée.
Une URL présente dans les logs mais absente du crawl relève d’une page orpheline, d’une ancienne adresse ou d’un chemin hors maillage interne. Cet écart n’est pas une cause : c’est un indice à vérifier.
Pour garder un historique complet de vos données Search Console, voyez l’export vers BigQuery : il vous permet de comparer l’exploration et l’indexation sur la même période.
| Critère | Exploration (Googlebot) | Indexation |
|---|---|---|
| Source | Logs serveur et rapport « Statistiques sur l’exploration » | Rapport « Indexation des pages » |
| Ce qu’elle montre | Les URLs demandées, les réponses du serveur, les problèmes de disponibilité | Les pages connues de Google et la raison de leur absence de l’index |
| Question posée | Cette URL a-t-elle été demandée pendant la période ? | Cette URL est-elle dans l’index ? |
| Outil à croiser | Crawl interne comparé aux URLs des logs | Inspection d’URL dans Search Console |
Les freins que trahissent les codes de réponse
Un code 429 signale une limitation du débit : le serveur refuse des requêtes parce qu’il en reçoit trop. Des 429 ou des 5xx, c’est-à-dire des erreurs serveur, font baisser la capacité d’exploration de Google.
Si les temps de réponse augmentent, vérifiez en même temps la disponibilité du serveur, les 5xx, les 429 et le nombre de requêtes Googlebot. Une hausse de latence réduit aussi cette capacité.
Pour trier ces codes, voyez les logs des grands comptes :
- Page définitivement supprimée : renvoyez un statut
404ou410. - Soft 404 : une page qui semble vide ou absente, mais qui renvoie
200, peut continuer à être explorée. - Redirections : évitez les longues chaînes, elles réduisent l’efficacité de l’exploration.
- Noindex : ne l’utilisez pas pour éviter l’exploration, Google doit demander la page pour lire cette consigne.
- robots.txt : bloquez-y l’exploration des pages que Google ne doit pas explorer.
Le budget de crawl gaspillé sur des URL inutiles
Le budget de crawl, c’est le nombre d’URL que Google peut et souhaite explorer sur votre site. Il dépend de la capacité de votre serveur et de l’intérêt de Google.
Pour la plupart des sites, ce n’est pas un enjeu. Il le devient à partir de 10 000 pages uniques qui changent chaque jour, ou de 1 million de pages qui changent chaque semaine.
Si beaucoup d’URL sont « Détectée, actuellement non indexée », surveillez-les.
Divisez les requêtes Googlebot sur vos pages utiles par le total des requêtes Googlebot, puis multipliez par 100. Comparez ensuite les 2xx, 3xx, 4xx et 5xx de chaque famille de pages aux URL du sitemap et du crawl interne. Pour trier les URL à écarter, voyez optimiser votre budget de crawl.
Le journal d’accès est votre meilleure source contre les freins à l’indexation. Une visite de Googlebot prouve seulement que la requête est arrivée au serveur, pas que la page est indexée.
Votre prochain pas : vérifiez les IP Googlebot, puis comptez les 5xx et les 429. Si elles coïncident avec une baisse d’exploration, c’est le serveur qu’il faut corriger.