Comment Googlebot calcule-t-il réellement votre budget de crawl ?

Quelles ressources consomment vraiment du budget de crawl ?

La déclaration de John Mueller tranche une ambiguïté persistante : chaque requête HTTP compte. Pas seulement le HTML de vos pages. Les images embarquées dans vos articles, les fichiers JavaScript qui orchestrent vos interfaces, les feuilles de style CSS qui habillent vos contenus — tout ça tape dans le compteur.

Concrètement, une page web typique en 2020 pèse 2 Mo et génère 70 requêtes HTTP en moyenne. Si Googlebot crawl 1 000 pages de votre site, il peut facilement déclencher 70 000 requêtes serveur. Sur un site e-commerce avec des fiches produits bourrées de visuels haute définition ou une plateforme SaaS qui charge 15 scripts tiers, le ratio explose.

Cette granularité de comptage change la donne pour l'optimisation. Un site avec 10 000 URLs HTML mais 200 000 ressources statiques associées ne consomme pas le budget d'un site de 10 000 URLs. Il en consomme celui d'un site de 210 000 ressources crawlables.

Le cache de Google résout-il vraiment le problème ?

Mueller mentionne un « cache agressif » qui réduit les requêtes répétitives. C'est la bouée de sauvetage : si Googlebot a déjà crawlé votre logo header il y a 3 jours et que le fichier n'a pas changé, il ne le re-télécharge pas à chaque visite de page.

Le hic ? Google ne publie aucune métrique sur l'efficacité de ce cache. Combien de temps un fichier CSS reste-t-il en cache ? Quels critères déterminent qu'une ressource doit être re-crawlée ? [A vérifier] — aucune donnée officielle ne permet d'estimer le gain réel. Sur un site qui pousse des mises à jour quotidiennes de ses assets, le cache peut devenir quasi-inutile.

Les logs serveur montrent que certaines images sont effectivement crawlées une seule fois sur plusieurs semaines. D'autres, inexplicablement, se font re-télécharger tous les 2-3 jours. La logique de cache reste opaque et non garantie.

Pourquoi cette mécanique de comptage est-elle si importante ?

Le budget de crawl n'est pas infini. Google alloue un quota basé sur la santé serveur, l'autorité du domaine et la fraîcheur du contenu. Si vous gaspillez ce quota sur des ressources non prioritaires, vos nouvelles pages stratégiques ne seront pas crawlées à temps.

Un site d'actualité qui publie 50 articles par jour mais génère 5 000 requêtes pour des images non optimisées risque que ses articles récents ne soient indexés qu'avec 12-24h de retard. Sur des requêtes trending, ça tue le trafic. Même problème pour l'e-commerce en période de soldes : si Googlebot consomme son quota sur des anciens produits épuisés, les nouvelles fiches arrivent trop tard dans l'index.

• Chaque requête HTTP compte dans le budget de crawl, pas uniquement les pages HTML
• Un site avec beaucoup de ressources statiques (images, JS, CSS) consomme proportionnellement plus de budget qu'un site minimaliste
• Le cache de Google réduit les requêtes répétitives mais son efficacité reste non documentée et imprévisible
• Gaspiller du budget sur des ressources secondaires retarde l'indexation des contenus prioritaires
• Les logs serveur restent l'outil le plus fiable pour mesurer la consommation réelle de budget par type de ressource

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est même une des rares fois où Google donne un chiffre actionnable. Les analyses de logs confirment que Googlebot génère effectivement des dizaines de milliers de requêtes sur des sites moyens, bien au-delà du simple nombre de pages HTML. Les patterns montrent clairement que les images, scripts et feuilles de style apparaissent dans les hits Googlebot.

Le problème, c'est que cette transparence s'arrête là. Google ne dit pas quel poids relatif chaque type de requête a dans le calcul final du budget. Une image de 50 Ko compte-t-elle autant qu'une page HTML de 200 Ko ? Est-ce que le temps de réponse serveur module ce comptage ? Aucune réponse officielle. [A vérifier] dans vos propres données.

Le cache « agressif » est-il vraiment une solution fiable ?

Soyons honnêtes : le terme « agressif » sonne rassurant, mais il cache une absence totale de garantie. Les tests montrent une variabilité énorme selon les sites. Certains voient leurs CSS crawlés une fois par mois, d'autres toutes les semaines. Les mécanismes de validation (ETag, Last-Modified, Cache-Control) influencent peut-être le comportement, mais Google ne documente rien.

Pire, sur les sites qui utilisent des CDN avec URLs versionnées (style fichier.abc123.css), chaque déploiement change l'URL et invalide le cache. Résultat : le « cache agressif » ne sert à rien. Si vous pratiquez du cache-busting systématique pour vos assets, attendez-vous à ce que Googlebot les re-crawle intégralement à chaque passage.

