Demande d’exploration

En bref — Le budget d’exploration comporte deux dimensions : la vitesse à laquelle un moteur de recherche peut récupérer vos pages (cadence d’exploration) et la quantité de pages qu’il veut explorer (demande d’exploration). La demande correspond au « vouloir ». Google souhaite davantage explorer une page lorsqu’elle est populaire, change souvent et paraît digne d’intérêt. Aucun bouton ne permet d’augmenter cette demande : elle se gagne grâce aux liens, à une fraîcheur réelle et à un inventaire d’URL débarrassé des pages inutiles.

Qu’est-ce que la demande d’exploration ?

Lorsque l’on parle de « budget d’exploration », on réunit en réalité deux notions distinctes. La première est la capacité du serveur à supporter l’exploration : sa vitesse et le nombre de pages qu’il peut servir simultanément. C’est la cadence d’exploration, traitée sur une page dédiée. La seconde est la quantité de pages que le moteur de recherche souhaite effectivement explorer. C’est la demande d’exploration, sujet de cette page.

Pensez à l’offre et à la demande. La cadence représente l’offre, c’est-à-dire le volume d’exploration que votre site peut supporter. La demande représente la quantité d’exploration que Google souhaite effectuer. Evidence for this claim Google describes crawl demand as one of the two main elements of crawl budget, alongside crawl capacity limit. Scope: Google Search crawling. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Ce qui incite Google à explorer une page

Google cite plusieurs facteurs importants, sans prétendre fournir une liste exhaustive. Il en développe surtout trois :

• Popularité. Les pages recevant davantage de liens sont explorées plus souvent afin que Google conserve une copie récente.
• Obsolescence et fraîcheur. Google souhaite vérifier plus fréquemment une page qui change beaucoup et espace ses visites lorsqu’elle reste immuable.
• Nombre d’URL que Google pense trouver sur le site. Si le site regorge d’URL inutiles, dupliquées ou de faible valeur, Google consacre de l’exploration à celles-ci plutôt qu’aux pages utiles. C’est le facteur que vous maîtrisez le mieux. Evidence for this claim Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Scope: These inputs influence crawling but do not provide a user-controlled demand setting. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Google mentionne également la taille du site, sa fréquence de mise à jour, la qualité des pages et leur pertinence par rapport à des sites comparables. Popularité, obsolescence et inventaire perçu ne forment donc pas une formule complète : ce sont les leviers les plus importants et les plus faciles à actionner, pas la totalité des facteurs.

Un autre facteur est temporaire : lors d’une migration de site vers un nouveau domaine, Google doit réexplorer l’ensemble du contenu sous les nouvelles URL. La demande augmente donc pendant un certain temps.

Pourquoi vous ne pouvez pas simplement « augmenter la demande d’exploration »

Il n’existe aucun réglage direct, pas plus qu’un bouton obligeant Google à explorer plus vite. Publier dix articles par jour ne change rien si personne ne crée de lien vers eux et s’ils ne sont pas réellement utiles. Les méthodes efficaces sont lentes et concrètes : obtenir des liens, maintenir une vraie fraîcheur et supprimer les URL inutiles afin que l’exploration atteigne les pages importantes.

Voici le point contre-intuitif : davantage d’exploration n’est même pas l’objectif. Être souvent exploré n’améliore pas le classement. Il ne faut pas chercher plus de demande, mais orienter la demande existante vers les bonnes pages.

Pour approfondir l’interaction entre demande et capacité du serveur, le retour des signaux de qualité vers le planificateur et le diagnostic entre demande et capacité, ouvrez l’onglet Avancé.

En bref — La demande d’exploration est le côté vouloir du budget, tandis que la cadence ou capacité d’exploration en est le côté pouvoir. Google cite la popularité (liens et PageRank), l’obsolescence (fréquence de changement) et l’inventaire perçu (nombre d’URL supposées, y compris les URL inutiles) comme facteurs généraux importants, sans en faire une formule fermée ; la taille du site, la fréquence de mise à jour, la qualité des pages et leur pertinence comparative comptent aussi. Les migrations de site provoquent une hausse temporaire. Ma synthèse est la suivante : la demande ordonne les URL par priorité ; la capacité liée à la charge de l’hôte détermine jusqu’où Googlebot descend dans cette file. Google ne décrit pas ce modèle comme un algorithme littéral, mais il correspond aux éléments disponibles. Un serveur sain ne crée pas de demande, tandis qu’une demande élevée peut rester limitée par la capacité. La demande ne se règle pas directement : on agit sur ses facteurs, et le planificateur l’augmente lorsque les signaux de qualité issus de l’indexation s’améliorent. Google cherche parallèlement à explorer moins, mais plus précisément. L’objectif est donc la bonne priorisation, non le volume. La plupart des sites n’ont jamais besoin de gérer ce sujet.

La demande est le « vouloir » ; la cadence est le « pouvoir »

