Guide complet du crawl budget et de son optimisation

Crawl budget : la vraie raison pourquoi Google ignore vos pages

Un client m'appelle un mardi matin, paniqué. Sa boutique en ligne compte 180 000 URL. Google en indexe 4 000. Pas parce que le contenu est mauvais. Pas parce qu'il y a une pénalité. Simplement parce que Googlebot passe, regarde, et repart en ayant exploré des milliers de pages de filtres à facettes qui ne mènent nulle part.

Le crawl budget, c'est exactement ça : la quantité de pages que Google accepte d'explorer sur votre site dans un temps donné. Et quand il est mal géré, ce ne sont pas vos pages médiocres qui souffrent — ce sont vos meilleures.

J'ai passé des mois à auditer ce genre de situation. Franchement, au début, je ne comprenais pas pourquoi mes recommandations de contenu ne changeaient rien. Le problème n'était pas le contenu. Le problème était que Google ne le voyait jamais.

Comprendre le crawl budget sans se perdre dans la théorie

La plupart des articles sur le sujet répètent la même définition. Je vais tenter autre chose : vous expliquer pourquoi ça fonctionne comme ça, parce que sans ça, les actions concrètes ne tiennent pas debout.

Les deux freins qui se combinent

Google explore votre site sous deux contraintes simultanées.

La première est technique. Vos serveurs ont une capacité limitée. Si Googlebot envoie 50 requêtes par seconde sur un hébergement mutualisé, le site tombe. Google le sait, il adapte la cadence. C'est le crawl rate limit.

La seconde est une question d'envie. Google explore en priorité ce qui lui semble utile : contenu frais, pages populaires, sites bien structurés. C'est le crawl demand. Vous ne le contrôlez pas directement, mais vous l'influencez par la qualité, la fraîcheur, le maillage interne.

Le budget réel est le plus petit des deux. Si votre serveur répond lentement, c'est lui qui décide. Si Google se désintéresse, c'est lui qui tranche. Et là, surprise : beaucoup de gens optimisent le premier alors que le second est le vrai problème.

Qui est réellement concerné

Question qu'on me pose souvent : « Mon site fait 800 pages, je dois m'en occuper ? » Non.

Le crawl budget devient un sujet quand trois conditions se cumulent :

• Un volume de pages qui se compte en dizaines de milliers
• Une mise à jour fréquente, qui oblige Google à revenir souvent
• Beaucoup de pages générées automatiquement, souvent sans valeur

Si vous êtes un cabinet d'avocats avec 40 pages, vous pouvez fermer cet onglet. Sérieusement. Votre énergie sera mieux investie ailleurs.

Budget de crawl et budget d'indexation : deux choses différentes

Confusion fréquente, et elle coûte cher. Le budget de crawl, c'est la visite. Le budget d'indexation, c'est la décision de garder la page dans l'index une fois visitée.

Vous pouvez très bien avoir un crawl budget parfaitement optimisé et des milliers de pages qui restent en « Explorée, actuellement non indexée ». C'est un signal, pas un échec. Google a vu la page, il l'a jugée inutile à ses yeux. Le problème est alors qualitatif, pas technique.

Distinguer les deux vous évite de perdre des semaines à optimiser le mauvais levier.

Comment auditer son crawl budget pour de vrai

Voici la partie qui manque partout ailleurs. Les gens expliquent le concept, jamais la méthode. Je vais vous donner la mienne, celle que j'applique à chaque mission.

Partir des logs serveur, pas de la Search Console

La Search Console vous donne le rapport « Statistiques d'exploration ». Il est utile. Il est aussi insuffisant : Google y agrège les données, vous perdez le détail.

Les logs serveur, c'est brut. Chaque requête, chaque URL, chaque code de réponse, chaque user-agent. Vous savez exactement ce que Googlebot a demandé.

Ce que je fais systématiquement :

1. Filtrer les lignes où l'user-agent contient « Googlebot » (attention, il y a aussi Googlebot-Image, Googlebot-News, etc.)
2. Segmenter par code HTTP : les 200, les 301, les 404, les 5xx
3. Regrouper par type de page : produits, catégories, filtres, blog, pagination
4. Comparer avec la liste des URL que vous jugez stratégiques

