Comment corriger les erreurs de crawl budget sur un site

Vous ouvrez le rapport « Statistiques d'exploration » dans la Search Console, et vous voyez cette courbe qui stagne. Googlebot passe, mais il ne descend pas assez profond. Pendant ce temps, des dizaines de pages que vous jugez importantes moisissent dans un coin de l'index, explorées une fois tous les deux mois. J'ai connu ça sur un site e-commerce à 40 000 URL : 12 000 pages jamais explorées, et un chiffre d'affaires qui plafonnait.

Corriger les erreurs de crawl budget, ce n'est pas un réglage magique. C'est un travail de nettoyage, souvent ingrat, qui consiste à reprendre le contrôle de ce que Googlebot dépense comme énergie sur votre domaine. Et la bonne nouvelle, c'est que 80 % des problèmes viennent de trois ou quatre causes qu'on peut identifier en une après-midi.

Comment corriger les erreurs de crawl budget sans y passer des mois

La première chose que je dis à quiconque me demande d'où vient le problème : arrêtez de vouloir tout optimiser en même temps. Le crawl budget, c'est une ressource finie. Chaque seconde que Googlebot passe sur une URL inutile est une seconde qu'il ne passe pas sur une page qui compte.

Donc on ne « corrige » pas le crawl budget dans l'abstrait. On corrige des erreurs précises qui consomment ce budget à votre place.

Les erreurs qui coûtent réellement cher

Les 404 isolées, tout le monde s'en fiche, y compris Google. Le vrai problème, c'est le régime de croisière :

• Des liens internes qui pointent vers des pages supprimées depuis deux ans, en pagination, dans le footer, dans les menus déroulants. Googlebot les suit à chaque passage.
• Des redirections en chaîne à trois, quatre, cinq sauts. Chaque saut est une requête consommée. J'ai vu un site où 3 200 URL passaient par une chaîne de quatre redirections avant d'arriver à la bonne page.
• Des paramètres d'URL infinis : tri, filtres à facettes, sessions. Un catalogue de 5 000 produits peut générer des centaines de milliers d'URL si personne ne cadre les paramètres. C'est le scénario classique du site e-commerce qui se plaint que sa catégorie phare ne remonte plus.
• Les erreurs 5xx en rafale, qui font baisser le crawl rate limit pendant des semaines. Google n'oublie pas qu'un serveur l'a mal reçu.

Franchement, dans neuf cas sur dix que j'ai traités, le coupable est le paramètre d'URL ou la redirection en chaîne. Pas la structure du site en elle-même.

Le diagnostic, étape par étape

Ma méthode, que je n'ai pas inventée mais que j'applique à la lettre depuis un moment :

1. Ouvrir le rapport « Statistiques d'exploration » et repérer la répartition entre « Découvertes », « Explorées » et « Explorées mais non indexées ». Un écart qui se creuse entre découvertes et explorées, c'est le signal.
2. Confronter avec les logs serveur sur au moins sept jours. Combien de hits Googlebot par URL distincte ? Où passe-t-il le plus clair de son temps ?
3. Identifier la répartition par type de contenu : pages produits, catégories, pagination, URL de filtres. Vous verrez tout de suite qui mange la moitié du budget pour rien.
4. Repérer les familles d'URL qui reviennent en exploration plusieurs fois par semaine sans jamais changer. C'est du gaspillage pur.

Ce diagnostic prend deux à trois heures sur un site de taille moyenne. Pas deux semaines.

Le robots.txt mal utilisé : erreur classique

« Je vais juste bloquer le dossier dans le robots.txt. » Combien de fois j'ai entendu ça avant de constater que le site avait bloqué ses propres pages produits en croyant bloquer un sous-dossier de test. Un robots.txt mal ciblé peut faire disparaître des pages de l'index en quelques semaines.

La distinction à garder en tête : le robots.txt empêche l'exploration, mais si Google découvre l'URL ailleurs (lien externe, sitemap), il peut l'indexer sans contenu. Pour une page qu'on veut désindexer sans la supprimer, on utilise une balise noindex, pas un blocage robots.txt. C'est l'inverse qui est vrai quand on veut économiser du crawl : là, bloquer au niveau du robots.txt est légitime, à condition de ne pas vouloir indexer la page.

Quel levier pour quel problème

Problème constaté	Levier à activer	Effet attendu
Paramètres d'URL générant des milliers d'URL	Balises canonical + règles de paramètres dans la Search Console	Forte réduction des URL explorées
Pages dupliquées ou proches	Canoniques croisées + consolidation du contenu	Répartition propre du budget
Redirections en chaîne	Réécriture des règles 301 pour aller à la cible finale	Débit serveur amélioré, budget libéré
Liens internes cassés	Correction au niveau des gabarits	Moins de hits gaspillés en 404
Pages de test ou de staging accessibles	Blocage robots.txt + suppression de l'index	Gain net immédiat

Servir Googlebot mieux, pas plus vite

Autre chose que j'ai apprise un peu tard, et que je regrette : on peut avoir un crawl budget correct et un serveur qui répond mal. Le crawl rate limit dépend directement de la capacité de votre hébergement à répondre vite. Si votre serveur met 2 secondes à renvoyer une page, Google ralentit tout seul.