Google indique explicitement que le budget d’exploration comprend deux composantes : “is determined by two main elements: crawl capacity limit and crawl demand.” (traduction) « est déterminé par deux éléments principaux : la limite de capacité d’exploration et la demande d’exploration ». Dans mon guide Ahrefs sur le budget d’exploration, je le formule ainsi : “made up crawl demand which is how many pages a search engine wants to crawl on your site and crawl rate which is how fast they can crawl.” (traduction) « composé de la demande, soit le nombre de pages qu’un moteur souhaite explorer sur votre site, et de la cadence, soit la vitesse à laquelle il peut les explorer ». Autrement dit, la première exprime l’intention du moteur et la seconde son aptitude technique. Evidence for this claim Google describes crawl demand as one of the two main elements of crawl budget, alongside crawl capacity limit. Scope: Google Search crawling. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Cette page ne traite que du vouloir. Le côté pouvoir — limite de capacité, ancien curseur GSC retiré en janvier 2024, ralentissement de Googlebot par les réponses 5xx/429 et grille manuelle Crawl Control de Bing — relève de la page sur la cadence d’exploration. Je renverrai vers elle lorsque les deux notions interagissent.

Les trois principaux facteurs de demande

La documentation actuelle de Google présente l’inventaire perçu, la popularité et l’obsolescence comme des facteurs généraux importants, sans prétendre à une formule exhaustive et fermée. Elle cite aussi la taille du site, sa fréquence de mise à jour, la qualité des pages et leur pertinence par rapport à des sites similaires. Les trois facteurs ci-dessous sont les plus détaillés par Google et ceux sur lesquels vous pouvez agir directement. Evidence for this claim Google's crawl-demand guidance discusses perceived inventory, popularity, and staleness. Scope: These inputs influence crawling but do not provide a user-controlled demand setting. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Popularité

“URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” (traduction) « Les URL les plus populaires sur Internet tendent à être explorées plus souvent afin de rester à jour dans nos systèmes. » Davantage de liens et de PageRank vers une URL constituent un signal de demande : c’est pourquoi une page d’accueil est visitée constamment, alors qu’une page profonde sans lien l’est à peine. Comme je l’écris dans mon guide : “Popular pages, or those with more links and PageRank, will generally receive priority over other pages.” (traduction) « Les pages populaires, ou celles qui reçoivent davantage de liens et de PageRank, sont généralement prioritaires. » Les liens internes comptent également : une page orpheline ne bénéficie presque d’aucune demande.

Obsolescence

“Our systems want to recrawl documents frequently enough to pick up any changes.” (traduction) « Nos systèmes souhaitent réexplorer les documents assez souvent pour détecter les changements. » Google apprend le rythme propre à chaque page : une page constamment modifiée est souvent réexplorée, tandis qu’une page immuable l’est de moins en moins. Dans mon guide, je décris le recul appliqué à une page statique : “if they crawl a page and see no changes after a day, they may wait three days before crawling again, ten days the next time, 30 days, 100 days, etc.” (traduction) « si une page ne présente aucun changement après un jour, ils peuvent attendre trois jours avant de revenir, puis dix jours, 30 jours, 100 jours, etc. » Cette cadence par URL relève de la fréquence d’exploration, mais sa force sous-jacente est la demande, en particulier l’obsolescence.

Inventaire perçu : le facteur le plus maîtrisable

Voici le levier principal. Google écrit : “Without guidance from you, Google tries to crawl all or most of the URLs that it knows about on your site. If many of these URLs are duplicates, or you don’t want them crawled for some other reason (removed, unimportant, and so on), this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.” (traduction) « Sans indications de votre part, Google tente d’explorer tout ou partie des URL connues sur votre site. Si beaucoup sont dupliquées ou ne doivent pas être explorées, cela gaspille un temps considérable ; c’est le facteur que vous pouvez le mieux maîtriser. »

L’effet subtil concerne la demande, pas seulement la capacité. Les URL inutiles gaspillent certes des récupérations au détriment de nouveaux contenus. Mais un inventaire connu surtout composé de doublons de faible valeur et de paramètres donne aussi à Google l’image d’un site moins intéressant à explorer. Réduire cet inventaire ne libère pas seulement de la capacité : avec le temps, cela concentre la demande sur les URL qui la méritent. Navigation à facettes, identifiants de session, calendriers infinis et autres pièges à robots sont les gonfleurs d’inventaire classiques — et des réducteurs classiques de demande.

Migrations et autres pics de demande

Un facteur ne concerne aucune URL isolée : “Additionally, site-wide events like site moves may trigger an increase in crawl demand in order to reprocess the content under the new URLs.” (traduction) « Des événements touchant tout le site, comme une migration, peuvent accroître la demande afin de retraiter le contenu sous les nouvelles URL. » Après un changement de domaine ou de plateforme, une forte activité de Googlebot pendant quelques semaines est normale : tout doit être récupéré et retraité aux nouvelles adresses. Il s’agit d’un pic temporaire, pas d’un nouveau niveau de référence, bien que ce phénomène soit rarement mentionné dans les guides concurrents.

Interaction entre demande et charge de l’hôte : ordre de la file et plafond de capacité

Voici un modèle mental qui clarifie le sujet. Je précise qu’il s’agit de ma synthèse, et non d’un algorithme littéral documenté par Google. Elle s’appuie sur une séance de questions-réponses de Gary Illyes, rapportée par Search Engine Roundtable : la charge de l’hôte “sets a bucket of URLs in importance order and GoogleBot will crawl in that order based on the schedule the host load decided. If Google thinks your server can handle it, it will crawl the whole bucket, if not, it will stop.” (traduction) « établit un ensemble d’URL classées par importance ; Googlebot suit cet ordre selon le calendrier décidé par la charge de l’hôte. Si le serveur peut le supporter, il parcourt tout l’ensemble ; sinon, il s’arrête. » Selon la même source, la charge suit l’importance des pages, non leur nombre brut ni le nombre souhaité. La page bloque l’extraction automatisée : cette formulation n’a pas pu être revérifiée directement lors de ce passage. Traitez-la donc comme une paraphrase secondaire bien corroborée, pas comme une citation primaire confirmée.