Le résultat est brutal. Sur un site que j'ai audité l'an dernier, 61 % des requêtes de Googlebot finissaient sur des pages de paramètres à facettes. Ma cliente pensait que Google ne « comprenait pas » son contenu. Google ne le voyait simplement pas.

Les signaux qui doivent vous alerter

Trois chiffres à surveiller dans vos logs.

• Trop de 3xx : au-delà de 5 % des requêtes redirigées, vous gaspillez. Les chaînes de redirections sont du carburant brûlé pour rien.
• Beaucoup de 404 : Google continue à venir sur des URL mortes. Il faut le lui dire clairement, pas espérer qu'il comprenne tout seul.
• Une faible part sur les pages stratégiques : si vos meilleures pages ne reçoivent que 10 % des visites, votre budget part ailleurs.

À l'inverse, un site où Googlebot passe 70 % de son temps sur des pages utiles est un site en bonne santé, même si le volume total baisse.

Ce que je mesure avant et après

Un audit sans mesure de départ ne sert à rien. Avant toute action, je note sur 30 jours glissants :

Indicateur	Ce qu'il révèle	Signal d'alerte
Nombre de requêtes Googlebot/jour	Volume global d'exploration	Chute brutale sans raison
Part des requêtes sur pages stratégiques	Qualité du budget	En dessous de 30 %
Taux de codes 3xx	Redirections inutiles	Au-dessus de 5 %
Taux de 5xx	Santé serveur	Tout pic, même bref
Délai de réponse moyen	Capacité du serveur	Au-dessus de 500 ms

Ces cinq lignes suffisent à savoir où vous en êtes. Le reste, c'est du diagnostic fin.

Les leviers techniques qui changent vraiment la donnée

Bon, entrons dans le concret. Ce sont les actions qui, d'expérience, produisent un effet mesurable.

Maîtriser les paramètres d'URL

C'est la cause numéro un de gaspillage sur les sites e-commerce. Les filtres à facettes génèrent des combinaisons quasi infinies : couleur × taille × prix × marque. Google peut explorer des millions d'URL qui affichent les mêmes 12 produits dans un ordre différent.

Trois approches, du plus simple au plus fin :

