Réponse courte
Le budget de crawl est le nombre de pages qu’un moteur explore sur un site pendant une période donnée. Il se situe à la rencontre de deux limites : ce que le serveur supporte, et l’intérêt que Google porte aux pages. Ce n’est pas un facteur de classement, c’est un préalable : une page jamais explorée ne peut pas se positionner.
Ce guide couvre la mesure et l’optimisation. Pour la définition seule, voir la fiche Budget de crawl du lexique.
2
composantes seulement : la capacité d’exploration du serveur et la demande de Google.
10 000
pages uniques au contenu qui change chaque jour : le seuil à partir duquel Google dit que le sujet compte.
0
place au classement : le budget conditionne l’exploration, jamais la position.
De quoi le budget de crawl est-il fait ?
De deux limites indépendantes, et c’est la plus basse des deux qui décide. Google les nomme capacité d’exploration et demande d’exploration.
La capacité protège votre serveur. Google borne le nombre de connexions parallèles et la durée pendant laquelle il les maintient ouvertes, pour ne pas dégrader le site pour vos visiteurs. Un serveur qui répond vite autorise davantage de requêtes ; des erreurs serveur répétées font baisser la cadence.
La demande, elle, mesure l’intérêt. Elle dépend de la taille du site, de la fréquence de mise à jour et de la qualité perçue des pages. Une URL populaire et souvent modifiée est revisitée vite ; une page figée depuis trois ans est revue de loin en loin.
La conséquence qu’on oublie. Augmenter la capacité de son serveur ne fait pas monter l’exploration si la demande reste basse. Sur la plupart des sites, le levier n’est pas la machine, c’est ce qu’on donne à explorer.
Comment Googlebot explore-t-il un site ?
En quatre temps, et l’exploration n’est que le deuxième. Le passage du robot ne garantit rien.
La découverte se fait par un lien interne, un lien externe ou le sitemap. L’exploration télécharge la page. Le rendu exécute ce qu’il faut pour la voir comme un visiteur. L’indexation est une décision distincte, prise après coup, sur le contenu obtenu.
D’où l’état « Explorée, actuellement non indexée » que remonte la Search Console : la page a bien été lue, elle n’a pas convaincu. Confondre les deux verbes fait chercher un problème d’exploration là où il y a un problème de contenu.
Googlebot n’est pas seul sur votre serveur. Bingbot, les robots des moteurs génératifs et les outils d’audit consomment eux aussi des ressources. Ce sont les journaux du serveur qui montrent qui passe réellement, et dans quelles proportions.
Quels sites sont vraiment concernés ?
Peu, en réalité. Google donne trois profils, en précisant que ce sont des ordres de grandeur et non des seuils exacts.
- Les sites de plus d’un million de pages uniques dont le contenu change environ une fois par semaine.
- Les sites de plus de 10 000 pages uniques dont le contenu change très vite, quotidiennement.
- Les sites dont une part importante des URL est classée « Détectée, actuellement non indexée ».
En dehors de ces cas, l’optimisation du crawl est un chantier à faible rendement. Sur un site vitrine de quelques dizaines de pages, Googlebot explore tout sans effort : le temps est mieux investi dans le contenu et dans la vitesse.
Sur votre site
Où part réellement votre budget d’exploration ?
Je relève dans vos journaux ce que Googlebot demande, les codes qu’il reçoit et les URL qui absorbent le crawl sans rien rapporter. Réponse sous 24 heures ouvrées.
Qu’est-ce qui fait varier le budget ?
Cinq facteurs, dont trois se corrigent sans toucher au serveur.
| Facteur | Effet sur l’exploration |
|---|---|
| Vitesse et santé du serveur | Un serveur rapide autorise plus de requêtes ; les erreurs 5xx répétées font baisser la cadence |
| Profondeur de clic | Une page à six ou sept clics de l’accueil est explorée rarement, parfois jamais |
| Maillage interne | Une page qui reçoit beaucoup de liens est perçue comme importante ; une page orpheline ne l’est pas |
| Fraîcheur du contenu | Une page qui change souvent est revisitée plus vite qu’une page figée |
| Erreurs et doublons | Chaque 404 servie, chaque chaîne de redirection et chaque doublon consomme une requête pour rien |
La profondeur et le maillage sont les deux leviers les plus rentables, parce qu’ils ne coûtent qu’une décision d’architecture. Ramener une page stratégique de six clics à trois change son rythme d’exploration sans ajouter une ligne de code.
Comment le mesurer ?
Une seule source dit ce que Googlebot a réellement demandé : la Search Console, complétée par les journaux du serveur.
Le rapport Statistiques d’exploration se trouve dans les paramètres de la Search Console. Il donne le total des requêtes, le poids téléchargé et le temps de réponse moyen, puis ventile les demandes par code de réponse, par type de fichier et par objectif, découverte d’une URL nouvelle ou actualisation d’une URL connue.
Il s’arrête là où commence l’analyse fine : il agrège, il ne dit pas quelle URL a été visitée. C’est le rôle des journaux du serveur, seule source qui montre l’adresse exacte, la fréquence et le code servi. Un crawler de bureau comme Screaming Frog complète le tableau en cartographiant la profondeur de clic et les pages orphelines, mais il simule ce qu’un robot pourrait rencontrer : il ne prouve pas ce qui a été exploré.
Ne pas confondre les trois sources. Un crawl d’audit montre ce que la structure permet. Les journaux montrent ce qui s’est passé. La Search Console montre ce que Google a retenu. Un site peut être parfait au crawl d’audit et pratiquement pas exploré dans les faits.
Comment orienter le budget vers les bonnes pages ?
En retirant ce qui absorbe des requêtes sans rien rapporter, puis en rapprochant les pages qui comptent.
- 01Repérer le gaspillage. Croiser la Search Console et les journaux pour lister ce que Googlebot demande sans valeur : pages en erreur toujours sollicitées, URL à paramètres qui multiplient les variantes, doublons, pages orphelines encore visitées.
- 02Rapprocher les pages stratégiques. Renforcer le maillage vers elles et réduire la profondeur de clic. Une page atteignable en trois clics est explorée bien plus souvent qu’une page enfouie à sept niveaux.
- 03Écarter les zones inutiles. Le fichier robots.txt refuse l’exploration des chemins sans intérêt, recherche interne et paramètres de tri en tête.
- 04Nettoyer le sitemap. Il ne doit lister que des URL canoniques en 200, sans redirection ni page bloquée. Un plan de site qui déclare des adresses mortes envoie le robot dans le vide.
- 05Raccourcir les redirections. Une chaîne de trois sauts force quatre requêtes pour une seule page. Les liens internes doivent pointer la destination finale, jamais une ancienne adresse redirigée.
User-agent: *
Disallow: /panier/
Disallow: /*?tri=
Disallow: /recherche/
Sitemap: https://votre-site.fr/sitemap.xmlLe raccourci à éviter. Bloquer le CSS et le JavaScript pour « économiser du crawl ». Googlebot en a besoin pour rendre la page : privé d’eux, il évalue un document qu’il ne voit pas correctement. Et bloquer une page dans le robots.txt ne la désindexe pas, cela empêche seulement le robot de lire le noindex qu’elle porte peut-être.
Quels codes HTTP Googlebot rencontre-t-il chez vous ?
Chaque requête reçoit un code, et ce code oriente la suite. C’est la lecture la plus rapide de la santé d’un crawl.
| Code | Ce qu’il dit | Effet sur l’exploration |
|---|---|---|
| 200 | Page servie normalement | Le cas nominal : le robot lit et revient |
| 301 | Redirection permanente | Toléré, mais chaque saut coûte une requête |
| 404 | Page introuvable | Consomme du budget tant que des liens y mènent |
| 500 | Erreur serveur | Le pire signal : Google ralentit pour ne pas aggraver la panne |
Le soft 404 mérite une mention à part : la page répond 200 alors qu’elle n’a rien à montrer. Google la traite comme une erreur tout en continuant de la demander. Servir un vrai 404, ou un 410 pour un contenu définitivement retiré, coûte moins cher qu’une page vide qui répond correctement.
Les pièges les plus fréquents, et comment les traiter
| Symptôme | Correction |
|---|---|
| Des milliers d’URL à paramètres explorées | Canonique vers l’URL de référence, tri et filtres écartés du crawl |
| Plusieurs sauts avant la page finale | Rediriger directement vers la destination, et corriger les liens internes |
| Des pages mortes toujours visitées | Retirer les liens qui y mènent et servir un code franc, 404 ou 410 |
| Beaucoup de pages fines ou dupliquées | Fusionner, enrichir ou retirer : c’est un travail de contenu, pas de configuration |
Sur un catalogue, la navigation à facettes produit à elle seule l’essentiel du gaspillage. Trois filtres combinables suffisent à fabriquer des centaines d’adresses pour un même produit. L’objectif n’est pas de tout bloquer, c’est de garder une version indexable par contenu réel.
Ce qui change avec les moteurs génératifs
Les robots des services d’IA s’ajoutent à ceux des moteurs, et ils explorent pour d’autres raisons. Un site qui gaspille déjà son budget le gaspille désormais deux fois.
Deux points méritent attention. D’abord le volume : sur un site que je mesure, les crawlers d’IA dépassent régulièrement Googlebot en nombre de requêtes. Ensuite le rendu : une page qui exige l’exécution complète du JavaScript coûte plus cher à explorer qu’une page servie en HTML. Le rendu côté serveur n’est pas seulement une question de vitesse perçue, c’est aussi ce qui décide du nombre de pages qu’un robot peut traiter dans le même temps.
La direction est la même pour tous ces robots : un site clair, rapide, sans impasse, avec un plan de site à jour. Ce ne sont pas des optimisations pour l’IA, ce sont les mêmes fondamentaux, mesurés plus souvent. Sur ce point, quinze ans d’évolution du métier disent la même chose : les outils changent, la propreté technique reste.
À retenir
- 01Deux composantes seulement : ce que le serveur supporte, et l’intérêt que Google porte aux pages. La plus basse décide.
- 02Le sujet ne concerne vraiment que les grands sites et ceux qui changent tous les jours.
- 03Ce n’est pas un facteur de classement : c’est un préalable à l’indexation, donc au positionnement.
- 04Les deux leviers les plus rentables sont la profondeur de clic et le maillage, pas la puissance du serveur.
Questions fréquentes
Le budget de crawl influence-t-il le positionnement ?
Pas directement, ce n’est pas un facteur de classement. Mais une page jamais explorée n’est jamais indexée, et une page non indexée ne se positionne pas. C’est un préalable technique, pas un levier de ranking.
Comment savoir combien de pages Google explore par jour ?
Le rapport Statistiques d’exploration de la Search Console donne le nombre de requêtes quotidiennes. Pour savoir quelles URL sont concernées, il faut les journaux du serveur : la Search Console agrège, elle ne détaille pas adresse par adresse.
Faut-il s’en préoccuper sur un petit site ?
Rarement. En dessous de quelques milliers de pages, Googlebot explore l’ensemble sans difficulté. La vigilance porte alors sur les erreurs, les redirections et la santé du serveur, pas sur le volume exploré.
À quelle fréquence Googlebot revient-il ?
Selon la demande d’exploration, qui dépend de la popularité et de la fraîcheur des pages. Une page mise à jour souvent et bien maillée est revue plus vite. Aucune cadence n’est garantie : Google ajuste en continu.
Augmenter la puissance du serveur augmente-t-il le crawl ?
Seulement si la capacité était la limite active. Si c’est la demande qui plafonne, un serveur plus rapide ne change rien au nombre de pages explorées.
Bloquer une page dans le robots.txt économise-t-il du budget ?
Oui pour l’exploration, non pour l’indexation. La page n’est plus demandée, mais elle peut rester dans l’index si des liens externes la citent. Et le robot ne lira jamais le noindex qu’elle porte.
Sources
- 1Google Search Central : Gérer le budget d’exploration d’un grand site, d’où viennent les deux composantes et les ordres de grandeur cités
- 2Search Console : Rapport Statistiques d’exploration
- 3Google Search Central : Erreurs HTTP et réseau rencontrées par Googlebot
- 4Définition courte et contexte dans la fiche Budget de crawl du lexique