Une relation se dégage de cette lecture — là encore, c’est ma manière de relier les éléments, non un mécanisme intégralement décrit par Google :

• La demande fixe l’ordre. Le “bucket of URLs in importance order” (traduction) « ensemble d’URL classées par importance » représente la demande : popularité et obsolescence placent certaines URL en tête.
• La capacité fixe la profondeur atteinte. Charge de l’hôte et cadence déterminent jusqu’où Googlebot progresse un jour donné. “If your server can handle it, it crawls the whole bucket; if not, it stops.” (traduction) « Si le serveur peut le supporter, il parcourt tout l’ensemble ; sinon, il s’arrête. »

Les deux facteurs ne sont donc pas simplement multipliés : ils jouent des rôles différents. Un serveur rapide et sain ne fabrique pas de demande ; il relève seulement le plafond de demande réalisable. Une demande élevée peut rester limitée par la capacité si un serveur lent ou instable arrête Googlebot au milieu de la file. Lorsqu’un serveur plus rapide n’accélère pas l’exploration de nouvelles pages, c’est souvent parce que la capacité n’était pas la contrainte : la demande l’était.

La demande ne se règle pas directement, mais le planificateur écoute

Réponse courte : vous ne réglez pas directement la demande. Vous la gagnez indirectement grâce à de vrais liens et à des améliorations de qualité qui produisent des signaux d’indexation. Rien d’autre ne la déplace.

Il n’existe pas de requête « explorer davantage ». La demande reste cependant dynamique, et Google a expliqué son évolution. Gary Illyes déclare : “If you want to increase how much we crawl, then you somehow have to convince search that your stuff is worth fetching, which is basically what the scheduler is listening to.” (traduction) « Pour accroître notre exploration, il faut convaincre la recherche que votre contenu mérite d’être récupéré ; c’est essentiellement ce qu’écoute le planificateur. » La boucle de retour est presque immédiate : “Scheduling is very dynamic. As soon as we get the signals back from search indexing that the quality of the content has increased across this many URLs, we would just start turning up demand.” (traduction) « La planification est très dynamique. Dès que les signaux d’indexation indiquent une hausse de qualité sur de nombreuses URL, nous commençons à augmenter la demande. » À l’inverse : “If search demand goes down, then that also correlates to the crawl limit going down.” (traduction) « Si la demande de recherche baisse, la limite d’exploration baisse également. » Ces trois formulations ont été revérifiées dans la couverture de Search Engine Journal, mais pas dans l’audio ou la transcription primaire du podcast ; elles restent donc des citations secondaires bien corroborées.

Cette explication écarte les astuces. Faux horodatages lastmod, notifications de sitemap et volume de publication ne convainquent pas le planificateur. Seules comptent les deux choses difficiles : une popularité réelle grâce aux liens et de véritables améliorations de qualité visibles dans les signaux d’indexation. Le reste n’est que mise en scène.

Google cherche à explorer moins, pas plus

L’angle le plus récent, absent de nombreux guides anciens, est l’objectif déclaré de Google : réduire le volume total d’exploration. En avril 2024, Illyes écrit : “My mission this year is to figure out how to crawl even less, and have fewer bytes on wire.” (traduction) « Ma mission cette année est de trouver comment explorer encore moins et transférer moins d’octets. » Il conteste l’idée d’une chute de l’exploration : “we’re crawling roughly as much as before, however scheduling got more intelligent” (traduction) « nous explorons à peu près autant qu’avant, mais la planification est devenue plus intelligente », puis présente l’objectif comme bénéfique à tous : “Decreasing crawling without sacrificing crawl-quality would benefit everyone.” (traduction) « Réduire l’exploration sans sacrifier sa qualité profiterait à tous. » Les mécanismes évoqués sont une meilleure mise en cache, le partage du cache entre agents utilisateurs et la réduction des octets transférés, pas une hausse de l’exploration.

Conclusion : la demande n’a jamais été une grandeur à maximiser. Google optimise activement une exploration totale moindre, mais de qualité égale ou supérieure, en dirigeant la demande vers les URL les plus susceptibles de la mériter. Votre objectif n’est pas davantage de demande, mais la bonne priorisation de celle que vous avez gagnée.

Avez-vous réellement un problème de demande ?

La plupart des sites n’en ont pas et ne devraient pas consacrer une minute à ce sujet. Google écrit : “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (traduction) « Si votre site ne compte pas beaucoup de pages qui changent rapidement, ou si vos pages semblent explorées le jour même de leur publication, vous n’avez pas besoin de lire ce guide. » John Mueller s’est montré tout aussi direct sur l’échelle : d’après Search Engine Roundtable, 100k URL ne suffisent généralement pas à affecter le budget, car cela représente bien moins d’une exploration par minute sur trois mois.

Pour les sites assez grands, voici un diagnostic distinguant demande et capacité, avec une réserve : il produit une hypothèse à vérifier, pas un diagnostic. Consultez le rapport Statistiques sur l’exploration de GSC et les journaux serveur. Si l’état de l’hôte et le temps de réponse sont bons, mais qu’un groupe d’URL est rarement exploré et reste dans l’état “Discovered – currently not indexed” (traduction) « Détectée, actuellement non indexée », ce schéma pointe vers la demande sans la prouver. Les statistiques montrent l’activité d’exploration, donc une vue liée à la capacité, pas un score de demande. Aucun score public de ce type n’existe : la demande s’infère en rapprochant activité et état d’indexation.

