Crawl budget : quand s'inquieter et comment le mesurer

Le crawl budget est ce genre de sujet qui n'entre dans la conversation qu'une fois devenu un probleme. Google a publie en 2017 que les sites de moins de quelques milliers d'URLs n'ont pas a s'en preoccuper, et cette phrase est devenue une excuse pour ignorer le sujet meme sur des e-commerces de 800 000 PDPs. Le point de bascule n'est presque jamais le nombre d'URLs dans le sitemap, mais le ratio entre pages utiles et pages que Googlebot rencontre. Quand ce ratio passe sous les 30%, vous saignez deja du crawl, meme si le trafic organique ne le montre pas encore.

Le premier signal pratique apparait dans Search Console, dans Parametres > Statistiques de l'exploration. Si les requetes quotidiennes chutent de 40% en deux semaines sans changement de serveur, ou si le temps de reponse moyen passe de 300ms a 1.2s, vous avez un probleme de budget. Autre symptome classique : des pages neuves mettant plus de 10 jours a etre indexees sur un site qui recevait Googlebot le jour meme. Avant de toucher quoi que ce soit, il vaut la peine de mener un Comment auditer le SEO on-page sans tomber dans les conjectures honnete pour ecarter une cause cote contenu.

Le vrai diagnostic vit dans les logs serveur. Filtrer par user-agent Googlebot sur 30 jours de logs Nginx ou Cloudflare revele des choses que GSC ne montrera jamais : combien de fois le bot a frappe des URLs avec parametre ?sort=, combien sont revenues en 404, combien de hits sur des paginations infinies issues de filtres a facettes. Chez un client, 62% du crawl partait vers des URLs avec trois parametres ou plus, toutes canoniques vers la version propre. La solution n'a pas ete le noindex, mais la correction des liens internes et la revue des Canonical tags : les erreurs frequentes qui saignent le trafic organique pour arreter l'hemorragie a la source.

Trois pieges techniques concentrent la majorite des cas. Le premier est un robots.txt mal configure qui bloque des ressources dont le renderer a besoin, d'ou la lecture obligatoire sur robots.txt: les pieges qui bloquent l'indexation en silence. Le second est un sitemap gonfle d'URLs en 404, redirigees ou en noindex, traite dans Sitemap XML moderne: priorite, lastmod et ce qu'il faut ignorer. Le troisieme, plus subtil, c'est du JavaScript qui ne rend le contenu qu'apres interaction, faisant voir a Googlebot des pages vides et bruler du quota. Le guide JavaScript SEO: rendu, hydration et indexation couvre les patterns qui marchent en 2026 avec Next.js et Astro.

Pour mesurer avec precision, construisez une requete BigQuery croisant l'export GSC avec les logs CDN. Comptez les URLs distinctes crawlees par jour, groupez par motif de path (/p/, /c/, /blog/, /tag/), et calculez le ratio entre crawlees et indexees. Si /tag/ represente 35% du crawl mais 2% des impressions, vous avez une fuite claire. Ce type d'analyse est detaille dans BigQuery + GSC: les requetes que votre agence ne lance pas et dans Log file analysis : ce que Googlebot fait vraiment, qui montre comment separer le vrai Googlebot des bots qui usurpent le user-agent (autour de 18% du trafic se declarant Googlebot, selon les donnees Cloudflare 2024).

Il y a un moment ou le probleme cesse d'etre technique et devient architectural. Les sites de plus de 100 000 URLs actives ont besoin d'une logique de priorisation dans le HTML lui-meme : lastmod fiable, maillage interne refletant l'importance commerciale des pages, et suppression aggressive des variantes qui ne generent pas de demande. Si votre categorie principale recoit moins de hits Googlebot qu'une page de tag obsolete, le probleme n'est pas le budget, c'est la conception. A retenir : lancez une log analysis de 30 jours avant le prochain trimestre, classez vos URLs en trois seaux (actives, dormantes, dechets), et attaquez le troisieme en premier. Le crawl budget se retablit en 6 a 8 semaines une fois que vous arretez de nourrir ce qui ne devrait pas exister.