En 2021, j'ai repris un client, un e-commerçant basé à Birmingham avec environ 52 000 URLs indexées, qui ne comprenait pas pourquoi roughly 18 000 de ses pages produits n'avaient pas été crawlées en plus de trois mois. Son équipe dev devinait. Ajout de sitemaps XML. Ping vers Google Search Console. Rien ne marchait. Puis j'ai extrait leurs journaux serveur bruts et en environ quarante minutes la réponse était complètement évidente : Googlebot brûlait son allocation de crawl quotidienne sur des URLs paginées filtrées, des paramètres de session, et une facette de recherche interne cassée qui générait quelque chose comme 4 000 URLs uniques mais inutiles par semaine. Gaspillage total. Pur nonsense.
Point clé : Les journaux serveur montrent exactement quelles pages Googlebot lit réellement sur un site de 50 000 pages ; l'analyse des journaux est la seule source fiable pour les décisions concernant le budget de crawl.
C'est à ça que l'analyse de fichiers journaux sert réellement, pas aux métriques de vanité, pas aux slides de board room, mais à découvrir exactement ce qu'un crawler fait sur votre site un mardi quelconque et à couper le gras impitoyablement.
Pourquoi le budget de crawl compte vraiment à l'échelle
Voici ce que la plupart des gens se trompent sur. Le crawl budget n'est pas une préoccupation pour un site brochure de 200 pages. Googlebot le balayera en quelques minutes. Mais une fois que vous dépassez, disons, 20 000 URLs, et définitivement quand vous êtes à 50 000 ou plus, le crawler de Google prend des décisions explicites sur ce à quoi donner la priorité. La documentation propre de Google appelle ça le « crawl budget » et le divise en deux composants : la limite de taux de crawl (à quelle vitesse Googlebot crawle sans surcharger votre serveur) et la demande de crawl (combien Google veut réellement crawler en fonction des signaux de popularité et de fraîcheur).
Tous deux peuvent être manipulés. Mais vous ne pouvez pas manipuler ce que vous ne pouvez pas mesurer. Et vous ne pouvez pas le mesurer correctement sans les journaux.
Les outils d'analyse comme Google Search Console vous donnent un rapport de statistiques de crawl. C'est acceptable comme point de départ. Mais c'est agrégé, retardé, et ça ne vous dit pas quelles URL spécifiques consomment le budget. Les logs serveur, oui. Ils vous montrent chaque requête que Googlebot a faite, vers quelle URL, à quel moment, et quel code de statut HTTP il a reçu en retour. C'est la matière première.
Obtenir les Logs
Ça semble évident mais c'est là que la plupart des gens bloquent. Selon votre configuration d'hébergement, les logs se trouvent à différents endroits.
Sur un hébergement WordPress géré comme WP Engine ou Kinsta, vous pouvez extraire les journaux d'accès bruts depuis le dashboard ou via SFTP, regardez dans le répertoire /logs/. Sur un VPS exécutant Nginx, votre journal d'accès se trouve typiquement à /var/log/nginx/access.log. Apache le met à /var/log/apache2/access.log. Si vous êtes sur un CDN comme Cloudflare, vous aurez besoin de Cloudflare Logpush (tier enterprise) ou vous ne verrez que les requêtes de CDN-edge, pas l'origine, distinction importante.
Pour ce client à Birmingham, ils étaient sur un serveur géré Kinsta. J'ai récupéré 30 jours de logs, ce qui représentait environ 4,2 GB de fichiers compressés .gz. C'est une taille normale pour un site actif de 50 000 pages.
Analyser les Logs Bruts Sans Perdre la Tête
Vous avez deux options réelles ici :
- Screaming Frog Log File Analyser, C'est ce que j'utilise 90% du temps. Vous importez les fichiers journaux directement, filtrez par user agent Googlebot, et ça vous donne une répartition triable des URLs crawlées, de la fréquence de crawl, des codes de statut, et des temps de réponse. Honnêtement, pour la plupart du travail d'agence c'est le bon outil. L'analyseur de journaux de Screaming Frog gère les fichiers jusqu'à plusieurs GB sans s'effondrer, ce qui compte.
- ELK Stack (Elasticsearch, Logstash, Kibana), Plus de setup, significativement plus de puissance. Si vous avez des besoins de monitoring continu pour un gros client ou un contrat enterprise, ça vaut l'investissement. Seahawk a quelques clients où nous piped les journaux directement dans un dashboard Kibana. Temps réel, magnifique, et vous pouvez définir des alertes quand la fréquence de crawl de Googlebot chute soudainement.
Pour un audit ponctuel, Screaming Frog Log File Analyser c'est correct. Pour quoi que ce soit de continu, construisez la pile ELK ou au moins considérez GoAccess, c'est open source, ça tourne dans le terminal, et ça traite les gros fichiers journaux plus vite que presque tout ce que j'ai testé.
Ce qu'il faut réellement chercher
Une fois les données chargées, la plupart des gens les fixent du regard sans savoir quelles questions poser. Voici ce que je cherche vraiment dans un audit de logs :
Distribution de la fréquence de crawl
Triez vos URLs par fréquence de crawl, combien de fois Googlebot a frappé chaque URL dans la fenêtre de 30 jours. Vous trouverez presque toujours une distribution bimodale. Un cluster d'URLs importantes crawlées fréquemment (bon) et une longue queue d'URLs poubelles qui sont aussi crawlées fréquemment (très mauvais). Cette queue poubelle est votre problème.
Sur le site de Birmingham, les 500 URL crawlées les plus demandées incluaient 340 combinaisons de filtres/facettes. Aucune d'elles n'était indexée. Aucune n'avait le moindre volume de recherche. Googlebot visitait ?colour=red&size=M&sort=price_asc plus souvent qu'il ne visitait les pages de catégorie réelles. Dingue.
Répartition des codes de statut
Filtrez tout ce qui n'est pas un 200. Spécifiquement :
- Des 404s étant crawlées répétées, C'est une hémorragie de crawl budget. Fixez-les avec des redirections 301 ou patchez les liens internes qui les pointent.
- Chaînes de redirection 301, Une redirection qui passe par A → B → C représente deux sauts inutiles. Googlebot les suit mais cela consomme du budget et le PageRank s'échappe à chaque étape.
- Erreurs 500, Si Googlebot accède à des pages qui retournent des erreurs 500 et les réessaye ensuite, vous gaspillez du budget ET vous endommagez votre score d'accessibilité aux crawlers auprès de Google au fil du temps.
- 304 Not Modified, C'est en fait correct. Cela signifie que Google vérifie la fraîcheur du contenu et que vos en-têtes de cache fonctionnent correctement.
Pics de temps de réponse
Google a déclaré publiquement que les temps de réponse lents du serveur font que Googlebot crawle moins agressivement. Si vos logs montrent des temps de réponse moyens supérieurs à 500 ms pour les URLs crawlées, en particulier les pages de catégories ou de produits, c'est un signal pour corriger votre cache côté serveur avant toute autre chose.
Identifier les éléments qui tuent le budget
Je vais vous donner une liste des choses que je vois consommer le budget de crawl sur les grands sites, à peu près dans l'ordre de fréquence:
- Navigation à facettes sans noindex ni disallow, Filtres, sélecteurs de couleur, sélecteurs de taille, ordres de tri. Ces éléments multiplient votre nombre d'URLs de manière exponentielle. Une catégorie de produits avec 10 options de filtrage et 5 ordres de tri génère 50+ variantes d'URLs dupliquées. Sur un site de 50 000 pages, cela représente potentiellement des centaines de milliers d'URLs.
- Archives paginées crawlées infiniment, /page/2, /page/3... /page/847. Si le contenu de la page 200 de votre archive de blog n'a aucune valeur pour la recherche organique, vous devez soit l'indexer avec noindex, soit bloquer le chemin de pagination dans robots.txt.
- IDs de session dans les URLs, Les anciennes plateformes CMS (et certains anciens paramétrages WooCommerce) ajoutent des jetons de session comme ?sessionid=abc123def456 aux URLs. Chaque session génère une URL unique. Googlebot crawle toutes ces URLs. C'est une fuite de budget catastrophique sur les sites plus anciens.
- Contenu dupliqué via paramètres d'URL, ?utm_source=email dans les liens internes, les paramètres de suivi qui s'échappent dans les URLs crawlables, ?ref=homepage ajoutés par les plugins d'affiliation. À corriger dans l'outil de paramètres d'URL de Google Search Console et à canonicaliser au niveau du HTML.
- Pages orphelines sans liens internes mais toujours dans le sitemap, Googlebot les trouve via le sitemap, les crawle, ne trouve aucun signal interne, les déprioritise au fil du temps. Mais elles consomment quand même du budget lors des crawls de découverte.
- Pages soft 404 retournant un statut 200, Pages de résultats de recherche sans résultats, pages de catégories vides, pages de profil utilisateur pour des comptes supprimés. Google perd du temps à crawler ces pages et les indexe parfois.
Corriger Ce Que Vous Trouvez
Honnêtement, l'analyse est la partie la plus facile. C'est l'implémentation qui rend les projets politiques.
Voici mon flux de travail réel quand j'ai terminé un audit de log et que je dois présenter des recommandations :
- Robots.txt disallow pour les modèles d'URL qui ne doivent jamais être crawlés, les paramètres de session, les combinaisons de filtres, les URL de résultats de recherche interne. J'utilise des règles wildcard du type Disallow: /*?sessionid=style. Testez chaque règle dans l'outil robots.txt de Google Search Console avant de déployer.
- Noindex + nofollow sur les pages paginées au-delà de la page 2 ou 3, selon la fraîcheur du contenu. Ne désactivez pas complètement la pagination ou vous empêcherez Googlebot de découvrir le contenu lié.
- Balises canoniques sur toutes les variantes d'URL paramétrées pointant vers l'URL canonique propre. C'est une sécurité supplémentaire aux côtés du robots.txt.
- Corrigez les 404 à la source. Soit vous mettez à jour les liens internes, soit vous implémentez des redirections 301. J'utilise le crawler principal de Screaming Frog avec les données de log pour identifier les pages qui renvoient vers des URL mortes.
- Hygiène XML sitemap. Supprimez de votre sitemap toute URL qui retourne un code différent de 200, qui est noindexée, ou qui est une redirection. Votre sitemap doit être une liste curée des pages que vous voulez indexer, rien d'autre.
Seahawk avait un client fintech l'année dernière, environ 65 000 pages, principalement du contenu dynamique. Le simple fait de corriger robots.txt pour bloquer les modèles d'URL de recherche interne a réduit le crawl par Googlebot des URL inutiles de 61 % en six semaines. Les 39 % restants du budget de crawl se sont redistribués vers les pages produits et catégories. L'indexation du nouveau contenu est passée d'une moyenne de 23 jours à 6 jours. C'est l'impact réel.
Configuration de la Surveillance Continue
Un audit de logs, c'est un instantané. Une bonne gestion du crawl budget, c'est continu. À quoi ça ressemble concrètement en pratique ?
Au minimum, je recommande d'extraire et d'analyser les logs mensuellement pour tout site au-dessus de 30 000 pages. Regardez la tendance de fréquence de crawl pour vos 100 meilleures URLs génératrices de revenus. Si la fréquence de visite de Googlebot sur ces pages baisse, quelque chose a changé : nouvelles fuites de budget de crawl, problèmes de performance du serveur, ou une baisse du signal PageRank.
Si vous voulez être plus sophistiqué, configurez GoAccess en tant que tâche cron pour traiter les instantanés de logs quotidiens et envoyer un rapport récapitulatif par email. Ça prend environ deux heures à configurer et vous évite de manquer l'érosion lente du crawl budget entre les audits trimestriels.
FAQ
Le crawl budget a-t-il de l'importance si je suis déjà complètement indexé ?
Plus ou moins. Une indexation complète aujourd'hui ne signifie pas qu'elle reste ainsi. Si vous publiez régulièrement du nouveau contenu, de nouveaux produits, de nouveaux articles de blog, de nouvelles pages de destination, le budget de crawl détermine la rapidité avec laquelle ce contenu frais est découvert. Un site avec un budget de crawl qui fuit peut avoir de nouvelles pages restant inexaminées pendant des semaines. C'est un vrai désavantage compétitif si vous êtes dans un secteur en mouvement rapide.
Devrais-je bloquer entièrement Googlebot de certains sous-dossiers en utilisant robots.txt ?
Oui, dans des cas spécifiques. Les zones admin, les chemins de staging, les résultats de recherche interne, et les URL de filtres chargées de paramètres sont tous des candidats raisonnables pour les règles Disallow. Ce que je vous mets en garde, c'est de ne pas bloquer les fichiers JavaScript ou CSS. Googlebot a besoin de ceux-ci pour rendre vos pages correctement. Beaucoup de vieux conseils SEO disent de bloquer le JS; ignorez-les.
Combien de données de logs devrais-je analyser ?
30 jours, c'est le juste milieu pour la plupart des sites. Moins que ça et vous ne verrez pas les motifs de crawl basse fréquence. Plus que ça et la taille des fichiers devient ingérable sauf si vous avez une véritable stack ELK. Pour les sites e-commerce saisonniers, je regarde parfois 60 jours couvrant une période de pointe pour comprendre le comportement de crawl sous charge de trafic.
Et si mon hébergeur ne fournit pas d'accès brut aux logs ?
Mettez la pression sur votre fournisseur d'hébergement. La plupart des hébergements gérés ont cela disponible même si ce n'est pas affiché en évidence dans le tableau de bord. Si vous ne pouvez vraiment pas obtenir les logs bruts, l'analyse bot de Cloudflare peut vous donner une image partielle pour les sites derrière le proxy Cloudflare, bien que ce soit un piètre substitut aux vraies données de log. Envisagez de changer d'hébergeur si c'est un blocage récurrent sur un compte client important.
Les statistiques de crawl de Google Search Console suffisent-elles ?
Pour un petit site, on peut dire que oui. Pour tout au-dessus de 20 000 pages, non. Les statistiques de crawl de GSC sont agrégées par jour et ne révèlent pas de données au niveau de l'URL. Vous pouvez voir que Googlebot a crawlé 12 000 pages un mardi mais pas lesquelles. Les fichiers de log vous donnent cette résolution. Les deux outils ensemble, c'est le tableau complet.
---
Bon, la plupart des SEOs sautent l'analyse des logs parce que ça ressemble à du territoire DevOps. Ce n'est pas glamour. Vous grep des gigabytes de timestamps et de chaînes user-agent. Mais sur les gros sites, c'est la différence entre deviner où va votre crawl budget et le savoir vraiment. Et savoir, de mon expérience, ça vaut toujours les deux heures que ça prend pour extraire les données.
Lectures complémentaires : Recherche de mots-clés par IA en 2026 : ce que c'est, pourquoi la recherche traditionnelle, la recherche par IA, et le SEO multilingue.