Avant de conclure à un manque de demande, éliminez les autres causes du même symptôme : Google peut ne pas avoir découvert les URL ; le rendu peut masquer le contenu ; la canonisation peut envoyer Google ailleurs ; de vrais problèmes de qualité peuvent conduire à une exclusion volontaire de l’index ; enfin, la sélection d’indexation de Google peut écarter une page malgré une exploration et une qualité correctes. Une faible demande ne devient l’hypothèse principale qu’après ces vérifications, sans jamais constituer une cause confirmée. Un matériel plus rapide ne la corrigera pas : il faut agir sur les liens, les raisons réelles de revenir et la réduction de l’inventaire inutile.

Pour obtenir la réalité par URL, l’analyse des journaux est la bonne méthode. L’onglet Outils présente un service actuel que je connais directement.

Demande, cadence, budget et fréquence d’exploration

Gardez ces notions distinctes :

• Demande d’exploration — quantité de pages que Google souhaite explorer, selon la popularité, l’obsolescence et l’inventaire perçu. Sujet de cette page.
• Cadence d’exploration — vitesse à laquelle Google peut explorer, selon la capacité et la charge de l’hôte. Sujet d’une autre page.
• Budget d’exploration — réunion des deux : “the number of URLs Googlebot can and wants to crawl.” (traduction) « le nombre d’URL que Googlebot peut et souhaite explorer ».
• Fréquence d’exploration — périodicité de réexploration d’une URL, qui constitue un résultat de la demande, principalement lié à l’obsolescence.

Bing n’emploie pas le terme « demande d’exploration ». Il présente le sujet comme l’efficacité de l’exploration, que Fabrice Canel définit ainsi : “how often we crawl and discover new and fresh content per page crawled,” (traduction) « la fréquence à laquelle nous explorons et découvrons du contenu nouveau et récent par page explorée ». La philosophie de Bing commence par réduire l’inventaire, équivalent côté demande de l’inventaire perçu. IndexNow lui signale directement les changements au lieu d’attendre que le planificateur déduise l’obsolescence. Google n’utilise pas IndexNow : ce protocole ne modifie donc pas sa demande.

Résumé par l’IA

Version condensée de l’onglet Avancé :

• La demande correspond à l’intention d’explorer ; la cadence ou capacité représente la possibilité technique. Le budget réunit les deux dans la définition “number of URLs Googlebot can and wants to crawl” (traduction) « nombre d’URL que Googlebot peut et souhaite explorer ».
• Facteurs importants, sans formule fermée : popularité (liens et PageRank), obsolescence (fréquence des changements) et inventaire perçu (URL que Google pense trouver, y compris les inutiles), auxquels s’ajoutent taille du site, fréquence de mise à jour, qualité des pages et pertinence comparative.
• Les migrations augmentent temporairement la demande pendant le retraitement sous les nouvelles URL.
• Modèle demande-capacité — ma synthèse, pas un algorithme Google documenté : la demande fixe l’ordre de priorité ; la capacité liée à l’hôte fixe la profondeur atteinte. Un serveur rapide ne crée pas de demande, et une demande élevée peut être limitée par la capacité.
• La demande ne se règle pas directement. Le planificateur l’augmente lorsque les signaux de qualité issus de l’indexation progressent. Les vrais leviers sont les liens et des améliorations réelles de qualité et de fraîcheur ; faux lastmod, notifications de sitemap et volume de publication ne fonctionnent pas.
• Google cherche à explorer moins, pas plus, tout en dirigeant la demande avec davantage de précision. L’objectif est la bonne priorisation, non le volume.
• Diagnostic : hôte sain, faible activité et état “Discovered – currently not indexed” (traduction) « Détectée, actuellement non indexée » forment une hypothèse de demande, pas une preuve. Écartez d’abord découverte, rendu, canonisation et sélection d’indexation. Aucun score public de demande n’existe.
• Bing parle d’efficacité de l’exploration ; IndexNow signale les changements à Bing, pas à Google. La plupart des sites n’ont rien à gérer.

Documentation officielle

Documentation de première main fournie par les moteurs de recherche.

Google

• Optimiser votre budget d’exploration — définit la demande, ses trois principaux facteurs et les pics liés aux migrations.
• Gestion du budget d’exploration — distingue capacité et demande et décrit le plafond auquel la demande se heurte.
• Ce que signifie le budget d’exploration pour Googlebot (2017) — billet original de Gary Illyes définissant le budget comme ce que Googlebot « peut et souhaite explorer » et recensant les URL de faible valeur.
• Mythes et réalités de l’exploration — confirme que la cadence n’est pas un signal de classement et que la santé du serveur fixe le plafond de capacité.
• Série de décembre sur l’exploration (2024) — Googlebot, cache HTTP, navigation à facettes et recherche d’une exploration plus efficace.

Bing / Microsoft

• Série bingbot : maximiser l’efficacité de l’exploration — présentation par Bing de l’équivalent côté demande.
• Série bingbot : optimiser la fréquence d’exploration — cadence fondée sur la fréquence de changement du contenu, analogue à l’obsolescence.
• IndexNow / indexnow.org — signalement des URL modifiées à Bing et à d’autres moteurs, mais pas à Google.

Citations des sources

