Comment diagnostiquer un problème de budget de crawl (sans se raconter d'histoires)
« On a 8 000 pages que Google n'a jamais vues. » Cette phrase, je l'ai entendue dans une réunion il y a quelques mois, et le pire, c'est que les gens autour de la table hochaient la tête comme si c'était une fatalité météo. Sauf que non. Un budget de crawl, ce n'est pas un dieu capricieux qui décide de bouder vos URLs. C'est une négociation permanente entre ce que votre serveur peut encaisser et ce que Google a envie d'explorer. Et comme toute négociation, il y a des leviers.
Le problème, c'est que 90 % des diagnostics que je croise partent du mauvais bout : on vous envoie droit vers les correctifs (robots.txt, canonical, maillage) avant même d'avoir mesuré où part réellement le jus. Résultat, deux semaines de travail pour rien.
Points clés à retenir
- Un budget de crawl ne se diagnostique pas « au feeling » : il se mesure en croisant logs serveur et indexation réelle.
- La règle de pertinence tient toujours : sous ~10 000 pages, le budget de crawl est rarement votre problème (cherchez ailleurs).
- Le premier indicateur à surveiller est le ratio de hits gaspillés sur des URLs non indexables.
- Augmenter la fréquence de crawl avant d'avoir réduit le gaspillage revient à remplir un seau percé.
- Un diagnostic propre prend 2 à 3 jours, pas 3 semaines. Si vous dépassez, vous noyez le poisson.
Votre budget de crawl est-il vraiment le problème ?
Avant de plonger dans les logs, une question honnête : avez-vous le volume pour que le crawl budget soit ne serait-ce qu'un sujet ?
J'entends chaque semaine des e-commerçants avec 400 produits paniquer sur leur « budget de crawl ». Franchement, à ce niveau-là, votre problème est ailleurs — qualité de contenu, structure, indexation basique. Le crawl demand s'active pour les sites qui dépassent la dizaine de milliers d'URLs, parfois moins si l'architecture génère du bruit (paramètres, filtres, pagination). En dessous, Google a largement le temps de tout voir.
Les signes qui doivent vraiment allumer le voyant rouge
- Des pages produit ou catégorie stratégiques découvertes plus de 30 jours après leur publication
- Un volume de hits Googlebot qui stagne alors que vous ajoutez du contenu
- Une majorité de votre crawl capturée par des URLs que vous ne voulez pas voir indexées
- Des pages commerciales absentes de l'index alors qu'elles sont liées en interne
- Un taux de revisite très faible sur vos pages à forte valeur
Si trois de ces signaux se cumulent, vous avez un vrai problème. Sinon, vous cherchez probablement une excuse technique pour ne pas travailler votre contenu. Je dis ça sans méchanceté.
Croiser les logs serveur et Search Console : la méthode pas-à-pas
Les logs serveur sont souvent présentés comme « la seule source de vérité ». C'est vrai, mais incomplet : seuls, ils vous disent ce que Googlebot a fait, pas ce qu'il aurait dû faire. Le vrai diagnostic naît du croisement avec ce que Search Console voit de son côté.
Étape 1 — Isoler proprement les hits Googlebot
Piège classique : filtrer sur « Googlebot » dans le user-agent attrape aussi tous les faux (SEO tools, scrapers, scripts mal configurés). Le vrai Googlebot se vérifie par reverse DNS. Sur un fichier de logs de 2 Go, ça change tout : je suis déjà passé de 1,2 million de hits « Googlebot » à 340 000 une fois la vérification faite. Le gaspillage fantôme disparaît d'un coup.
Étape 2 — Classer les URLs par « désirabilité »
Vous ne pouvez pas juger un gaspillage sans savoir quelles pages comptent. Exportez votre sitemap, vos pages catégories stratégiques, vos fiches produit prioritaires. Puis étiquetez chaque URL crawlé comme : prioritaire, tolérée (paginations utiles, tags contrôlés) ou parasite (filtres à paramètres, sessions, pages vides, doublons de tri).
Étape 3 — La jointure qui dit tout
Tableau croisé par URL : hits Googlebot × statut HTTP × présence dans l'index GSC × dernière date de crawl. Trois ratios en sortent, et ce sont eux qui pilotent tout :
| Indicateur | Calcul | Seuil d'alerte |
|---|---|---|
| Gaspillage de crawl | Hits sur URLs parasites / hits totaux | > 30 % |
| Hits sur erreurs | Hits sur 4xx et soft 404 / hits totaux | > 5 % |
| Délai de revisite stratégique | Jours moyens entre deux crawls d'une page prioritaire | > 45 jours |
| Taux de couverture utile | URLs stratégiques crawlées / URLs stratégiques totales | < 80 % |
Ces seuils ne sont pas des vérités gravées. Ce sont les miens, calibrés sur une dizaine de sites à forte volumétrie. Ils marchent pour moi. À vous de les ajuster à votre contexte, mais ne descendez pas en dessous — sinon vous vous alarmez pour rien.
Les outils que j'utilise réellement
Je ne vais pas vous vendre du rêve. Pour un premier passage rapide, GoAccess en ligne de commande fait le job en dix minutes. Pour de l'analyse sérieuse avec jointure sitemap et GSC, Screaming Frog Log File Analyser reste mon cheval de bataille — l'interface est austère, mais il tient des fichiers que d'autres refusent d'ouvrir. Et pour scripter vos propres ratios, Python + pandas : trois heures de travail une fois, réutilisables à l'infini.
Réduire le gaspillage avant d'augmenter le crawl
Voilà l'erreur que je vois le plus souvent, et je l'ai commise moi-même. On constate que Googlebot crawle peu, alors on cherche à le faire crawler plus : sitemaps plus fréquents, ping, maillage massif. Sauf que si la moitié du crawl part sur des URLs parasites, vous demandez à Google d'aller plus vite dans un mur. Il ne le fera pas, et vous aurez perdu trois semaines.
L'ordre logique est inverse. D'abord boucher les fuites, ensuite seulement réclamer plus de fréquence. Sur un projet où je suis intervenu, on a supprimé 62 % des URLs crawlées (filtres à paramètres mal gérés, sessions dans les URLs, paginations imbriquées infinies) sans toucher à une seule page utile. Le crawl total a baissé de moitié. Et pourtant, le délai de revisite des pages catégories est passé de 38 jours à 6. Google ne crawlait pas moins, il crawlait mieux.
Les fuites à traiter en priorité
- Paramètres de filtre et de tri générant des milliers de combinaisons uniques
- Sessions et identifiants utilisateurs dans les URLs (oui, ça existe encore en 2026)
- Paginatons infinies ou quasi-infinies sans cap clair
- Pages de recherche interne ouvertes à l'indexation
- Doublons HTTP/HTTPS ou www/non-www mal redirigés
- Soft 404 qui renvoient un code 200 et se font recrawler en boucle
Le robots.txt est utile, mais attention : il empêche le crawl, pas l'indexation. Une URL bloquée en robots.txt peut toujours apparaître dans les résultats si elle est liée quelque part. Pour du nettoyage propre, combinez toujours avec des balises noindex servies correctement — donc accessibles au crawl. C'est contre-intuitif, et c'est justement pour ça que tant de sites se plantent.
Trois erreurs qui ruinent le diagnostic
Analyser une fenêtre trop courte
Une semaine de logs, ça ne dit rien. Googlebot a des cycles, parfois hebdomadaires, parfois plus longs selon votre fraîcheur. Je travaille sur des fenêtres de 28 jours minimum, et 90 jours quand je cherche à identifier des tendances de revisite. En dessous, vous prenez des décisions sur du bruit.
Ignorer la distinction desktop/mobile
Depuis le passage au mobile-first indexing (déjà ancien, mais on l'oublie encore), Googlebot mobile et desktop ne crawle pas à la même fréquence partout. Sur certains sites, l'écart atteint 20 à 30 %. Si vous mixez les deux user-agents dans votre analyse, vous lissez un signal utile.
Conclure « c'est la faute de Google »
Neuf fois sur dix, quand un client me dit que Google ne crawle pas ses pages, le problème est chez lui. Une redirection mal foutue, un maillage absent, un serveur lent qui déclenche le crawl rate limit. Le crawl rate limit, d'ailleurs, c'est le seul paramètre vraiment côté serveur : si votre TTFB dépasse régulièrement 1 seconde sur des pages stratégiques, Google ralentit de lui-même. Ce n'est pas une punition, c'est de la prudence.
Ce qui reste une fois le diagnostic posé
Un diagnostic propre, ce n'est pas un rapport de 40 pages avec des camemberts. C'est une liste courte : quelles URLs gaspillent, pourquoi, et ce qu'on fait cette semaine. Le reste, c'est de la littérature.
Et il y a une chose que peu de gens acceptent : parfois, après nettoyage complet, la fréquence de crawl ne remonte pas tout de suite. Comptez plusieurs semaines, parfois un trimestre, avant que Google recalibre. Il teste, il observe, il ajuste. C'est frustrant quand on a livré le travail propre. Mais au moins, à ce moment-là, vous saurez que le problème n'était pas de votre côté — et c'est déjà énorme.
La vraie question n'est donc pas « comment augmenter mon budget de crawl » mais « est-ce que ce que Google voit mérite son temps ». Répondez honnêtement à ça, et le reste suit.