Les logs serveur WordPress montrent quelque chose que l’interface du CMS ne montre pas directement : les requêtes réellement reçues par le serveur. Lorsqu’un robot de Google demande une URL, le journal d’accès peut enregistrer la date, la ressource demandée, le code HTTP retourné et le user-agent déclaré. Cette donnée permet d’étudier le comportement de crawl beaucoup plus précisément qu’en regardant uniquement le sitemap ou une liste de pages indexées.
Une analyse de logs permet de savoir quelles URLs sont demandées par Googlebot, à quelle fréquence et avec quel code HTTP. Elle peut révéler un crawl concentré sur des redirections, erreurs, filtres WooCommerce ou anciennes URLs alors que des pages importantes sont rarement demandées. En revanche, un passage de Googlebot ne prouve ni l’indexation ni le classement d’une page : les logs décrivent les requêtes reçues par le serveur, pas la décision finale de Google Search.
1. Un log serveur ne montre pas la même chose qu’un outil SEO
Lorsqu’une page WordPress est demandée, le serveur web peut conserver une trace de cette requête dans ses journaux d’accès. Le format dépend de l’hébergement, du serveur, du proxy ou du CDN utilisé, mais les informations disponibles peuvent notamment inclure l’URL demandée, la date, le code HTTP, le user-agent et différentes informations techniques.
Cette source est intéressante parce qu’elle ne cherche pas à simuler le comportement d’un robot : elle enregistre ce que le serveur a réellement reçu.
| Information | Question SEO associée |
|---|---|
| URL demandée | Quelles ressources le robot vient-il réellement explorer ? |
| Code HTTP | Reçoit-il une page normale, une redirection, une erreur client ou une erreur serveur ? |
| Horodatage | Quand l’URL a-t-elle été demandée et comment le crawl évolue-t-il ? |
| User-agent | Quel robot ou navigateur déclare effectuer la requête ? |
| Temps ou volume technique selon le journal | Certaines ressources provoquent-elles des réponses particulièrement lourdes ou lentes ? |
Attention à ne pas confondre access log et debug.log
Le fichier de débogage de WordPress sert à enregistrer des erreurs ou informations liées à l’exécution de PHP et du CMS. Il ne constitue pas un historique complet des requêtes reçues par le serveur.
Pour analyser Googlebot, ce sont principalement les journaux d’accès du serveur, du proxy ou du CDN qui intéressent le SEO.
Tous les hébergements ne donnent pas le même accès
Certains hébergeurs permettent de télécharger facilement les logs bruts. D’autres proposent une interface, une durée de conservation limitée ou nécessitent de passer par un service intermédiaire.
Avant toute analyse, identifiez la source du journal. Si un CDN ou un reverse proxy se trouve devant WordPress, les fichiers du serveur d’origine ne représentent pas nécessairement à eux seuls toutes les requêtes reçues par le site.
2. Filtrer Googlebot sans faire confiance uniquement au user-agent
Une première analyse consiste souvent à filtrer les lignes dont le user-agent contient Googlebot. Cela permet d’isoler rapidement une partie des requêtes.
Mais un user-agent peut être imité. N’importe quel robot peut envoyer une chaîne de caractères déclarant « Googlebot ».
Pour une analyse rigoureuse, vérifiez l’origine du robot
Google documente plusieurs méthodes permettant de vérifier qu’une requête provient réellement de ses robots, notamment à partir de ses plages d’adresses IP publiées ou par vérification DNS.
Cette étape devient particulièrement importante lorsque l’objectif est de mesurer précisément le crawl de Google plutôt que de simplement repérer des robots déclarant son nom.
Rapide à filtrer, mais la valeur peut être usurpée par un autre robot.
Permet de travailler avec un échantillon plus fiable des requêtes réellement attribuables aux robots de Google.
Ne mélangez pas tous les robots dans une même analyse
Un site peut recevoir des moteurs de recherche, outils SEO, robots d’IA, systèmes de monitoring et crawlers malveillants. Leur comportement n’a pas la même signification.
Si l’objectif est d’étudier l’exploration de Google Search, commencez par isoler les requêtes pertinentes avant de calculer vos répartitions d’URLs et de codes HTTP.
Un volume élevé de lignes contenant « Googlebot » n’est pas suffisant pour conclure. Vérifiez d’abord la provenance des requêtes et assurez-vous que votre fichier contient bien la période et le trafic que vous pensez analyser.
3. Ce que les logs peuvent révéler sur la qualité du crawl
Une fois les requêtes pertinentes isolées, le but n’est pas simplement de compter les visites du robot. Il faut regarder où part le crawl et ce que le serveur renvoie.
Beaucoup de réponses 200
Un code 200 indique que le serveur a répondu normalement à la requête. Il faut ensuite regarder quelles pages représentent ces réponses : contenus stratégiques, pages secondaires, filtres, fichiers ou URLs qui n’ont plus beaucoup d’intérêt.
Beaucoup de redirections
Si Googlebot continue à demander massivement d’anciennes URLs qui renvoient vers de nouvelles destinations, les logs permettent de le constater directement.
Une redirection permanente correctement utilisée est normale lors d’une migration. En revanche, de nombreuses chaînes ou des liens internes pointant encore vers d’anciennes adresses peuvent mériter une correction.
Des erreurs 404 ou 410
Leur présence n’est pas automatiquement alarmante. Une ancienne URL supprimée sans équivalent peut légitimement ne plus exister.
L’analyse devient intéressante lorsque Googlebot demande régulièrement une URL qui devrait encore fonctionner, ou lorsqu’une ancienne page importante n’a pas reçu la destination prévue.
Des réponses 5xx
Les erreurs serveur méritent davantage d’attention lorsqu’elles touchent régulièrement Googlebot. Elles indiquent que le serveur n’a pas pu fournir correctement la ressource au moment de la requête.
| Code | Lecture initiale | Question à poser |
|---|---|---|
| 200 | Ressource servie normalement. | Googlebot explore-t-il les bonnes URLs ? |
| 3xx | Redirection. | Est-elle nécessaire, directe et correctement ciblée ? |
| 404 / 410 | Ressource absente. | Est-ce volontaire ou une page utile a-t-elle été perdue ? |
| 5xx | Erreur serveur. | Le problème est-il ponctuel ou récurrent sur des URLs importantes ? |
Ne cherchez pas à obtenir 100 % de réponses 200. Un site réel possède souvent des redirections et anciennes URLs. Ce qui compte est de comprendre si les réponses correspondent au comportement voulu.
4. Sur WordPress, regardez quelles familles d’URLs absorbent le crawl
WordPress peut générer plusieurs types d’URLs selon le thème, les extensions, les taxonomies et les fonctionnalités activées. WooCommerce ajoute encore d’autres structures : produits, catégories, attributs, filtres et paramètres.
Une analyse de logs devient particulièrement utile lorsque vous regroupez les requêtes par modèle d’URL plutôt que d’examiner des milliers de lignes une par une.
Les paramètres et filtres méritent une attention particulière
Sur une boutique, une même catégorie peut parfois être accessible à travers différents paramètres de tri, de filtre ou de navigation. Selon la configuration, ces combinaisons peuvent créer un grand nombre d’URLs possibles.
Les logs permettent de voir si Googlebot les demande réellement et dans quelles proportions, avant de conclure qu’elles représentent un problème.
Sur un site e-commerce WordPress, cette lecture par famille d’URLs est généralement plus utile qu’un simple comptage du nombre total de requêtes.
Les anciennes URLs peuvent rester très présentes après une refonte
Après une refonte WordPress, le journal peut montrer que Google continue à demander des anciennes adresses. Ce comportement n’est pas nécessairement anormal : les anciennes URLs peuvent rester connues pendant un certain temps.
L’important est que leur réponse soit cohérente : redirection correcte lorsqu’un successeur existe, ou statut approprié lorsque le contenu a réellement disparu.
N’appliquez pas des blocages robots uniquement parce qu’une famille d’URLs reçoit beaucoup de crawl. Avant toute modification, vérifiez son rôle, son indexabilité, ses liens internes et les conséquences d’un éventuel blocage.
5. Crawl, indexation et classement : trois choses différentes
C’est la distinction essentielle d’une analyse de logs. Voir Googlebot demander une URL indique que le robot a effectué une requête. Cela ne prouve pas que la page sera indexée.
Googlebot demande une ressource au serveur.
Google traite les informations de la page et peut décider de l’intégrer à son index.
Une page indexée peut ensuite être évaluée pour différentes recherches.
Search Console permet notamment d’observer impressions et clics obtenus dans Google Search.
Une URL très crawlée peut ne pas être indexée
Une page peut être explorée puis ne pas être retenue dans l’index, ou Google peut choisir une autre URL canonique. Les logs ne permettent pas à eux seuls d’expliquer cette décision.
Une page peu crawlée n’est pas forcément en difficulté
Une page stable et déjà connue peut être visitée moins souvent qu’un contenu qui change fréquemment. Il n’existe donc pas de fréquence minimale universelle à atteindre pour chaque URL.
Comparez les logs avec Search Console
Le rapport sur les statistiques d’exploration fournit une vue agrégée de l’activité de Googlebot. L’inspection d’URL et les rapports d’indexation apportent d’autres informations sur des pages spécifiques.
Les logs répondent à une question plus brute : qu’a réellement demandé le robot à votre infrastructure ?
Le croisement est plus puissant que chaque source isolée. Une URL stratégique absente des logs, difficilement accessible dans le maillage et problématique dans Search Console mérite davantage d’attention qu’une simple variation de fréquence de crawl.
6. Méthode pratique pour analyser les logs d’un site WordPress
Une analyse utile ne nécessite pas de regarder chaque ligne manuellement. Il faut transformer les requêtes brutes en groupes exploitables.
1. Récupérer une période suffisamment représentative
Une fenêtre trop courte peut donner une vision trompeuse si certaines pages ne sont pas visitées quotidiennement. La durée pertinente dépend du volume de crawl et de la taille du site.
2. Nettoyer et vérifier les robots étudiés
Isolez les requêtes attribuables à Googlebot et écartez autant que possible les robots qui se contentent d’utiliser un user-agent similaire.
3. Classer les URLs par type
Regroupez les pages par catégories utiles au diagnostic : services, articles, produits, catégories, paramètres, anciennes URLs, ressources techniques ou autres modèles propres au site.
4. Calculer la répartition des codes HTTP
Examinez la part des requêtes terminant en 200, redirection, 404 ou erreur serveur, puis identifiez les URLs qui concentrent les anomalies.
5. Comparer les pages stratégiques au reste du site
Ne cherchez pas seulement les URLs les plus crawlées. Construisez également une liste des pages importantes pour vérifier si elles apparaissent réellement dans les journaux.
| Observation | Investigation suivante |
|---|---|
| Beaucoup de crawl sur des redirections | Rechercher anciens liens internes, chaînes et URLs historiquement connues. |
| Nombreuses URLs à paramètres | Examiner leur génération, leur utilité et leur rôle dans la navigation. |
| Erreurs serveur récurrentes | Identifier horaires, URLs concernées et cause infrastructurelle. |
| Page stratégique jamais observée | Contrôler liens internes, sitemap, indexabilité et inspection d’URL. |
| Anciennes URLs encore très demandées | Vérifier le plan de redirections et les liens externes ou internes persistants. |
Le « crawl budget » n’est pas le premier problème de tous les WordPress
Google précise que la gestion avancée du budget d’exploration concerne surtout les sites très volumineux ou connaissant des évolutions rapides. Sur un petit site, il est généralement plus utile de corriger les erreurs, le maillage et les problèmes d’indexation que de chercher à optimiser chaque requête de Googlebot.
En revanche, sur un gros WooCommerce, un média ou un site générant de nombreuses URLs, les logs peuvent devenir une source beaucoup plus stratégique.
Les logs serveur permettent d’observer le crawl réel, pas de lire l’index de Google. Utilisez-les pour identifier les URLs effectivement demandées, les codes HTTP retournés et les familles de pages qui concentrent le crawl. Vérifiez l’origine des robots, comparez les données avec Search Console et cherchez des anomalies concrètes avant de modifier robots.txt, les canonicals ou l’architecture du site.
Vos logs montrent des milliers d’URLs mais vous ne savez pas lesquelles posent problème ?
La page Audit de site WordPress présente une approche plus large pour croiser crawl, indexation, architecture et contenu avant de prioriser les corrections.
Voir l’audit de site WordPress →FAQ sur les logs serveur et Googlebot
Qu’est-ce qu’un log serveur WordPress ?
Dans ce contexte, il s’agit principalement du journal des requêtes reçues par l’infrastructure qui sert le site WordPress. Il ne faut pas le confondre avec le fichier de débogage PHP ou WordPress.
Les logs permettent-ils de savoir si une page est indexée ?
Non. Ils permettent de constater qu’une requête a été reçue. Pour étudier l’indexation, il faut compléter cette information avec les outils et rapports prévus par Google Search Console.
Comment savoir si un Googlebot présent dans les logs est authentique ?
Il ne faut pas se fier uniquement au user-agent. Google documente des méthodes de vérification basées notamment sur ses plages d’adresses IP publiées et sur la vérification DNS.
Beaucoup de 404 dans les logs sont-elles mauvaises pour le SEO ?
Pas automatiquement. Une URL définitivement supprimée peut légitimement retourner une réponse indiquant son absence. Il faut surtout identifier les erreurs touchant des pages qui devraient encore exister ou disposer d’une redirection pertinente.
Une page très crawlée est-elle importante pour Google ?
Une fréquence élevée de crawl ne permet pas à elle seule de conclure qu’une page est importante ou bien classée. Le rythme dépend de plusieurs facteurs et ne constitue pas une mesure directe de valeur SEO.
Faut-il optimiser le crawl budget d’un petit site WordPress ?
Généralement, ce n’est pas la priorité. Les problématiques avancées de budget d’exploration concernent davantage les sites très volumineux ou évoluant rapidement. Sur un petit site, architecture, liens, erreurs et indexabilité sont souvent plus importantes à contrôler en premier.
À quoi servent les logs sur WooCommerce ?
Ils permettent notamment de voir si Googlebot explore beaucoup de produits, catégories, paramètres, filtres ou anciennes URLs. Cela aide à vérifier le comportement réel avant de modifier la gestion de ces URLs.
Sources et références
- Google Search Central — Vérifier Googlebot — méthodes permettant de vérifier qu’une requête provient réellement d’un robot de Google.
- Google Search Console — Rapport sur les statistiques d’exploration — données agrégées concernant l’activité de crawl de Google sur un site.
- Google Search Central — Gestion du budget d’exploration — recommandations destinées principalement aux sites volumineux ou connaissant des changements rapides.
- Google Search Central — Codes HTTP et erreurs réseau — interprétation par Google des réponses HTTP et des erreurs rencontrées pendant l’exploration.
- Google Search Central — Présentation de robots.txt — fonctionnement du contrôle d’exploration par robots.txt et limites de son usage.
- Google Search Console — complément aux logs pour examiner indexation et performances dans Google Search.