Déclarations officielles de Google et Bing. Chaque lien mène directement au passage cité.

Google — définition et facteurs de la demande

• “The amount of time and resources that Google devotes to crawling a site is commonly called the site’s crawl budget and it’s determined by two main elements: crawl capacity limit and crawl demand.” (traduction) « Le temps et les ressources que Google consacre à l’exploration d’un site constituent son budget, déterminé par la limite de capacité et la demande. » — Guide des grands sites sur la gestion du budget d’exploration. Accéder à la citation
• “Each crawler has its own ‘demand’ when it comes to crawling the web.” (traduction) « Chaque robot possède sa propre demande lorsqu’il explore le Web. » Accéder à la citation
• “URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems.” (traduction) « Les URL plus populaires sur Internet sont généralement explorées plus souvent pour rester à jour dans nos systèmes. » (popularité) Accéder à la citation
• “Our systems want to recrawl documents frequently enough to pick up any changes.” (traduction) « Nos systèmes souhaitent réexplorer les documents assez souvent pour détecter les changements. » (obsolescence) Accéder à la citation

Google — inventaire perçu et migrations

• “If many of these URLs are duplicates, or you don’t want them crawled for some other reason (removed, unimportant, and so on), this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.” (traduction) « Des doublons et des URL sans intérêt consomment inutilement le temps d’exploration de Google ; la composition de cet inventaire reste le levier le plus directement contrôlable. » Accéder à la citation
• “Additionally, site-wide events like site moves may trigger an increase in crawl demand in order to reprocess the content under the new URLs.” (traduction) « Des événements globaux comme une migration peuvent accroître la demande afin de retraiter le contenu sous les nouvelles URL. » Accéder à la citation
• “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (traduction) « Si votre site ne compte pas beaucoup de pages qui changent rapidement, ou si elles sont explorées le jour de leur publication, vous n’avez pas besoin de lire ce guide. » Accéder à la citation

Gary Illyes, Google — évolution réelle de la demande (citations issues de la couverture par Search Engine Journal de son passage dans un podcast)

• “If you want to increase how much we crawl, then you somehow have to convince search that your stuff is worth fetching, which is basically what the scheduler is listening to.” (traduction) « Pour accroître notre exploration, il faut convaincre la recherche que votre contenu mérite d’être récupéré ; c’est ce qu’écoute le planificateur. » Lire l’article
• “Scheduling is very dynamic. As soon as we get the signals back from search indexing that the quality of the content has increased across this many URLs, we would just start turning up demand.” (traduction) « Le calendrier réagit rapidement : lorsque l’indexation renvoie des signaux de meilleure qualité sur un grand ensemble d’URL, Google relève la demande. » Lire l’article
• “If search demand goes down, then that also correlates to the crawl limit going down.” (traduction) « Si la demande de recherche baisse, la limite d’exploration baisse également. » Lire l’article

Gary Illyes, Google — mission d’« explorer encore moins » (LinkedIn, avril 2024 — source primaire, vérifiée mot pour mot)

• “My mission this year is to figure out how to crawl even less, and have fewer bytes on wire.” (traduction) « Ma mission cette année est de trouver comment explorer encore moins et transférer moins d’octets. » Lire la publication
• “we’re crawling roughly as much as before, however scheduling got more intelligent” (traduction) « nous explorons à peu près autant qu’avant, mais la planification est devenue plus intelligente » et “Decreasing crawling without sacrificing crawl-quality would benefit everyone.” (traduction) « Réduire l’exploration sans sacrifier sa qualité profiterait à tous. » Lire la publication

Bing / Microsoft — efficacité de l’exploration, analogue côté demande

• “The crawl efficiency is how often we crawl and discover new and fresh content per page crawled.” (traduction) « L’efficacité de l’exploration est la fréquence à laquelle nous explorons et découvrons du contenu nouveau et récent par page explorée. » — Fabrice Canel. Accéder à la citation

S’agit-il d’un problème de demande — et devez-vous vous en préoccuper ?

Suivez l’arbre de haut en bas. Pour la plupart des sites, la réponse arrive vite : ne changez rien.

Mythes et erreurs sur la demande d’exploration

Ces confusions conduisent au mauvais diagnostic.

« Demande et budget d’exploration désignent la même chose. » Pourquoi c’est faux : la demande n’est qu’une des deux composantes ; le budget réunit capacité et demande, soit “the number of URLs Googlebot can and wants to crawl.” (traduction) « le nombre d’URL que Googlebot peut et souhaite explorer ». À faire : distinguer les termes. Le budget est le résultat ; demande et capacité sont ses deux facteurs. Un problème de budget est donc un problème de demande, de capacité ou des deux.

« Un serveur plus rapide augmente la demande. » Pourquoi c’est faux : sa vitesse relève seulement le plafond de capacité. Elle permet de satisfaire davantage la demande existante, sans donner à Google davantage envie d’explorer. Popularité, obsolescence et inventaire perçu ne dépendent pas du matériel. À faire : si les pages restent peu explorées malgré un serveur sain, cessez d’acheter du matériel et travaillez sur les liens, la fraîcheur et la réduction de l’inventaire inutile.

« Publier plus souvent augmente la demande. » Pourquoi c’est faux : le volume sans importance ni changement réel ne convainc pas le planificateur. Dix articles superficiels par jour sans aucun lien ne changent rien. À faire : publier des contenus qui gagnent des liens et s’améliorent réellement ; ce sont eux qui alimentent les signaux de qualité. Ce point concerne aussi la fréquence d’exploration, détaillée ailleurs.