Quelles stratégies cette logique invalide-t-elle ?

Certaines pratiques SEO courantes deviennent contre-productives à la lumière de cette déclaration. Embarquer 15 images haute résolution dans chaque article pour « enrichir le contenu » ? Ça explose votre budget. Charger 8 polices web custom pour une identité visuelle premium ? Pareil. Multiplier les scripts de tracking et widgets tiers pour analyser le comportement utilisateur ? Vous payez cash en quota de crawl.

Les sites qui ont optimisé leur Critical Rendering Path pour les utilisateurs (lazy loading agressif, minification, concaténation) gagnent aussi côté crawl. Moins de requêtes HTTP = budget préservé pour les vraies pages. Le Performance Budget devient un SEO Budget. C'est pas une coïncidence que les sites les plus performants en Core Web Vitals aient aussi souvent les meilleurs taux de crawl.

Comment auditer votre consommation réelle de budget ?

Première étape : analysez vos logs serveur. Filtrez les requêtes Googlebot sur une période de 30 jours et segmentez par type de ressource (HTML, images, CSS, JS, fonts, autres). Calculez le ratio requêtes/ressources versus pages HTML crawlées. Si vous voyez 10 000 pages HTML mais 150 000 requêtes totales, votre ratio est de 15:1 — chaque page HTML entraîne en moyenne 14 requêtes additionnelles.

Deuxième niveau : identifiez les gaspillages prioritaires. Quelles ressources sont crawlées le plus souvent sans apporter de valeur SEO ? Les anciennes versions de fichiers CSS toujours accessibles ? Les images de thumbnails redimensionnées côté serveur au lieu d'être pré-générées ? Les polices web exotiques utilisées sur 3 titres par page ? Tout ça vole votre budget.

Quelles optimisations techniques déployer en priorité ?

Commencez par robots.txt. Bloquez explicitement les ressources non essentielles à l'indexation : polices web, fichiers de tracking, images décoratives répétitives. Attention à ne pas bloquer ce qui sert au rendering (Google a besoin de voir le contenu tel que l'utilisateur le voit), mais tout ce qui est purement cosmétique peut sauter.

Ensuite, optimisez vos headers HTTP de cache. Cache-Control: max-age=31536000 pour les assets versionnés (qui ne changeront jamais une fois déployés). ETag et Last-Modified corrects pour permettre les requêtes conditionnelles 304 Not Modified. Si Googlebot peut valider qu'un fichier n'a pas changé sans le télécharger, ça économise du quota même si le cache interne de Google a expiré.

Troisième levier : le lazy loading intelligent. Les images en bas de page qui ne s'affichent que si l'utilisateur scrolle peuvent être chargées en JavaScript côté client. Googlebot verra quand même le contenu (il exécute le JS), mais si vous structurez bien, il ne déclenchera pas forcément toutes les requêtes images. Testez avec la Google Search Console pour vérifier que le rendu reste correct.

Quelle stratégie adopter pour les gros sites ?

Sur les sites de 100 000+ pages, la prioritisation devient critique. Utilisez les sitemaps XML segmentés par priorité métier : un sitemap pour les pages stratégiques (produits phares, landing pages), un autre pour le catalogue long tail, un troisième pour les contenus éditoriaux anciens. Ça ne contrôle pas directement le budget de crawl, mais ça guide Googlebot vers ce qui compte.

Ensuite, nettoyez impitoyablement. Les anciennes URLs qui génèrent des 404 mais restent crawlées ? Servez des 410 Gone pour signaler la suppression définitive. Les pages paginées infinies qui diluent le crawl ? Consolidez avec rel=prev/next ou passez en load-more JavaScript. Les facettes de filtres e-commerce qui explosent le nombre d'URLs ? Robots.txt ou balises noindex stratégiques.

Surveillez vos temps de réponse serveur. Un TTFB (Time To First Byte) rapide permet à Googlebot de crawler plus d'URLs dans le même laps de temps. Si votre serveur met 800ms à répondre au lieu de 200ms, vous perdez 75% de capacité de crawl. C'est mathématique : Google alloue un temps de crawl, pas un nombre de requêtes absolu.

• Auditez vos logs serveur sur 30 jours pour identifier le ratio requêtes totales / pages HTML crawlées
• Bloquez dans robots.txt les ressources décoratives non essentielles à l'indexation (polices, tracking, images répétitives)
• Configurez des headers HTTP Cache-Control agressifs (max-age=31536000) pour les assets versionnés
• Segmentez vos sitemaps XML par priorité métier pour guider le crawl vers les contenus stratégiques
• Nettoyez les URLs mortes (410 Gone), consolidez les paginations infinies, rationalisez les facettes de filtres
• Optimisez votre TTFB serveur pour maximiser le nombre d'URLs crawlables dans le quota temps alloué