En 2021, j'ai repris un client -- un e-commerce basé à Birmingham avec environ 52 000 URLs indexées -- qui ne comprenait pas pourquoi à peu près 18 000 de ses pages produit n'avaient pas été crawlées en plus de trois mois. Son équipe dev devinait. Ajoutaient des sitemaps XML. Pingeaient Google Search Console. Rien ne marchait. Puis j'ai tiré les 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 de filtres paginé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. Du pur non-sens.
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.Server logs show exactly which pages Googlebot actually reads on a 50,000-page site; log analysis is the only ground truth for crawl-budget decisions.
C'est à ça que servent vraiment les analyses de fichier log -- pas aux métriques de vanité, pas aux présentations en salle de réunion, mais à savoir exactement ce qu'un crawler fait sur votre site un mardi donné et à couper le gras sans pitié.
Pourquoi le budget de crawl compte vraiment à l'échelle
Voilà 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 minutes. Mais une fois passé, 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 qu'il faut prioriser. La propre documentation de Google appelle ça le « crawl budget » et le décompose en deux composantes : crawl rate limit (à quelle vitesse Googlebot crawle sans surcharger votre serveur) et crawl demand (combien Google veut vraiment crawler selon les signaux de popularité et de fraîcheur).Google's own documentation calls this "crawl budget" and breaks it down into two components: crawl rate limit (how fast Googlebot crawls without hammering your server) and crawl demand (how much Google actually wants to crawl based on popularity and freshness signals).
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.which specific URLs are eating the budget. Server logs do. They show you every single request Googlebot made, to which URL, at what time, and what HTTP status code it received back. That's the raw material.
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 tableau de bord ou via SFTP -- regardez dans le répertoire /logs/. Sur un VPS avec Nginx, votre journal d'accès se trouve généralement à /var/log/nginx/access.log. Apache le place à /var/log/apache2/access.log. Si vous êtes sur un CDN comme Cloudflare, vous aurez besoin de Cloudflare Logpush (tier entreprise) sinon vous ne verrez que les requêtes à la limite du CDN, pas l'origine -- distinction importante.WordPress host like WP Engine or Kinsta, you can pull raw access logs from the dashboard or via SFTP -- look in the/logs/directory. On a VPS running Nginx, your access log is typically at/var/log/nginx/access.log. Apache puts it at/var/log/apache2/access.log. If you're on a CDN like Cloudflare, you'll need Cloudflare Logpush (enterprise tier) or you'll only see CDN-edge requests, not origin -- important distinction.
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..gz files. That's a normal size for a busy 50K-page site.
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 directement les fichiers log, filtrez par user agent Googlebot, et ça vous donne un résumé trié des URLs crawlées, fréquence de crawl, codes de statut et temps de réponse. Honnêtement, pour la plupart du travail d'agence c'est le bon outil. L'analyseur log de Screaming Frog gère des fichiers jusqu'à plusieurs GB sans broncher, ce qui compte. -- This is what I use 90% of the time. You import the log files directly, filter by Googlebot user agent, and it gives you a sortable breakdown of crawled URLs, crawl frequency, status codes, and response times. Honestly, for most agency work it's the right tool.Screaming Frog's log analyser handles files up to several GB without falling over, which matters.
- ELK Stack (Elasticsearch, Logstash, Kibana) -- Plus de configuration, beaucoup plus de puissance. Si vous avez des besoins de monitoring continu pour un gros client ou un contrat entreprise, ça vaut l'investissement. Seahawk a quelques clients où on pipe les logs directement dans un tableau de bord Kibana. En temps réel, magnifique, et vous pouvez configurer des alertes si la fréquence de crawl de Googlebot chute soudainement. -- More setup, significantly more power. If you've got ongoing monitoring needs for a large client or an enterprise contract, this is worth the investment. Seahawk has a couple of clients where we pipe logs directly into a Kibana dashboard. Real-time, beautiful, and you can set alerts when Googlebot crawl frequency drops suddenly.
Pour un audit ponctuel, Screaming Frog Log File Analyser c'est bon. Pour tout ce qui est continu, construisez la ELK stack ou au moins considérez GoAccess -- c'est open source, ça marche en terminal, et ça traite les gros fichiers log plus vite que presque tout ce que j'ai testé.GoAccess -- it's open source, runs in the terminal, and processes large log files faster than almost anything else I've tested.
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 groupe d'URLs importantes crawlées fréquemment (bon) et une longue traîne d'URLs sans valeur qui sont aussi crawlées fréquemment (très mauvais). Cette traîne sans valeur c'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.?colour=red&size=M&sort=price_asc more often than it was visiting the actual category pages. Wild.
Répartition des codes de statut
Filtrez tout ce qui n'est pas un 200. Spécifiquement :
- Des 404s crawlés répétitivement -- C'est une hémorragie de crawl budget. Corrigez-les avec des redirects 301 ou patchez les liens internes qui pointent dessus. -- These are a crawl budget haemorrhage. Fix them with 301 redirects or patch the internal links that point to them.
- Chaînes de redirections 301 -- Une redirection qui va A → B → C représente deux sauts inutiles. Googlebot les suit, mais cela consomme votre budget de crawl et le PageRank fuit à chaque étape. -- A redirect that goes A → B → C is two wasted hops. Googlebot follows them but it costs budget and PageRank leaks at each jump.
- Erreurs 500 -- Si Googlebot accède à des pages qui retournent des erreurs 500 et les réessaie ensuite, vous gaspillez du budget de crawl ET vous endommagez votre score d'indexabilité auprès de Google à long terme. -- If Googlebot is hitting pages that return 500s and then retrying them, you're wasting budget AND damaging your crawlability score with Google over time.
- 304 Not Modified -- C'est en réalité correct. Cela signifie que Google vérifie la fraîcheur de la page et que vos en-têtes de cache fonctionnent correctement. -- Actually fine. Means Google is checking freshness and your caching headers are working correctly.
Pics de temps de réponse
Google a déclaré publiquement que les temps de réponse serveur lents font que Googlebot crawle moins agressivement. Si vos logs montrent des temps de réponse moyens supérieurs à 500ms pour les URLs crawlées -- en particulier les pages de catégorie ou de produit -- c'est un signal pour corriger votre mise en cache côté serveur avant toute autre chose. that slow server response times cause Googlebot to crawl less aggressively. If your logs show average response times above 500ms for crawled URLs -- particularly category or product pages -- that's a signal to fix your server-side caching before anything else.
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 ou disallow -- Filtres, sélecteurs de couleur, sélecteurs de taille, options de tri. Ces éléments multiplient votre nombre d'URLs de façon exponentielle. Une catégorie de produits avec 10 options de filtre et 5 ordres de tri génère 50+ variantes d'URL dupliquées. Sur un site de 50 000 pages, cela représente potentiellement des centaines de milliers d'URLs. -- Filters, colour pickers, size selectors, sort orders. These multiply your URL count geometrically. A product category with 10 filter options and 5 sort orders generates 50+ duplicate URL variants. Across a 50K-page site, that's potentially hundreds of thousands of URLs.
- Archives paginées crawlées infiniment -- /page/2, /page/3... /page/847. Si le contenu à la page 200 de vos archives de blog n'a aucune valeur en termes de recherche organique, vous devez soit la marquer en noindex, soit interdire le chemin de pagination dans robots.txt. --
/page/2,/page/3.../page/847. If the content on page 200 of your blog archive has zero organic search value, you need to either noindex it or disallow the pagination path in robots.txt. - IDs de session dans les URLs -- Les anciennes plateformes CMS (et certaines configurations WooCommerce héritées) ajoutent des tokens de session comme ?sessionid=abc123def456 aux URLs. Chaque session génère une URL unique. Googlebot les crawle toutes. C'est une fuite catastrophique de budget de crawl sur les sites plus anciens. -- Old CMS platforms (and some legacy WooCommerce setups) append session tokens like
?sessionid=abc123def456to URLs. Every session generates a unique URL. Googlebot crawls all of them. This is a catastrophic budget leak on older sites. - Contenu dupliqué via paramètres d'URL -- ?utm_source=email dans les liens internes, paramètres de suivi qui s'échappent dans les URLs crawlables, ?ref=homepage ajouté par les plugins d'affiliation. Corriger cela via l'outil des paramètres d'URL dans Google Search Console et canonicaliser au niveau du HTML. --
?utm_source=emailin internal links, tracking parameters leaking into crawlable URLs,?ref=homepageappended by affiliate plugins. Fix in Google Search Console's URL parameter tool and canonicalise at the HTML level. - Pages orphelines sans liens internes mais toujours dans le sitemap -- Googlebot les trouve via le sitemap, les crawle, ne trouve aucun signal interne, et les déprioritise au fil du temps. Mais elles consomment quand même du budget de crawl lors des découvertes initiales. -- Googlebot finds them via sitemap, crawls them, finds no internal signal, deprioritises them over time. But they still eat budget on discovery crawls.
- Pages soft 404 retournant un statut 200 -- Pages de résultats de recherche vides, pages de catégorie vides, pages de profil utilisateur pour des comptes supprimés. Google perd du temps à crawler ces pages et les indexe parfois. -- Search pages with no results, empty category pages, user profile pages for deleted accounts. Google wastes time crawling these and sometimes indexes them.
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 :
- Le fichier robots.txt doit exclure les patterns d'URL qui ne doivent jamais être crawlés -- les paramètres de session, les combinaisons de filtres, les URLs de résultats de recherche interne. J'utilise des règles wildcard du type Disallow: /*?sessionid=style. Testez chaque règle dans l'outil de test robots.txt de Google Search Console avant de déployer. for URL patterns that should never be crawled -- session parameters, filter combinations, internal search result URLs. I use
Disallow: /*?sessionid=style wildcard rules. Test every rule in Google Search Console's robots.txt tester before deploying. - 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é. on paginated pages beyond page 2 or 3, depending on content freshness. Don't disallow pagination entirely or you break Googlebot's ability to discover linked content.
- 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. on all parameterised URL variants pointing to the clean canonical URL. This is belt-and-braces alongside 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 en parallèle avec les données de logs pour trouver quelles pages pointent vers des URLs mortes. -- Either update the internal links or implement 301 redirects. I use Screaming Frog's main crawler alongside the log data to find which pages are linking to dead URLs.
- Hygiène du sitemap XML -- Supprimez du sitemap toute URL qui retourne un code autre que 200, qui est en noindex, ou qui est une redirection. Votre sitemap doit être une liste triée des pages que vous voulez indexer, rien de plus. -- Remove any URL from your sitemap that returns a non-200, is noindexed, or is a redirect. Your sitemap should be a curated list of pages you want indexed, nothing else.
Seahawk avait un client fintech l'année dernière -- environ 65 000 pages, surtout du contenu dynamique -- où la simple correction du robots.txt pour bloquer les patterns de recherche interne a réduit le crawl de Googlebot sur les URLs inutiles de 61 % en six semaines. Les 39 % restants de budget de crawl se sont reportés sur les pages de produits et de catégories. L'indexation du nouveau contenu a chuté d'une moyenne de 23 jours à 6 jours. C'est l'impact dans le monde 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 de télécharger et analyser les logs mensuellement pour tout site dépassant 30 000 pages. Regardez la tendance de la 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 décline, quelque chose a changé -- de nouvelles fuites de budget de crawl, des problèmes de performance du serveur, ou une chute 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é ?
Un peu. Une indexation complète aujourd'hui ne signifie pas que ça reste ainsi. Si vous publiez régulièrement du nouveau contenu -- nouveaux produits, nouveaux articles de blog, nouvelles landing pages -- 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 des pages nouvelles non inspectées pendant des semaines. C'est un vrai désavantage concurrentiel si vous opérez dans une niche qui bouge vite.
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 URLs avec de nombreux paramètres de filtres sont tous des candidats raisonnables pour les règles Disallow. Ce que je vous conseille d'éviter, c'est de bloquer les fichiers JavaScript ou CSS -- Googlebot en a besoin pour bien rendre vos pages. 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 ?
Poussez votre fournisseur d'hébergement à vous les fournir -- la plupart des hébergeurs gérés les proposent même si ce n'est pas visible en évidence dans le tableau de bord. Si vous ne pouvez vraiment pas obtenir les logs bruts, l'analyse des bots de Cloudflare peut vous donner une image partielle pour les sites derrière le proxy Cloudflare, mais c'est un piètre substitut aux données de logs réelles. Envisagez de changer d'hébergeur si c'est un obstacle récurrent sur un gros compte client.Cloudflare's bot analytics can give you a partial picture for sites behind the Cloudflare proxy, though it's a pale substitute for real log data. Consider switching hosts if this is a recurring blocker on a large client account.
Les statistiques de crawl de Google Search Console suffisent-elles ?
Pour un petit site, c'est discutable. Pour tout ce qui dépasse 20 000 pages, non. Les statistiques de crawl dans GSC sont agrégées par jour et ne présentent pas de données au niveau de l'URL. Vous pouvez voir que Googlebot a crawlé 12 000 pages un mardi, mais pas quelles 12 000 pages. Les fichiers logs vous donnent cette résolution. Les deux outils ensemble -- c'est l'image complète.which 12,000 pages. Log files give you that resolution. Both tools together -- that's the complete picture.
---
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.