Sur un site que je suivais, on avait un hébergement mutualisé, et les pics de charge faisaient grimper le TTFB à plus de 3 secondes en heure de pointe. Googlebot diminuait son rythme sans qu'on lui demande. On a migré vers un serveur dédié avec cache serveur correctement configuré. Résultat en trois semaines : +40 % de pages explorées par jour, à contenu identique.

Le cache, justement. Trop de sites envoient des en-têtes no-cache sur des pages qui ne changent jamais. Googlebot, à chaque passage, doit reconstruire la page côté serveur. Pour les pages de catégorie d'un catalogue, c'est du gaspillage à grande échelle.

Des sitemaps vraiment propres

Un sitemap n'augmente pas le crawl budget. Il aide Google à savoir où aller. Mais un sitemap contenant 60 000 URL dont 20 000 en redirection ou en 404, c'est une invitation au désastre. Passez le vôtre au filtre : seulement des URL en 200, indexables, canoniques. Le reste n'a rien à y faire. J'ai vu des sitemaps générés automatiquement qui pointaient vers des versions paginées de filtres — du contenu qu'on voulait justement éviter.

Resserrer le maillage interne

À budget constant, on peut faire mieux descendre Googlebot en profondeur en réduisant le nombre de clics nécessaires pour atteindre les pages importantes. Une page à quatre clics de la home est explorée moins souvent qu'une page à un clic. Ce n'est pas une règle écrite, c'est une tendance que j'observe systématiquement.

Concrètement :

• Faire remonter les pages stratégiques dans le menu ou dans un bloc « produits phares ».
• Ajouter des liens contextuels depuis les pages les plus explorées.
• Réduire le nombre de liens dans le footer — chaque lien du footer est suivi à chaque passage de Googlebot, même s'il ne mène nulle part d'utile.

Budget de crawl ou fréquence de crawl : ce n'est pas la même chose

On mélange souvent les deux. La fréquence de crawl, c'est à quelle cadence Google revient sur une URL donnée. Le budget de crawl, c'est le volume global d'exploration alloué à votre domaine sur une période. Vous pouvez avoir une fréquence de crawl élevée sur 100 pages et un budget global ridicule parce que 90 % de votre domaine est du bruit. C'est même le cas le plus fréquent sur les sites mal structurés.

Corriger l'un sans l'autre ne donne rien. Un site qui gagne du budget mais continue à le gaspiller sur des URL de filtres n'avancera pas plus vite.

Quand faut-il vraiment nettoyer, et quand laisser tomber

Un site de 500 pages n'a jamais de problème de crawl budget. Vraiment jamais. Si vous lisez ce genre d'article avec un site de 800 URL, la réponse est probablement ailleurs : qualité du contenu, autorité, intention de recherche mal ciblée.

Le seuil, dans mon expérience :

• À partir de 5 000 URL, commencez à surveiller.
• À partir de 20 000 URL, ou si le site est mis à jour quotidiennement, le sujet devient prioritaire.
• Sur un site à 100 000 URL avec facettes, c'est probablement le chantier n°1 du trimestre.

Et une chose que je répète à mes clients : le crawl budget se dégrade vite quand on arrête de le surveiller. Un site qui change de gabarit, qui migre d'URL, qui ajoute des filtres, peut repartir en arrière en trois mois. Ce n'est pas une optimisation one-shot, c'est une hygiène.

Les erreurs que je regrette d'avoir faites

La pire : avoir bloqué au robots.txt un dossier que je voulais désindexer. Deux mois plus tard, les pages ressortaient dans les résultats avec un descriptif vide, parce que Google les avait découvertes via un lien externe et ne pouvait plus les explorer pour voir la balise noindex. Il a fallu tout rouvrir, attendre la réindexation, puis appliquer le bon noindex. Perte de temps : six semaines.

Deuxième erreur : avoir cru que le nombre de pages soumises dans le sitemap influençait la fréquence de crawl. Il n'influence que la découverte. Une fois découvertes, c'est Google qui décide de la cadence. Point.

Troisième : avoir négligé les paramètres d'URL dans la Search Console pendant des mois parce que « ça marchait ». Ça ne marchait pas. Ça consommait. On l'a vu quand le budget global a chuté de moitié après une mise à jour du site.

Voilà pour les regrets. La bonne nouvelle, c'est qu'ils sont tous réparables — sauf peut-être le temps perdu.

Le vrai marqueur d'un crawl budget sain

Ce n'est pas le nombre de pages explorées par jour. C'est la part du budget qui va aux pages que vous voulez voir indexées. Un site qui explore 30 000 pages par jour dont 28 000 sont des URL de filtres est en plus mauvaise posture qu'un site qui explore 5 000 pages par jour dont 95 % sont des pages de contenu.

Donc l'objectif n'est jamais « faire grimper la courbe ». C'est la redresser. La ramener vers ce qui compte. Une fois qu'on a compris ça, les corrections deviennent presque évidentes. Presque.