« Bloquer les URL inutiles dans robots.txt redirige immédiatement la demande vers mes bonnes pages. » Pourquoi c’est faux : réduire l’inventaire perçu aide la demande à se concentrer lorsque Google réévalue le site, mais ne provoque aucune réaffectation instantanée. Les récupérations libérées ne sont pas automatiquement versées sur les bonnes pages dès l’ajout d’une interdiction. À faire : réduire durablement l’inventaire inutile et patienter. C’est une tendance, pas un interrupteur.

« Search Console affiche un score de demande d’exploration. » Pourquoi c’est faux : aucun score public par site n’existe. Les statistiques montrent l’activité d’exploration, une vue liée à la capacité, non une mesure de demande. À faire : inférer la demande en rapprochant activité et état d’indexation. Un hôte sain, une faible activité et l’état “Discovered – currently not indexed” (traduction) « Détectée, actuellement non indexée » constituent un signal. Les journaux fournissent la réalité par URL.

« IndexNow ou les notifications de sitemap augmentent la demande de Google. » Pourquoi c’est faux : Google n’utilise pas IndexNow et ignore changefreq/priority dans les sitemaps. Une notification ne lui donne pas davantage envie d’explorer. À faire : utiliser IndexNow pour Bing et les moteurs participants. Pour Google, un lastmod exact facilite la planification, mais les leviers restent liens, fraîcheur et inventaire.

« Davantage d’exploration est toujours préférable, pour moi comme pour Google. » Pourquoi c’est faux : une exploration accrue n’améliore pas le classement, et Google cherche lui-même à explorer moins : “My mission this year is to figure out how to crawl even less, and have fewer bytes on wire” (traduction) « Ma mission cette année est de trouver comment explorer encore moins et transférer moins d’octets », tout en orientant la demande plus précisément. À faire : viser la bonne priorisation, non le volume brut. La demande disponible doit atteindre les bonnes URL.

Procédure : « Google n’explore pas mes pages importantes, mais mon serveur fonctionne bien »

Parcours linéaire destiné au responsable d’un grand site qui soupçonne un problème de demande. Arrêtez dès qu’une étape résout le problème.

1. Vérifier que le site est assez grand pour s’en préoccuper. Si les pages sont généralement explorées le jour de leur publication ou si le site est de taille normale, arrêtez : il n’existe pas de problème de demande. Cette procédure vise les sites de plus de 1M de pages, ceux qui changent rapidement ou ceux possédant un grand nombre d’URL “Discovered – currently not indexed” (traduction) « Détectées, actuellement non indexées ».

2. Écarter d’abord la capacité. Ouvrez les statistiques d’exploration de GSC. Vérifiez l’état de l’hôte et le temps de réponse moyen sur 90 jours. Des pics 5xx, des délais d’attente ou une hausse des temps de réponse signalent un problème de capacité. Corrigez le serveur, puis recommencez cette procédure. Si le serveur est sain, continuez.

3. Extraire la réalité par URL depuis les journaux. Récupérez les journaux serveur ou un flux d’analyse des robots pour le groupe concerné. Confirmez que les véritables visites de Googlebot sont rares sur les pages utiles, tandis que les paramètres et URL inutiles consomment les requêtes. Sur un serveur sain, cette rareté forme une hypothèse de demande, pas une cause confirmée. Écartez d’abord les explications concurrentes : URL non découverte, échec de rendu, canonisation vers une autre page, problème réel de qualité ou de duplication, choix de sélection d’indexation. Utilisez l’inspection d’URL et le HTML rendu dans Search Console.

4. Rechercher un gonflement de l’inventaire perçu. Comptez les URL de faible valeur que Google peut découvrir : combinaisons de navigation à facettes, identifiants de session, paramètres de tri et de filtre, calendriers ou espaces infinis, doublons internes. Si elles dépassent largement les pages utiles, la demande est probablement dispersée.

5. Réduire l’inventaire inutile. Supprimez les espaces d’URL de faible valeur à la source : gestion des paramètres, interdiction dans robots.txt des espaces infinis, correction des pièges à robots et regroupement des doublons par canonisation. Attendez une concentration progressive, non une réaffectation immédiate.

6. Travailler la popularité. Ajoutez depuis les pages fortes des liens internes vers celles qui sont peu explorées, éliminez les pages orphelines et recherchez des liens externes. La popularité est un facteur principal de demande.

7. Travailler la qualité et la fraîcheur. Améliorez et actualisez réellement les pages afin que les signaux issus de l’indexation indiquent au planificateur d’augmenter la demande. Un lastmod exact facilite la planification ; une fraîcheur artificielle ne sert à rien.

8. Attendre, puis mesurer à nouveau. Une fois que Google a pu réévaluer le site, consultez de nouveau statistiques et journaux. Les changements de demande sont progressifs. Si exploration et indexation reprennent, le problème est résolu. Sinon, demandez-vous si les pages méritent réellement d’être explorées : parfois, la réponse honnête est non, et des pages superficielles ne doivent pas être forcées dans l’index.

Liste de contrôle de la demande d’exploration

Diagnostic : demande ou capacité ?