• Bloquer les paramètres inutiles dans robots.txt via des motifs (attention aux faux positifs, c'est le piège classique)
• Ajouter une balise canonical vers la catégorie parente quand le filtre n'a pas de valeur propre
• Ne garder indexables que les filtres qui correspondent à une requête réelle

J'ai vu des sites passer de 22 % à 48 % de budget utile sur les pages produits juste en traitant ce point. Sans toucher au contenu.

Robots.txt n'est pas la même chose que noindex

Erreur que je vois encore trop souvent. Bloquer une URL dans robots.txt empêche l'exploration. Mais si Google ne peut pas explorer la page, il ne peut pas lire la balise noindex qu'elle contient. Résultat : la page peut rester indexée sans contenu, ou pire, générer de la confusion.

La règle est simple, même si elle paraît contre-intuitive : pour désindexer, laissez Google accéder à la page et mettez un noindex. Pour économiser du budget sur des pages sans valeur, utilisez robots.txt — en acceptant qu'elles restent visibles dans les résultats tant que Google ne les a pas revisitées.

Choisir entre les deux dépend de votre objectif : économiser ou faire disparaître. Rarement les deux à la fois.

Nettoyer les redirections en chaîne

Une redirection qui pointe vers une autre redirection, qui pointe vers une 404. Le robot suit tout ça, une visite par étape, et n'arrive jamais au contenu. Du budget pur perdu.

Je fais un crawl complet avec un outil type Screaming Frog ou Sitebulb, je sors la liste des chaînes, et je les aplatit : A pointe directement vers la destination finale. Sur un site de 40 000 URL, ça représente souvent 2 000 à 4 000 requêtes par jour récupérées.

Pas spectaculaire en pourcentage. Beaucoup en volume.

Le rendu JavaScript et le budget caché

Angle absent de la plupart des guides, et pourtant décisif. Depuis plusieurs années, Google exécute le JavaScript avant d'indexer. Mais cette exécution passe par une file d'attente séparée. Une page qui a besoin d'un rendu complet peut attendre des jours, voire des semaines, avant d'être traitée.

Concrètement : un site entièrement rendu côté client peut voir ses pages explorées, mises en file, et jamais rendues. Le crawl budget est consommé, l'indexation n'arrive pas.

Deux solutions :

• Rendu côté serveur pour les pages critiques
• Pré-rendu statique pour les pages stables

Franchement, si votre site dépend du rendu client pour afficher le contenu principal, vous vous tirez une balle dans le pied. Ce n'est pas une opinion, c'est ce que les logs racontent.

Budget crawl et sites à fort renouvellement : le cas particulier

Les sites d'actualité et les marketplaces ont un problème différent. Leurs pages ont une durée de vie courte. Si Google ne vient pas dans les heures qui suivent la publication, l'article est déjà obsolète.

Le crawl demand devient alors le seul levier réel. Impossible d'attendre : il faut que Google ait envie de revenir vite.

Ce qui fait revenir Google vite

Trois choses, dans l'ordre d'importance :

1. La fraîcheur perçue du site. Un site qui publie tous les jours est visité tous les jours.
2. Les liens internes depuis les pages les plus populaires vers les nouvelles pages.
3. Un sitemap d'actualités correctement tenu, avec des lastmod honnêtes.

Il y a quelques mois, une cliente de presse locale m'appelle. Ses articles ne sont plus indexés dans les 48 heures. J'ouvre la Search Console, puis les logs. Les nouvelles URL mettaient en moyenne 9 jours à recevoir une visite de Googlebot. Le sitemap avait des lastmod datés de trois ans, identiques pour toutes les pages.

Correction du sitemap, ajout de blocs « à la une » liés depuis la page d'accueil, mise en place d'un flux d'actualités propre. Trois semaines plus tard, le délai moyen tombait à moins de 6 heures. Pas de contenu changé. Juste la mécanique.

Le piège de la pagination

Une pagination mal gérée, c'est un puits sans fond. Chaque page numérotée est une URL, souvent avec peu de contenu unique. Google va les explorer, encore et encore, sans valeur ajoutée.

Aujourd'hui, la pagination classique reste acceptable si elle est propre. Une URL, un canonical propre, pas de paramètres qui s'empilent. Le rendu « charger plus » est souvent préférable pour l'utilisateur, mais plus risqué pour le crawl : si le contenu n'est accessible que par interaction, il peut ne jamais être exploré.

Mesurer les gains : ce qui marche, ce qui ne marche pas

Le problème avec ce sujet, c'est qu'on lit partout des promesses de « +45 % » sans savoir ce qu'elles mesurent. Voici ce que j'observe dans mes propres suivis.

Ce qui produit un effet visible

Sur les sites que j'ai optimisés, les gains les plus nets viennent de deux endroits :

• Le traitement des paramètres d'URL : la part de budget utile remonte typiquement de 15 à 30 points en quatre à six semaines
• La suppression des redirections en chaîne : effet immédiat sur le temps de réponse serveur, plus progressif sur le volume exploré

À l'inverse, jouer sur le crawl-delay dans robots.txt n'a quasiment aucun effet sur Google. Bing le respecte, Google l'ignore depuis longtemps. Ne perdez pas de temps avec ça, sauf si vous ciblez d'autres moteurs.

Ce qui ne marche pas

J'ai essayé, je l'admets volontiers :

1. Bloquer massivement dans robots.txt pour « obliger Google à revenir » — contre-productif, Google se désintéresse
2. Multiplier les sitemaps en espérant un signal — Google explore le sitemap, il ne l'utilise pas comme priorité
3. Ajouter des balises priority dans le sitemap — ignoré depuis des années

J'ai perdu plusieurs semaines sur ce troisième point, persuadé que ça marchait. Spoiler : non.

Ce qu'il faut retenir

Le crawl budget n'est pas un bouton qu'on active. C'est un équilibre entre ce que votre serveur supporte et ce que Google juge utile. Quand on le traite bien, ce ne sont pas les visites qui augmentent — c'est la qualité de ce qui est visité.

Et si vous devez retenir une seule chose : mesurez avant d'agir. Sans logs serveur, vous naviguez à l'aveugle. Avec, vous voyez exactement où part le carburant.

La vraie question n'est pas « comment attirer plus de Googlebot », mais « pourquoi perd-il son temps chez vous ». Répondre à celle-là change tout le reste.