Google a réécrit son Guide sur le budget d'exploration le 22 juillet 2026, et la quasi-totalité des pages qui expliquent actuellement le budget d’exploration pour les sites de commerce électronique datent d’avant cette date. La ligne qui importe le plus pour une boutique est nouvelle : votre capacité d’exploration est un pool unique partagé entre tous les robots d’exploration de Google ; ainsi, l’exploration de vos flux, de vos images et de vos annonces entre en concurrence avec la découverte des produits.
Voici mon avis sincère après avoir lu le nouveau document dans son intégralité et l'avoir testé sur notre propre site. La plupart des boutiques en ligne ne rencontrent absolument aucun problème de budget d'exploration, et celles qui en rencontrent ont généralement un problème d'URL en double qui se présente sous la forme d'un problème de budget d'exploration.
Principaux enseignements
- Google a remanié son document consacré au « budget d'exploration » le 22 juillet 2026 et précise désormais qu'une seule limite de capacité d'exploration est partagée entre tous ses robots d'exploration.
- Google Shopping effectue un indexation plus intensive lorsque vous disposez de flux de produits, et AdsBot effectue une indexation plus intensive avec les annonces dynamiques ; ainsi, les deux puisent dans le même vivier pour la découverte des produits.
- La plupart des sites ne rencontrent pas de problème lié au budget d'exploration ; selon Google, si vos pages sont explorées le jour même de leur publication, vous pouvez ne pas vous préoccuper de ce sujet.
- Lorsqu'une boutique en présente un, cela est généralement dû à la génération d'URL en double (balises, filtres, paramètres de tri, pagination), et non à une limite trop basse.
- La prise en charge du code HTTP 304 permet d'économiser des ressources lors de l'exploration, mais la “ prise en charge du 304 ” dépend du type de validateur envoyé par votre serveur ; notre serveur d'origine le respecte via l'ETag et non via l'en-tête « If-Modified-Since ».
- Vous ne pouvez pas demander d'augmentation de votre budget d'exploration ; Google n'augmente cette limite que si votre serveur continue à répondre rapidement et fonctionne correctement.
En quoi consiste exactement le « crawl budget » d'une boutique en ligne ?
Le budget d'exploration correspond à l'ensemble des URL que Google peut et souhaite explorer sur votre site. Il est déterminé par deux facteurs : votre limite de capacité d'exploration (la capacité de votre serveur à gérer les explorations) et celle de Google demande de référencement (dans quelle mesure Google souhaite réellement explorer vos pages).
Considérez la limite de capacité comme la porte d'un magasin très fréquenté. Elle correspond au nombre de personnes que Google autorise à entrer en même temps, ainsi qu'au délai d'attente entre chaque visite, et est définie de manière à ne pas surcharger votre serveur. Ce nombre n'augmente que si votre serveur continue à répondre rapidement, et il diminue si votre serveur commence à montrer des signes de saturation.
La « demande d'exploration » représente l'autre aspect : c'est l'intérêt que porte Google à vos pages, qui dépend de leur popularité et de la fréquence à laquelle elles sont mises à jour. Une boutique en ligne qui ajoute et modifie quotidiennement ses produits génère une réelle demande ; un site statique de type « brochure » en génère très peu. Si vous souhaitez en savoir plus sur les aspects liés à la mesure, consultez notre ancien guide sur la recherche du budget crawl et ses cas d'utilisation explique étape par étape comment lire les chiffres dans Search Console.
Votre site rencontre-t-il réellement un problème de budget d'exploration ?
La plupart des sites ne le font pas, et Google le précise sur la même page que tout le monde utilise pour promouvoir l'optimisation du budget d'exploration. Le document remanié indique clairement que si vos pages “ semblent être explorées le jour même de leur publication, vous n'avez pas besoin de lire ce guide ”.”
Google présente l'ensemble de ce guide comme un document destiné aux utilisateurs avancés pour trois types de sites : les grands sites comptant un million d'URL ou plus et dont le contenu évolue chaque semaine, les sites de taille moyenne ou grande comptant 10 000 URL ou plus et dont le contenu évolue quotidiennement, et les sites dont une grande partie des URL figurent dans Search Console en tant que Découvert, non indexé pour le moment. Il précise également que ces chiffres constituent “ une estimation approximative ” et ne sont “ pas des seuils exacts ” ; il convient donc de les considérer comme un indicateur de tendance et non comme une règle.
| Vous pouvez ne pas tenir compte du budget d'exploration si | Vous devriez y prêter attention si |
|---|---|
| Les nouveaux produits sont indexés le jour même de leur publication | Vous gérez un catalogue volumineux (environ 1 million d'URL ou plus) qui évolue chaque semaine |
| Votre boutique est de petite ou moyenne taille (moins de 10 000 URL environ) | Vous disposez d'au moins 10 000 URL et le contenu évolue quotidiennement |
| Peu d'URL figurent dans la catégorie “ Découvertes, non indexées pour le moment ” | Une grande partie de vos URL se trouve dans la catégorie “ Découvertes, non indexées pour le moment ” |
Ce qu'a changé la nouvelle version du document de Google sur le budget d'exploration publiée en juillet 2026
La majeure partie de la révision du 22 juillet concernait des ajustements mineurs. Google a expliqué qu’elle visait à améliorer “ la clarté, la cohérence terminologique et la fluidité du texte ”, ainsi qu’à s’assurer qu’un terme tel que limite de capacité d'exploration est utilisé de la même manière tout au long du texte, ce qui Table ronde sur les moteurs de recherche signalé le matin même de son atterrissage.
Mais quelques lignes sont véritablement nouvelles, et l'une d'entre elles est la raison d'être de cet article. Le document a également été discrètement déplacé : il figurait auparavant dans la documentation consacrée à la recherche et se trouve désormais dans une section plus large consacrée à l'exploration, ce qui correspond à son argument selon lequel le même budget est alloué aux robots d'exploration de la recherche, de Shopping et de la publicité.
| Ligne neuve ou affûtée | Pourquoi est-ce important pour un magasin ? |
|---|---|
| Une limite de capacité d'exploration est commune à tous les robots d'exploration | Le référencement de votre fil d'actualité, de vos images et de vos publicités entre en concurrence avec la découverte des produits |
| Google Shopping explore plus intensément les flux des commerçants ; AdsBot explore plus intensément les annonces dynamiques | Indique les crawlers de magasin précis qui utilisent le pool partagé |
| Chaque site démarre avec la même limite de capacité par défaut, fixée de manière prudente. | Google ne l'augmente que lorsque votre serveur démontre qu'il est capable d'en supporter davantage |
| Prise en charge du code HTTP 304 (Non modifié) pour éviter de télécharger à nouveau les pages qui n'ont pas été modifiées | Vous pouvez le vérifier sur votre propre domaine d'origine ; la plupart des boutiques ne renvoient jamais de code 304. |
Pourquoi une seule limite de capacité d'exploration est-elle partagée entre tous les robots d'exploration de Google ?
Le document révisé de Google l'indique désormais clairement : “ la limite de capacité d'exploration est partagée entre tous les robots d'exploration ”, et “ une forte demande de la part d'un robot d'exploration peut réduire la capacité disponible pour les autres ”. Cette simple phrase change la façon dont il faut envisager l'exploration d'une boutique en ligne.
Le document cite ensuite les robots d'exploration qui importent pour une boutique. Il précise qu'AdsBot “ est généralement plus sollicité lorsqu'un site utilise des cibles publicitaires dynamiques, et que Google Shopping est plus sollicité pour les produits figurant dans vos flux marchands ”. En lisant ces deux lignes ensemble, le tableau est clair : Googlebot pour la découverte des pages, Googlebot-Image pour vos photos de produits, Google Shopping pour votre flux et AdsBot pour vos pages de destination publicitaires puisent tous dans le même budget d'hébergement.
Il s'agit ici de Google décrivant ses propres systèmes, ce qui constitue la forme la plus solide de déclaration d'un fournisseur, mais reste néanmoins une déclaration d'un fournisseur ; je la considère donc comme son explication du fonctionnement de l'exploration plutôt que comme une règle établie. Ce que nous pouvons démontrer de première main, c’est la répartition sur notre propre site. Même en l’absence de flux Merchant Center actif, nos statistiques d’exploration dans Search Console ventilent l’exploration par type de robot d’exploration, et AdsBot représente à lui seul 9% de ce temps, la récupération des images et des ressources des pages en représentant une part importante.
Sur une boutique en ligne, cette composition est nettement plus orientée vers l'exploration des flux et des images que sur un site de contenu comme le nôtre. Si vous souhaitez découvrir comment l'un de ces robots d'exploration spécifiques aux boutiques se comporte en conditions réelles, nous avons documenté ce sujet séparément dans notre analyse de Google StoreBot.
Comment une boutique peut nuire à la visibilité de ses propres produits
Un site disposant d'un vaste catalogue d'images, d'un flux de produits actif et diffusant des annonces Shopping ou Performance Max peut voir ses pages produits indexées plus lentement, et ce non pas en raison d'une erreur de référencement sur la page. Cela s'explique par le fait que l'exploration de son propre flux, de ses images et de ses annonces épuise le quota partagé avant que Googlebot n'ait le temps d'indexer les nouveaux produits.
Nos propres données laissent entrevoir pourquoi cela pose problème. Dans les statistiques d'exploration, 90% L'une des activités de l'explorateur de Google sur notre site consiste à actualiser les pages qu'il connaît déjà, et uniquement 10% C'est la découverte, cette partie qui identifie de toutes nouvelles URL. Sur une boutique qui publie des produits tous les jours, c'est précisément avec cette mince part de découverte que votre flux et votre exploration d'images sont en concurrence.
Comment un site utilise son budget de crawl partagé
- Googlebot, Googlebot-Image, Google Shopping et AdsBot puisent tous dans un même pool de ressources partagé
- Le traitement intensif des images, des flux et des publicités mobilise une part importante de ces ressources
- Il reste moins de capacité à Googlebot pour découvrir et actualiser les pages
- Les pages de produits nouvelles ou mises à jour sont indexées et actualisées plus lentement
La prise en charge du code HTTP 304 permet-elle réellement d'économiser du budget d'exploration ?
Oui, quand cela fonctionne réellement. Le document de Google ajoute une nouvelle ligne demandant aux sites de “ prendre en charge les codes d'état HTTP 304 (Not Modified) ”, car un code 304 indique à Google de réutiliser la copie dont il dispose déjà au lieu de télécharger à nouveau la page. Mais “ prendre en charge le code 304 ” ne se résume pas à activer un simple bouton ; cela dépend du validateur que votre serveur envoie.
Un code 304 fonctionne grâce à des requêtes conditionnelles. Google mémorise l’ETag d’une page (une empreinte du contenu) ou sa date “ Last-Modified ”, puis demande : « Y a-t-il eu des changements depuis ? ». Si rien n’a changé, le serveur doit renvoyer un code 304 et ne pas envoyer de corps de réponse. Nous avons testé exactement cela sur notre propre serveur d'origine, qui utilise un cache de pages LiteSpeed, et le résultat s'est avéré plus mitigé que ne le laisse supposer cette instruction d'une seule ligne.
| Demande sous condition que nous avons envoyée | Ce que notre origine nous a rendu |
|---|---|
| If-None-Match avec l'ETag propre à un article de blog | HTTP 304 Non modifié |
| If-None-Match avec l'ETag de la page d'accueil | HTTP 304 Non modifié |
| « If-Modified-Since » avec une date récente | HTTP 200, la page complète s'affiche à nouveau |
Nous “ prenons donc en charge la règle 304 ” via l'en-tête ETag et non via l'en-tête If-Modified-Since, simplement parce que nos pages renvoient un en-tête ETag mais pas d'en-tête Last-Modified. Une requête If-Modified-Since n'ayant aucun élément à comparer, le serveur renvoie donc la page dans son intégralité. Nos statistiques d'exploration le confirment : « Non modifié (304) » se trouve sous 1% de toutes les réponses d'exploration de notre site, ce qui signifie que Google télécharge à nouveau presque tout, même lorsque le contenu n'a pas changé.
La leçon à retenir pour une boutique en ligne est de tester par soi-même plutôt que de partir de suppositions. Envoyez les deux requêtes conditionnelles vers une page produit et vérifiez laquelle votre plateforme prend en charge, car une boutique comportant beaucoup d’images ou de flux qui ne renvoie jamais de code 304 gaspille des ressources en récupérant à nouveau des octets qui n’ont pas changé. Il s’agit de la même vérification au niveau des en-têtes que celle que nous avons utilisée dans notre guide sur Comment vérifier si votre CDN met en cache.
Le véritable problème pour la plupart des boutiques en ligne réside dans la génération d'URL en double
Pour la plupart des sites qui se classent vraiment lentement, le problème ne réside pas dans un plafond de classement trop bas, mais dans un nombre trop élevé d’URL à faible valeur. Le document de Google appelle cela “ l’inventaire perçu ” et précise qu’il s’agit du “ facteur sur lequel vous avez le plus de contrôle ”, ce qui est une façon polie de dire que c’est généralement vous qui êtes à l’origine de ce gaspillage.
Sur une boutique en ligne, ces URL apparaissent sans que personne ne les ait créées. Chaque balise d’une collection dispose de sa propre URL, chaque filtre de la vitrine en ajoute une, chaque critère de tri en ajoute une autre, et chacun d’entre eux génère une pagination. Google consacre alors son exploration à des pages quasi identiques au lieu de se concentrer sur vos véritables produits. Nous avons analysé ce mécanisme en détail pour une plateforme dans notre article sur Contenu en double dans les collections Shopify, et la mise en page est identique sur WooCommerce.
Vu sous cet angle, le budget d'exploration est le symptôme et la génération d'URL en double est la cause du problème. En remédiant à cette prolifération d'URL, le “ problème de budget ” se résout généralement de lui-même ; c'est pourquoi je me pencherais sur ce point bien avant de m'inquiéter de la limite de capacité.
Comment gérer le budget d'exploration d'une boutique en ligne
Les leviers que Google vous met réellement à disposition sont limités : supprimer les URL en double et indésirables, veiller à ce que le serveur reste rapide et en bon état de fonctionnement, et orienter l'exploration vers ce qui compte vraiment. Il n'y a pas de bouton permettant de demander davantage de budget, alors ne tenez pas compte de ceux qui laissent entendre le contraire.
- Regrouper les contenus en double Ainsi, Google consacre son exploration “ au contenu unique plutôt qu’aux URL uniques ”, selon ses propres termes. Les balises « canonical », une navigation à facettes bien structurée et le fait de ne pas indexer les URL de filtrage et de tri font ici l’essentiel du travail.
- Renvoyez un code 404 ou 410 pour les produits que vous avez supprimés définitivement, car Google considère une erreur 404 comme “ un signal fort indiquant de ne plus explorer cette URL ”, ce qui lui permet d'éviter de gaspiller des requêtes sur des références obsolètes.
- Évitez les longues chaînes de redirection, qui, selon Google, “ ont un effet négatif sur l'exploration ” ; une boutique migrée regorgeant de redirections en chaîne ralentit l'exploration à chaque étape. Notre guide sur détection et aplatissement des chaînes de redirection prend en charge le nettoyage.
- Veillez à ce que le serveur reste rapide et stable, car la santé de l'exploration est le seul critère qui influe sur votre limite : des temps de réponse stables et un temps de réponse jusqu'au premier octet l'augmentent, tandis que les erreurs 5xx et les réponses de limitation de débit 429 la réduisent.
- Ne comptez pas sur le fichier robots.txt pour “ dégager des fonds ”. Google précise clairement qu’il “ ne réaffectera pas ce budget d’exploration nouvellement disponible à d’autres pages, sauf si Google atteint déjà la limite de capacité d’exploration de votre site ” ; le blocage des URL indésirables permet donc de mieux cibler l’exploration, et non de gagner en marge de manœuvre.
- N'utilisez pas « noindex » pour préserver l'exploration ni l'un ni l'autre ; Google continue de demander la page, puis l'abandonne dès qu'il détecte la balise, donc vous avez déjà utilisé votre quota de requêtes.
Vous pouvez consulter toutes ces informations là où se trouvent les chiffres réels, à savoir dans les statistiques d'exploration de Search Console et dans les journaux de votre serveur. Sur notre propre site, l'état de l'hébergeur est « normal », avec un 460 ms un temps de réponse moyen et l'absence de problèmes liés à l'hébergeur, ce qui correspond à la situation où la limite augmente au lieu de diminuer.
Si vous souhaitez aller plus loin que ce résumé, vos journaux de serveur bruts indiquent précisément quel robot d'indexation a accédé à quelle URL et à quel moment. Nous avons abordé la manière de les lire, notamment comment distinguer les différents types de robots d'indexation, dans notre guide consacré à Analyse des fichiers journaux pour l'IA et les robots d'indexation.
Votre boutique doit-elle donc se préoccuper du budget d'exploration ?
Honnêtement, pour la plupart des boutiques en ligne, la réponse est non, et le document remanié le reconnaît discrètement. Si vos produits sont explorés le jour même de leur publication et que Search Console ne regorge pas d’URL “ Découvertes, mais non indexées pour le moment ”, vous feriez bien mieux de consacrer votre temps à la création de contenu et à l’acquisition de liens plutôt qu’à tenter d’atteindre un plafond d’exploration que vous n’atteignez pas.
Les boutiques qui devraient s’en préoccuper sont les grands catalogues à rotation rapide, et pour elles, la véritable nouveauté de juillet 2026 réside dans le pool partagé : le crawl de votre flux, de vos images et de vos annonces entre désormais clairement en concurrence avec la découverte des produits ; ainsi, un ensemble d’URL trop volumineux ou un flux trop lourd n’est pas un problème distinct de “ Google met du temps à trouver mes produits ”, c’est la cause même du problème. Mon conseil est volontairement banal. Vérifiez d’abord si vous êtes réellement confronté à ce problème, puis corrigez les URL en double et assurez-vous du bon fonctionnement de votre serveur avant de vous lancer dans des solutions sophistiquées, car c’est là que va réellement votre budget.
Questions fréquentes sur le budget d'exploration des boutiques en ligne
Comment puis-je vérifier le budget d'exploration de ma boutique ?
Ouvrez Search Console, accédez à « Paramètres », puis à « Statistiques d'exploration ». Vous y trouverez le nombre total de requêtes d'exploration, le temps de réponse moyen, l'état de l'hôte, ainsi qu'une ventilation par type de Googlebot. C'est ce qui se rapproche le plus, chez Google, d'un aperçu en temps réel de la manière dont votre budget est utilisé.
Le fait de bloquer des URL de filtres dans le fichier robots.txt permettra-t-il de libérer du budget d'exploration pour mes produits ?
Pas en soi. Google précise qu'il ne réaffectera pas le quota de crawl ainsi libéré à d'autres pages, sauf si vous avez déjà atteint votre limite de capacité. Le blocage des URL indésirables aide Google à se concentrer sur les bonnes pages, mais cela ne vous offre pas de marge supplémentaire.
Quelle est la limite de capacité d'exploration ?
Il s'agit du nombre maximal de pages que Google peut explorer simultanément sur votre site, ainsi que du délai qu'il laisse entre chaque exploration, défini de manière à ne pas surcharger votre serveur. Chaque site commence avec la même valeur par défaut prudente, et Google ne l'augmente que lorsque votre serveur prouve qu'il est capable d'en gérer davantage.
Travailler avec WpConsults
Vous ne savez pas si votre boutique en ligne rencontre un problème de budget d'exploration ?
Si vos pages produits mettent du temps à être référencées, ou si une grande partie d'entre elles se trouve dans la catégorie “ Découvertes, non indexées pour le moment ”, je peux analyser vos statistiques d'exploration et vos fichiers journaux pour vous dire s'il s'agit réellement d'un problème de budget d'exploration ou d'un problème d'URL en double déguisé.
Journal des mises à jour
23 juillet 2026
- Publié pour la première fois, cet article s'appuie sur la nouvelle version du budget d'exploration de Google datée du 22 juillet 2026, ainsi que sur nos propres statistiques d'exploration et un test HTTP 304 réalisé directement sur notre serveur d'origine.
Vous souhaitez que nos publications apparaissent plus souvent sur Google ?
En un clic, Google affichera ce site dans votre rubrique « À la une ».
