Vous avez déjà vu ce rapport dans la Search Console : « Découverte – non indexée », en jaune, sur une page que vous avez publiée il y a six semaines. Vous l'avez relue trois fois, elle est propre, elle répond à une vraie question, et pourtant Google ne l'a jamais visitée. Ce n'est pas un problème de qualité. C'est un problème de budget.
Le crawl budget, c'est la quantité de ressources que Google accepte de consacrer à l'exploration de votre site sur une période donnée. Et tant qu'on n'a pas géré un domaine qui dépasse quelques milliers d'URLs, on ne comprend pas à quel point ce plafond est réel. Sur un site de 40 pages, vous ne le sentirez jamais. Sur un catalogue de 30 000 références avec des facettes de filtres, il décide de tout.
Points clés à retenir
- Le crawl budget est la résultante de deux forces : la capacité de votre serveur à répondre, et l'intérêt que Google porte à vos pages.
- Un site de moins de 1 000 pages n'a presque jamais de problème de budget — il a un problème de qualité ou de maillage.
- Le gaspillage vient presque toujours des mêmes endroits : paramètres d'URL, facettes, pagination infinie, redirections en chaîne.
- Les logs serveur restent la seule source fiable pour mesurer ce que Googlebot consomme réellement chez vous.
- Les erreurs 5xx et 429 en rafale font chuter la vitesse d'exploration, et la remontée prend des semaines.
Le crawl budget, une définition qui tient debout
Googlebot n'explore pas votre site d'un bloc. Il le visite par vagues, à une fréquence qui dépend de deux réglages que Google combine en permanence.
Les deux facteurs qu'on confond tout le temps
Le premier, c'est le crawl rate limit. Il représente votre côté de l'équation : combien de requêtes par seconde votre hébergement peut encaisser sans s'écrouler. Un serveur qui répond en 120 ms autorise beaucoup plus de passages qu'un serveur qui met 3 secondes.
Le second, c'est le crawl demand. Là, c'est Google qui décide. Est-ce que vos pages changent souvent ? Est-ce que d'autres sites pointent vers elles ? Sont-elles populaires dans les résultats ? Si la réponse est non, non et non, Googlebot viendra moins. Voilà tout.
Ce qui rend le sujet vicieux, c'est que ces deux curseurs interagissent. Je me souviens d'un client e-commerce dont le serveur tombait en timeout dès 15 requêtes simultanées. Google l'a détecté en quelques jours et a réduit sa cadence. Résultat : des nouvelles fiches produit attendaient trois semaines avant la première visite. Le problème n'était pas le SEO. C'était la RAM du serveur.
Qui est vraiment concerné par cette histoire
Franchement, la majorité des sites n'ont pas de problème de crawl budget. Un blog de 200 articles, une boutique de 500 références, un site vitrine : Google les explore intégralement sans jamais forcer.
Le seuil où ça commence à mordre se situe autour de plusieurs milliers d'URLs, ou dès qu'un site génère des pages à la volée (recherche interne, filtres, tri, pagination). Et là, le budget devient une ressource rare qu'il faut arbitrer.
- Les catalogues e-commerce avec paramètres de tri et de filtre
- Les annuaires et places de marché
- Les sites d'actualité qui publient tous les jours
- Les forums avec des milliers de profils et de fils de discussion
Comment mesurer ce que Googlebot consomme vraiment
C'est le point que la plupart des articles sautent. On vous explique l'optimiser sans jamais vous dire comment le regarder. Voici ma méthode, celle que j'applique depuis que j'ai compris que la Search Console seule ne suffit pas.
Le rapport « Statistiques sur l'exploration »
Dans la Search Console, ce rapport vous donne le nombre de requêtes par jour, la taille moyenne des réponses téléchargées et le temps de réponse moyen. C'est un bon point de départ, mais il est plafonné : Google n'y expose qu'un échantillon.
Ce que j'y cherche en premier, c'est la répartition par type de fichier. Si vous voyez une grosse part de .jpg ou .css dans les explorations, vous avez un problème de priorisation. Googlebot dépense du budget sur des ressources qui ne seront jamais indexées comme pages.
Les logs serveur, la vraie source
Un fichier de logs brut, filtré sur l'user-agent Googlebot, vous dit tout : quelles URLs ont été visitées, combien de fois, avec quel code de statut, et à quelle heure. Croisez ça avec votre sitemap et vous avez la carte de vos gaspillages.
Sur un audit récent, j'ai découvert que 38 % des requêtes Googlebot partaient sur des URLs de recherche interne du type /recherche?q=. Des milliers d'adresses uniques, toutes vides de valeur. Une seule ligne dans le robots.txt a redirigé ce budget vers les vraies fiches produit. Le taux d'indexation des nouvelles pages est passé de quelques jours à moins de 24 heures.
Le taux de réponse, l'indicateur qu'on oublie
Regardez la proportion de réponses en 200 par rapport au total. Si Googlebot reçoit beaucoup de 301, de 404 ou de 5xx, il travaille pour rien. Chaque redirection consomme une requête et n'apporte aucune page nouvelle à l'index.
| Signal dans les logs | Ce que ça coûte | Action |
|---|---|---|
| Pics de 5xx | Googlebot ralentit, parfois pendant des semaines | Stabiliser le serveur avant tout le reste |
| 429 en rafale | Signal explicite de « reviens plus tard » | Augmenter les limites de connexions |
| URLs paramétrées | Des milliers d'adresses sans contenu propre | Disallow ou canonical |
| Chaînes de 301 | Deux à quatre requêtes pour une seule page finale | Réécrire les redirections en direct |
| Pages « Découverte – non indexée » | URLs connues mais jamais visitées | Revoir maillage et priorité sitemap |
Les signaux qui montrent que votre budget part en fumée
Un budget mal optimisé ne fait pas de bruit. Il se manifeste par des symptômes qu'on met sur le dos d'autres causes pendant des mois.
Des pages découvertes mais jamais explorées
Si le rapport « Pages » de la Search Console affiche un stock croissant d'URLs en « Découverte – actuellement non indexée », et que ce stock ne se vide pas, c'est le signe numéro un. Google connaît l'adresse, mais il ne juge pas le passage prioritaire.
Dans mon expérience, ce symptôme vient rarement du serveur. Il vient du maillage interne. Une page orpheline, ou enterrée à six clics de l'accueil, n'attire presque aucun passage.
Le gaspillage sur les facettes et la pagination
Les filtres à choix multiple génèrent des combinaisons quasi infinies. Une catégorie avec cinq filtres à trois valeurs chacun, c'est déjà 243 URLs possibles, dont la plupart affichent trois produits. Googlebot les explore, une par une, et votre budget fond.
La solution n'est pas de tout bloquer. Bloquer la pagination profonde coupe l'accès aux produits listés en fin de catégorie. Il faut trier : garder les combinaisons qui ont du volume de recherche, neutraliser les autres.
Le contenu dupliqué qui aspire les visites
Deux versions d'une même page, avec et sans slash final, avec et sans majuscules : chacune consomme une requête. Multipliez par quelques milliers d'URLs et l'effet devient mesurable. Un canonical correct règle le problème en une ligne.
Comment optimiser votre crawl budget, concrètement
Passons à l'action. Je classe ces leviers par ordre d'impact réel, du plus fort au plus marginal.
Le robots.txt, à manier avec précision
C'est l'outil le plus puissant et le plus mal utilisé. Bloquer une URL ici ne l'empêche pas d'être indexée si elle est liée ailleurs — c'est une confusion que je rencontre dans un audit sur deux.
Ce qu'on bloque, ce sont les chemins sans valeur : recherche interne, paniers, pages de session, tris. Ce qu'on ne bloque jamais : les pages qui doivent être indexées, et surtout pas le CSS ou le JS dont Google a besoin pour rendre vos pages.
La performance serveur, le levier qu'on néglige
Un temps de réponse qui passe de 800 ms à 200 ms peut multiplier la cadence d'exploration. Je l'ai mesuré sur un site de presse : après migration vers un hébergement plus rapide, le nombre de requêtes Googlebot par jour a presque doublé en dix jours, sans toucher au contenu.
Concrètement, ça veut dire : cache serveur, CDN, base de données indexée, et surveillance des pics de 5xx. Rien de spectaculaire, mais l'effet est direct.
Sitemap et maillage interne
Votre sitemap est une liste de priorités que vous tendez à Google. S'il contient 40 000 URLs dont 35 000 sont secondaires, vous diluez le signal. Gardez-le propre, à jour, et limitez-le aux pages que vous voulez réellement voir indexées.
Le maillage interne travaille dans le même sens. Plus une page importante reçoit de liens contextuels depuis d'autres pages fortes, plus elle sera explorée souvent. C'est la version la plus ancienne et la plus efficace du référencement, et elle n'a pas pris une ride.
- Placez vos pages stratégiques à moins de trois clics de l'accueil
- Utilisez des liens contextuels dans le corps du texte, pas seulement dans les menus
- Retirez les liens vers les pages mortes ou obsolètes
Les questions qu'on me pose souvent
Combien de temps faut-il pour voir une amélioration ?
Comptez plusieurs semaines. Après correction, Google met généralement quelques jours à détecter le changement, puis quelques semaines à ajuster sa cadence. Sur un serveur qui plantait régulièrement, j'ai vu le retour à la normale prendre près de deux mois. C'est frustrant, mais c'est le rythme.
Bloquer une URL dans le robots.txt empêche-t-il son indexation ?
Non. Le robots.txt empêche l'exploration, pas l'indexation. Si d'autres sites pointent vers cette URL, Google peut l'indexer sans jamais l'avoir lue — et afficher un extrait vide ou incorrect. Pour retirer une page de l'index, il faut une balise noindex, et la page doit rester explorable pour que Google la lise.
Mon site fait 300 pages, dois-je m'en préoccuper ?
Non, et perdre du temps là-dessus serait une erreur. Sur un petit site, le budget n'est jamais le goulot d'étranglement. Si une page ne s'indexe pas, cherchez du côté du contenu, du maillage ou des balises canonical. Vous gagnerez des semaines.
Ce qu'il faut vraiment retenir
Le crawl budget n'est pas une notion abstraite qu'on agite pour se donner un genre technique. C'est une ressource finie, et sur les gros sites, chaque requête gaspillée est une page utile qui attend.
Mais voici ce que j'ai fini par comprendre après plusieurs années à courir après ce chiffre : le crawl budget n'est presque jamais le vrai problème. C'est un symptôme. Derrière un budget mal optimisé, il y a toujours un serveur lent, un maillage paresseux ou des URLs qu'on a laissées se multiplier sans réfléchir. Réparez la cause, et le budget suit.
La prochaine fois que vous verrez une page en « Découverte – non indexée », ne cherchez pas un réglage magique. Ouvrez vos logs, regardez où va votre budget, et demandez-vous si chaque requête consommée vous rapporte quelque chose. La réponse est souvent gênante. C'est là que le travail commence.