Chaque hit de Googlebot sur une URL de tri ou une combinaison de facettes est un hit en moins sur vos nouveaux produits. J'ai audité des catalogues de 50 000 à 2 millions de références : dans tous les cas, entre 40 et 82% du budget crawl partait sur des URLs sans la moindre valeur business. Des facettes combinatoires, des paginations profondes, des pages de recherche interne que personne n'avait bloquées.
Ce guide vous donne le protocole que j'utilise pour reprendre le contrôle : cartographier ce que Googlebot crawle réellement, scorer chaque URL par valeur business, et mesurer l'efficacité avec des KPIs actionnables. Avant de piloter le crawl, poser le diagnostic via l'audit d'indexation comme point de départ.
Ce que les logs révèlent sur votre crawl budget
Google définit le crawl budget comme la combinaison de deux mécanismes : la capacité de crawl (crawl capacity limit, déterminée par la performance serveur et les erreurs HTTP) et la demande de crawl (crawl demand, liée à la popularité et à la fraîcheur du contenu). C'est la composante la plus basse qui dicte le volume réel de pages visitées.
En pratique, la performance serveur joue un rôle sous-estimé. Google ralentit son robot sur les serveurs lents pour ne pas les surcharger. Un TTFB supérieur à 500 ms réduit déjà significativement la fréquence de passage. Pour comprendre comment les Core Web Vitals influencent la capacité de crawl, il faut raisonner en termes de signaux serveur autant que de signaux utilisateur.
Google affirme que les sites de « quelques milliers d'URLs » n'ont pas à s'inquiéter. C'est vrai pour un site vitrine. C'est faux pour un e-commerce de 5 000 produits avec navigation à facettes, qui peut générer des millions d'URLs accessibles. Le bon indicateur n'est pas la taille du catalogue : c'est la surface crawlable totale.
Les données Botify révèlent une corrélation nette : quand le taux de pages non-indexables dépasse 15%, seulement 33% des pages sont crawlées par mois. En dessous de 5% de pages non-indexables, ce chiffre monte à 50%. Chaque URL inutilement crawlée nourrit le lien entre crawl gaspillé et index bloat e-commerce.
"Sur son site, on doit faire crawler et indexer uniquement les URLs pertinentes pour optimiser l'utilisation de ce budget de crawl. C'est le principe directeur de tout ce qui suit."
Daniel Roch (SeoMix, 2022)
Cartographier ce que Googlebot crawle vraiment
L'identification par User-Agent seul est insuffisante : elle est facilement usurpable. Le protocole complet exige une vérification DNS inverse puis directe. L'IP doit retourner un hostname de type crawl-66-249-66-1.googlebot.com, et la résolution directe de ce hostname doit correspondre à l'IP originale. Seuls les domaines googlebot.com, google.com et googleusercontent.com sont légitimes. Pour approfondir le fonctionnement du crawler de site web et ses méthodes de parcours, il est utile de maîtriser ces mécanismes de vérification.
Une fois les vrais hits Googlebot isolés, normaliser les URLs : conversion en minuscules, suppression des trailing slashes, nettoyage des paramètres de tracking (utm_*, gclid, fbclid), et classification par type via patterns regex.
Je classe chaque URL dans l'une de ces catégories avec un objectif de recrawl précis :
- Pages produit (PDP) : recrawl tous les 3 à 7 jours sur les best-sellers, découverte sous 48h pour les nouveautés
- Pages catégories : stabilité d'indexation, recrawl tous les 7 à 14 jours
- Navigation à facettes : exclusion totale du crawl sauf facettes à fort potentiel SEO (transformées en pages statiques)
- URLs de tri et pagination profonde : blocage complet, contenu dupliqué sans valeur distincte
- Recherche interne : exclusion stricte via robots.txt
Un calcul simple illustre le problème : 100 couleurs x 10 tailles x 10 marques x 5 options de tri = 50 000+ URLs pour une seule catégorie. Gary Illyes (Google, 2023) confirme que la navigation à facettes est « de loin la source la plus commune de problèmes de sur-crawl signalée par les propriétaires de sites ».
La combinaison facettes x pagination multiplie les crawl traps créés par les facettes paginées. Quand plus de 30% des hits Googlebot dans vos logs ciblent des facettes, c'est une urgence.
Réduire, orienter, stabiliser : le playbook opérationnel
Phase 1 : réduire la surface crawlable
La priorité absolue. Gary Illyes (Google Search Central, 2023) recommande robots.txt plutôt que noindex pour les crawl traps : « Don't use noindex, as Google will still request, wasting crawling time. » Le blocage robots.txt empêche le crawl. Le noindex le permet mais empêche l'indexation. Pour le budget de crawl pur, robots.txt gagne.
Un cas concret documenté par Seenos.ai : un site de 2 millions de pages où 82% du crawl Googlebot partait sur des URLs multi-paramètres. Après blocage robots.txt des combinaisons de facettes et mise en place d'un sitemap statique, le délai d'indexation des nouveautés est passé de 60+ jours à moins de 48 heures.
Nuance importante : robots.txt peut créer des résultats « Indexed without description » si des backlinks externes pointent vers les pages bloquées. Dans ce cas, appliquer d'abord un noindex, attendre la désindexation, puis ajouter le Disallow. La procédure détaillée de nettoyage d'index e-commerce couvre ces scénarios de transition.
Phase 2 : orienter Googlebot vers les pages stratégiques
Le maillage interne est le levier le plus sous-estimé. Des restructurations documentées de breadcrumbs et liens internes montrent des bonds de couverture de crawl de l'ordre de 4x sur des sites mid-market. Le scoring URL doit intégrer la profondeur de crawl comme facteur limitant pour les pages à plus de 4 clics.
Les sitemaps cibles doivent inclure exclusivement les URLs canoniques indexables. La canonicalisation joue ici un rôle structurant : chaque URL présente dans le sitemap doit pointer vers elle-même en tant que canonical, sans quoi le signal envoyé à Googlebot est ambigu. Les sitemaps segmentés par type (catégories, PDP in-stock, best-sellers, nouveautés, promotions) permettent un pilotage fin du crawl.
Phase 3 : stabiliser l'index
Éliminer les variantes parasites (paramètres de tracking, sessions, formats alternatifs). Nettoyer les soft 404 via GSC et renvoyer de vrais codes 404 ou enrichir le contenu. Programmer une analyse logs + GSC mensuelle pour détecter les régressions avant qu'elles ne s'installent.
Sitemaps : ce que Google lit vraiment (et ce qu'il ignore)
Gary Illyes (SE Roundtable, 2017) a qualifié les attributs priority et changefreq du sitemap XML de « bag of noise ». Google les ignore complètement. Seul lastmod est utilisé, et uniquement s'il est « consistently and verifiably accurate ». Mettre à jour lastmod sans changement réel de contenu, c'est perdre toute crédibilité auprès du crawler.
Je recommande 5 sitemaps distincts :
- sitemap-categories.xml : pages catégories principales, refresh hebdomadaire
- sitemap-pdp-instock.xml : produits en stock uniquement, refresh quotidien
- sitemap-pdp-bestsellers.xml : top 1 000 vendeurs, refresh quotidien
- sitemap-nouveautes.xml : produits de moins de 30 jours, refresh quotidien
- sitemap-promos.xml : promotions actives, temps réel si possible
Trois anti-patterns que je vois régulièrement : inclure des URLs bloquées par robots.txt dans le sitemap (signal contradictoire pour Google), laisser des URLs noindex dans le sitemap, et dépasser 50 000 URLs par fichier sans sitemap index. Chacun de ces cas envoie un signal d'incohérence qui dégrade la confiance de Googlebot dans vos déclarations. Pour aller plus loin sur les signaux techniques qui impactent la visibilité, consultez le guide sur comment indexer une page sur Google.
Scorer vos URLs pour prioriser le crawl
Le framework que j'utilise combine 5 dimensions pondérées par leur impact business :
Score_URL = (Trafic x 0.25) + (Revenue x 0.35) + (Fraîcheur x 0.15) + (Liens x 0.15) + (Stock x 0.10)
Le modificateur stock s'applique en multiplicateur : in-stock = 1.0, out-of-stock = 0.3. Chaque dimension est normalisée sur 100 à partir de la valeur max du catalogue.
Les 4 tiers de priorisation :
- Tier 1 (score 80-100) : crawl quotidien. Best-sellers, promotions actives, nouveautés.
- Tier 2 (score 50-79) : crawl hebdomadaire. Produits actifs standard.
- Tier 3 (score 20-49) : crawl mensuel. Archives, produits longue traîne.
- Tier 4 (score 0-19) : exclure ou noindex. Ruptures prolongées, duplicates.
Ce scoring doit être recalculé mensuellement et alimenter directement les décisions de sitemap et de maillage interne.
Pour un catalogue de moins de 10 000 produits, le scoring reste un exercice utile mais rarement critique. À partir de 100 000 références, c'est une nécessité : sans priorisation explicite, Googlebot répartit son budget de manière uniforme et vos best-sellers sont traités comme n'importe quelle fiche obsolète.
KPIs de crawl actionnables
Dan Taylor (SALT.agency) propose une formule simple : N = Pages indexées / Taux de crawl quotidien. Un N inférieur à 5 indique un crawl sain. Un N supérieur à 10 signale un problème critique : Google met plus de 10 jours à parcourir l'ensemble de vos pages indexées.
Trois benchmarks complémentaires que je suis en priorité :
- Crawl ratio (hits pages indexables / total hits Googlebot) : cible supérieure ou égale à 0.80
- Crawl monétisable (hits pages à revenu / total crawl) : cible supérieure ou égale à 0.65
- Couverture sitemap (pages indexées / pages soumises en sitemap) : cible supérieure ou égale à 0.95
Dans Google Search Console :
- Ouvrir Paramètres > Crawl stats > par type de réponse
- Vérifier que le ratio réponses 2xx / total reste supérieur à 90%
- Contrôler les pics d'activité Googlebot après chaque mise en prod
Si vous n'êtes pas encore familier avec l'interface, consultez le guide pour bien démarrer avec Google Search Console avant d'explorer ces rapports avancés.
Dans vos logs serveur :
- Calculer N = pages indexées (GSC) / hits Googlebot quotidiens
- Segmenter les hits par type d'URL via patterns regex
- Identifier les URLs qui consomment plus de 5% du budget sans trafic organique
Le tableau de bord idéal combine les données de logs serveur et l'API GSC dans Looker Studio, segmentés par type d'URL. Ces métriques de crawl s'intègrent dans un reporting KPI SEO plus large qui relie performance technique et impact business.
Toute modification doit suivre un protocole rigoureux : baseline de 2 à 4 semaines sans changement, intervention unique (un seul facteur modifié), puis mesure sur 4 à 6 semaines.
Marketplace automobile (Botify) : 19x d'augmentation du crawl stratégique, doublement du trafic organique en 3 mois. Le cas documenté par Botify : 99% de pages non crawlées initialement. Après restructuration (robots.txt + liens internes + sitemap), les résultats sont apparus en 2 semaines sur les modifications robots.txt, 6 semaines pour le maillage interne.
Selon votre situation
Situation 1 : Vous venez de lancer un catalogue de 50 000 produits et vos nouvelles fiches mettent 3 semaines à s'indexer.
Ma recommandation : commencer par les logs. Identifier la part du crawl qui part sur les facettes et la recherche interne. Bloquer via robots.txt en priorité, puis mettre en place le sitemap pdp-instock. Le gain d'indexation est visible en 2 à 4 semaines. L'optimisation des fiches produit e-commerce viendra ensuite amplifier le rendement du crawl récupéré.
Erreur fréquente : bloquer les facettes en oubliant la recherche interne. Elle peut à elle seule consommer 20 à 40% du budget.
Situation 2 : Votre site dépasse 500 000 pages et votre crawl ratio stagne sous 40%.
Ma recommandation : audit logs mensuel obligatoire. Calculer le Crawl Efficiency Score (crawl stratégique / crawl total x 100). S'il est inférieur à 50%, la priorité est de réduire la surface non-indexable avant d'intervenir sur le maillage.
Erreur fréquente : commencer par le maillage sans avoir bloqué les traps. Googlebot continue de gaspiller sur les facettes même avec un maillage renforcé.
Situation 3 : Vos logs sont inaccessibles (CDN opaque, infra cloud sans accès serveur).
Ma recommandation : s'appuyer sur GSC Crawl Stats et la formule N = pages indexées / crawl quotidien. Si N dépasse 10, traiter sitemaps et robots.txt en priorité. Le diagnostic logs peut attendre d'avoir accès via un module de logging dédié.
Erreur fréquente : considérer GSC Crawl Stats comme un substitut complet aux logs. GSC ne montre pas la distribution par type d'URL, information critique pour identifier les crawl traps dominants.
Les erreurs qui sabotent votre crawl budget
1. Laisser la navigation à facettes sans blocage robots.txt
La cause principale de gaspillage que je retrouve sur la majorité des audits e-commerce. Un catalogue de 50 000 produits avec plusieurs niveaux de filtres peut générer des millions d'URLs crawlables. Chaque hit Googlebot sur ces pages est soustrait de vos PDP.
2. Mettre des lastmod statiques dans votre sitemap
Gary Illyes est explicite : Google n'utilise lastmod que si les dates sont « consistently and verifiably accurate ». Un lastmod identique sur 200 000 URLs est perçu comme du bruit. Google ignore l'attribut et perd confiance dans le sitemap entier.
3. Confondre volume d'indexation et qualité de crawl
Avoir 90% de ses pages indexées ne signifie pas que le crawl budget est bien utilisé. Le vrai indicateur : le crawl ratio (hits sur pages stratégiques / total hits). Viser 0.80 minimum. En dessous de 0.50, le problème est structurel même avec un index volumineux.
4. Combiner noindex ET robots.txt sur les mêmes URLs
robots.txt empêche le crawl, noindex le permet mais bloque l'indexation. Les combiner génère des signaux contradictoires et fait gaspiller des ressources crawl sur des pages qu'on voulait ignorer.
Questions fréquentes sur le crawl budget e-commerce
Google dit que non, en dessous de quelques milliers d'URLs. Mais un site de 5 000 produits avec navigation à facettes peut générer des millions d'URLs accessibles. Le bon indicateur est la surface crawlable totale, pas la taille du catalogue. Calculez votre score de santé crawl (formule N = pages indexées / crawl quotidien) : si N dépasse 10, vous avez un problème, même avec 3 000 références.
Google recommande robots.txt pour le crawl budget pur. Mais robots.txt peut créer des entrées SERP sans snippet si des backlinks externes pointent vers les pages bloquées. La synthèse que j'applique : robots.txt d'abord, noindex en backup si des liens externes existent. Ne jamais utiliser les deux simultanément sur la même URL.
Distribution typique du crawl budget e-commerce : catégories dans le menu 30 à 50%, facettes et filtres 10 à 40%, PDP seulement 15 à 30%. Les crawl traps aspirent le budget par leur volume. Si plus de 30% des hits Googlebot dans vos logs ciblent des facettes, c'est une urgence à traiter avant toute autre optimisation. L'enjeu est similaire à celui des catégories faibles qui diluent l'autorité du site sans apporter de trafic qualifié.
Non pour la priorisation directe (priority et changefreq sont ignorés). Oui pour la découverte et le signal de fraîcheur via lastmod. L'effet est réel mais indirect : un sitemap à jour avec des lastmod fiables réduit significativement le temps de découverte des nouvelles pages.
Trois niveaux de diagnostic. Niveau 1 : la formule rapide N = pages indexées / crawl quotidien GSC. Si N dépasse 10, c'est un signal d'alerte. Niveau 2 : GSC Crawl Stats, regarder la distribution par type de réponse. Niveau 3 : logs serveur si disponibles. Le benchmark sain est un minimum de 60% des hits Googlebot sur des pages indexables stratégiques.
Sources et références
- Documentation officielle du crawl budget — Google Search Central
- Gary Illyes : sitemap priority « a bag of noise » — SE Roundtable, 2017
- Crawl budget optimization for classified websites — Botify
- Managing faceted navigation SEO — Seenos.ai
- How to improve SEO by tackling index bloat and crawl waste — Pitchbox / Dan Taylor (SALT.agency)
- Guide indexation et crawl — Daniel Roch, SeoMix