• Confirmer que le site est réellement assez grand ou change assez vite pour justifier cette analyse.
• Dans les statistiques d’exploration de GSC : état de l’hôte sain, temps de réponse moyen stable, aucun pic 5xx ni délai d’attente.
• Examiner les journaux serveur ou l’analyse des robots pour connaître les visites réelles de Googlebot par URL.
• Identifier le schéma : serveur sain, faible exploration des bonnes pages et état “Discovered – currently not indexed” (traduction) « Détectée, actuellement non indexée » forment une hypothèse de demande, pas une preuve ni un problème de capacité.
• Écarter les causes similaires : découverte, rendu, canonisation, qualité ou duplication et sélection d’indexation.

Agir sur les facteurs de demande — aucun réglage direct n’existe

• Popularité : les pages importantes reçoivent des liens internes, ne sont pas orphelines et bénéficient d’un travail de liens externes lorsque nécessaire.
• Obsolescence et fraîcheur : les pages qui doivent être souvent réexplorées sont réellement mises à jour ; lastmod est exact et non artificiel.
• Inventaire perçu : navigation à facettes, paramètres, identifiants de session et espaces infinis sont maîtrisés ; les pièges sont corrigés et les doublons regroupés.

Vérifications de réalité

• Ne pas attendre d’un serveur plus rapide qu’il augmente la demande : il relève seulement le plafond de capacité.
• Ne pas attendre de l’interdiction des URL inutiles dans robots.txt qu’elle redirige instantanément la demande : la concentration est progressive.
• Ne pas compter sur IndexNow ou les notifications de sitemap pour modifier la demande de Google : il ignore IndexNow et changefreq/priority.
• Après une migration, considérer le pic temporaire comme normal.
• Se rappeler que l’objectif n’est pas davantage d’exploration, mais la bonne priorisation ; le volume n’est pas un facteur de classement.

Demande d’exploration — aide-mémoire

Les deux dimensions du budget d’exploration

Les trois facteurs les plus actionnables — Google cite également la taille du site, la fréquence de mise à jour, la qualité des pages et la pertinence comparative comme facteurs généraux importants, sans proposer de formule fermée.

Repères rapides

• Le budget réunit les URL que Googlebot est techniquement capable de récupérer et celles qu’il juge utile de visiter : “number of URLs Googlebot can and wants to crawl” (traduction) « nombre d’URL que Googlebot peut et souhaite explorer ».
• L’inventaire perçu est “the factor you can positively control the most” (traduction) « le facteur que vous pouvez le mieux maîtriser ».
• Les migrations de site augmentent temporairement la demande pendant le retraitement sous les nouvelles URL.
• La demande fixe l’ordre de priorité ; la capacité liée à l’hôte fixe la profondeur atteinte. Un serveur sain ne crée pas de demande.
• Le planificateur augmente la demande lorsque les signaux de qualité de l’indexation progressent ; avec les liens, c’est le seul véritable levier.
• Google cherche à explorer moins au total, pas plus. Le volume n’est pas un facteur de classement.
• Aucun score public de demande n’existe ; les statistiques d’exploration montrent l’activité, côté capacité.
• Bing parle d’efficacité de l’exploration ; IndexNow lui signale un changement, mais ne le signale pas à Google.

Outils pour diagnostiquer la demande

Il n’existe aucun « compteur de demande ». Le diagnostic consiste donc à lire l’activité d’exploration et à la comparer aux caractéristiques connues des pages.

• Google Search Console — rapport Statistiques sur l’exploration — requêtes dans le temps, état de l’hôte, temps de réponse moyen et répartitions par code, type de fichier, objet et type de Googlebot. Lisez-le comme une vue de la capacité : un hôte sain avec une faible activité sur de bonnes pages signale un possible manque de demande.
• GSC — rapport Indexation des pages — la catégorie “Discovered – currently not indexed” (traduction) « Détectée, actuellement non indexée » est l’empreinte classique d’un déficit de demande : Google connaît les URL, mais ne souhaite pas encore assez les explorer.
• Inspection d’URL dans GSC — indique la dernière exploration et l’état d’indexation d’une URL précise.
• Analyse des journaux serveur — réalité des visites de Googlebot par URL : pages récupérées, fréquence et gaspillage sur l’inventaire inutile.
• Ahrefs Bot Analytics — outil que je connais directement. Lors de son lancement, je l’ai décrit ainsi : “Have y’all checked out Bot Analytics in Ahrefs yet? We released a new tool that shows how bots crawl your website. Bot Analytics collects data server-side via Cloudflare integration.” (traduction) « Avez-vous testé Bot Analytics dans Ahrefs ? Ce nouvel outil montre comment les robots explorent votre site et collecte les données côté serveur grâce à Cloudflare. » Il affiche tous les robots et leurs pages dans 12 catégories, soit la réalité par robot et par URL nécessaire pour confronter l’inventaire perçu et la popularité aux faits. Ahrefs résume le problème : “uncontrolled bot traffic wastes crawl budget — bots crawling 404 pages or low-value URLs aren’t crawling the pages you need indexed,” (traduction) « un trafic de robots non maîtrisé gaspille le budget : ceux qui explorent des pages 404 ou de faible valeur n’explorent pas les pages à indexer », et estime que plus de la moitié du trafic des robots constitue un effort gaspillé.
• Ahrefs Site Audit / Screaming Frog SEO Spider — simulent une exploration pour détecter prolifération de paramètres, doublons et pièges qui gonflent l’inventaire perçu et réduisent la demande.

Cadre importance × changement × inventaire

Posez trois questions pour expliquer une évolution de la demande :

1. Importance : des signaux internes ou externes ont-ils rendu l’URL plus ou moins importante ?
2. Changement : la page a-t-elle réellement évolué et les signaux sincères du sitemap l’ont-ils indiqué ?
3. Inventaire : l’ensemble de doublons, paramètres ou URL de faible valeur connu du robot s’est-il agrandi ?

La santé de l’hôte constitue le plafond, pas un quatrième facteur de demande. Si les journaux montrent des erreurs ou délais d’attente, diagnostiquez séparément la capacité. Si le serveur est sain, mais que les URL utiles perdent de leur part d’exploration, examinez importance, changement et inventaire dans cet ordre.

Comparer la part d’exploration par répertoire

Cette chaîne de commandes shell résume les requêtes vérifiées d’un robot par premier répertoire de chemin dans un journal d’accès courant :

awk 'BEGIN{IGNORECASE=1} /Googlebot/ {split($7,p,"/"); print "/" p[2] "/"}' access.log | sort | uniq -c | sort -nr

Sous PowerShell :

Select-String .\access.log -Pattern 'Googlebot' | ForEach-Object { if ($_.Line -match '"(?:GET|HEAD)\s+https?://[^/]+/([^/?\s]*)|"(?:GET|HEAD)\s+/([^/?\s]*)') { '/' + (($Matches[1],$Matches[2] | Where-Object { $_ })[0]) + '/' } } | Group-Object | Sort-Object Count -Descending

Comparez des périodes de même durée avant et après une modification. Une hausse de part pour un répertoire donne un indice sur l’allocation du planificateur, mais ne prouve ni une meilleure qualité ni de meilleurs classements.

Mesures de la demande d’exploration

Part d’exploration des modèles utiles

Mesure : requêtes du robot vers les modèles importants divisées par toutes ses requêtes vérifiées. Interprétation : indique si la demande atteint l’inventaire utile. Collecte : classer les URL des journaux d’accès par modèle. Référence réaliste : définir la répartition souhaitée d’après votre propre inventaire utile et sa cadence de mise à jour ; aucun pourcentage universel n’existe. Fréquence : chaque semaine pour les grands sites changeants, sinon chaque mois.

Délai de réexploration après un changement important

Mesure : temps entre une véritable mise à jour de page et la récupération vérifiée suivante. Interprétation : indique si le planificateur reconnaît l’importance et le rythme de changement de la page. Collecte : rapprocher les horodatages de déploiement ou de contenu des journaux d’accès. Référence réaliste : établir une base par modèle ; actualités et pages de référence stables ne doivent pas partager le même objectif. Fréquence : mensuelle.

Part de l’inventaire de faible valeur

Mesure : URL connues et explorées qui sont paramétrées, dupliquées, vides ou assimilables à des erreurs 404 logicielles, rapportées aux URL utiles. Interprétation : indique si l’inventaire perçu dilue l’attention. Collecte : combiner exports d’exploration, sitemaps, règles d’indexabilité et journaux. Référence réaliste : viser une baisse par rapport à la base du site sans bloquer les ressources nécessaires. Fréquence : mensuelle et après tout changement de navigation à facettes ou de plateforme.

Ressources utiles

Mes articles connexes

• Quand faut-il se préoccuper du budget d’exploration ? — ma présentation du budget comme demande, soit le nombre de pages souhaité, plus cadence, avec popularité, recul lié à l’obsolescence et sites réellement concernés.
• Qu’est-ce que Googlebot et comment fonctionne-t-il ? — manière dont Googlebot décide quoi explorer et en quelle quantité.
• Guide du débutant en SEO technique — place de l’exploration et de son budget dans l’ensemble du SEO technique.

Mes conférences

• How Search Works (SlideShare) — présentation de l’exploration, des facteurs de demande et du plafond distinct de capacité lié à l’hôte. Avertissement permanent : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) « Ceci reflète ma compréhension des systèmes et ne sera pas complet ou exact à 100 %. »

Dans le secteur

• Priorités d’exploration de Google : éclairages de Gary Illyes (Search Engine Journal) — citations sur la valeur à récupérer, l’augmentation de la demande et sa baisse.
• Gary Illyes sur une exploration encore moindre (LinkedIn, avril 2024) — source primaire pour “crawl even less… fewer bytes on wire” (traduction) « explorer encore moins… transférer moins d’octets » et “scheduling got more intelligent” (traduction) « la planification est devenue plus intelligente ».
• Deux types d’exploration Google : découverte et actualisation (Search Engine Journal) — John Mueller sur découverte et actualisation ; la cadence d’actualisation est un résultat pur de la demande.
• Gary Illyes sur budget, planification et charge de l’hôte (Search Engine Roundtable) — modèle de l’ensemble d’URL par importance, paraphrasé dans cet article ; à confirmer sur la page vivante.
• Google : 100k URL n’affectent pas le budget (Search Engine Roundtable) — repère d’échelle de John Mueller, paraphrasé ici et à confirmer sur la page vivante.
• Qu’est-ce que le budget d’exploration ? Fonctionnement et optimisation (Search Engine Land) — guide complet utile sur les trois facteurs.
• Ahrefs Bot Analytics — page du produit présentant le gaspillage provoqué par les robots et l’estimation selon laquelle plus de la moitié de leur trafic est inutile.

Testez vos connaissances : demande d’exploration

Cinq questions rapides sur le côté « vouloir » du budget. Choisissez une réponse, puis vérifiez-la.

Journal des modifications