Comment analyser le budget crawl d’une boutique PrestaShop avec un gros catalogue ?

Sur un catalogue de quelques centaines de références, le budget de crawl n’a jamais été votre problème. Passé quelques milliers de produits avec des filtres actifs, il le devient, et pas de la façon dont les guides génériques le décrivent.

Le budget de crawl, au-delà de la définition générique

Le budget de crawl est le nombre d’URLs que Googlebot explore sur votre site sur une période donnée, déterminé par deux facteurs : la limite de crawl (ce que votre serveur peut encaisser sans dégrader ses performances) et la demande de crawl (l’intérêt de Google pour vos pages, lié à leur popularité et à leur fraîcheur). Cette définition est correcte, mais elle raisonne pour un site générique. Sur PrestaShop, le facteur qui domine n’est presque jamais la limite serveur : c’est le nombre d’URLs générées par la boutique elle-même, souvent sans que personne l’ait décidé.

La combinatoire des filtres, le vrai gouffre PrestaShop

C’est ce mécanisme, pas le volume de produits en tant que tel, qui fait basculer une boutique PrestaShop dans une zone à risque de gaspillage de budget de crawl. Le seuil generalement cité par Google (le budget de crawl devient un sujet surtout au-delà du million d’URLs) trompe beaucoup de propriétaires de boutiques moyennes : ils raisonnent en nombre de produits, alors que Google raisonne en nombre d’URLs uniques découvertes, filtres compris.

Mesurer avec les logs serveur

L’analyse de logs reste la seule méthode qui montre ce que Googlebot fait réellement, par opposition à ce qu’il est censé faire. Récupérez les logs bruts du serveur (accès Apache/Nginx ou export via l’hébergeur), filtrez sur le user-agent Googlebot vérifié par résolution DNS inverse, puis croisez les URLs visitées avec leur type : fiche produit, catégorie propre, ou URL de filtre/tri.

1. Isoler le trafic Googlebot réelFiltrez les logs sur le user-agent contenant « Googlebot » puis vérifiez par résolution DNS inverse que l’IP appartient bien à Google, pour écarter les faux Googlebot qui fausseraient l’analyse.
2. Catégoriser chaque URL crawléeClassez chaque ligne en trois familles : fiche produit, page de catégorie propre, URL de filtre ou de tri identifiable par ses paramètres GET ou son pattern d’URL réécrite.
3. Calculer la répartition en pourcentageLe ratio URLs de filtre / total des hits Googlebot est l’indicateur qui révèle un problème : au-delà de 30 à 40 % du crawl consacré à des URLs de filtre, le budget consacré aux vraies fiches produit se réduit d’autant.

Croiser avec Search Console

Le rapport de statistiques sur l’exploration de Search Console (Paramètres > Statistiques sur l’exploration) complète les logs sans les remplacer : il donne la tendance sur 90 jours et la répartition par type de réponse, mais pas le détail URL par URL. Le rapport de couverture, lui, permet de vérifier combien de ces URLs de filtre finissent en « Explorée, actuellement non indexée » : un volume élevé dans ce statut, corrélé à une forte proportion de filtres dans les logs, confirme le diagnostic de gaspillage.

Calculer le taux de gaspillage, un exemple concret

Dans cet exemple issu d’un audit réel sur une boutique de 4 200 références, près de la moitié du budget de crawl partait sur des combinaisons de filtres, laissant les nouvelles fiches produit attendre parfois plusieurs semaines avant leur première exploration. C’est ce type de tableau, construit à partir de vos propres logs, qui transforme une intuition en décision technique justifiée.

Reconcentrer le budget sur le catalogue

Trois leviers, du plus simple au plus structurant. D’abord, le canonical sur les URLs de filtre pointant vers la page de catégorie propre : il ne bloque pas le crawl mais consolide le signal d’indexation. Ensuite, le blocage ciblé dans robots.txt des patterns de paramètres de filtre identifiés dans vos logs : plus radical, à réserver aux combinaisons qui n’ont aucune valeur de recherche. Enfin, la balise noindex,follow sur les pages de filtre à faible volume de recherche, qui laisse Googlebot continuer de suivre les liens sans indexer la page elle-même. Ces trois leviers ne s’excluent pas : sur une boutique avec une combinatoire lourde, la combinaison canonical + robots.txt ciblé donne generalement le résultat le plus net, à condition de vérifier que le pilotage n’entre pas en collision avec le noindex déjà posé (un blocage robots.txt empêche Google de lire un noindex placé sur la même URL, un piège détaillé dans notre guide sur la désindexation des pages de recherche interne PrestaShop). Le paramétrage précis du fichier robots.txt lui-même fait l’objet d’un guide dédié : comment configurer robots.txt sur PrestaShop pour le SEO. Et pour vérifier que vos vraies fiches produit sont bien soumises à Google en priorité, notre article sur la création d’un sitemap XML PrestaShop optimisé complète la démarche.

Retenir l’essentiel

Le budget de crawl sur PrestaShop n’est pas un problème de volume de produits : c’est un problème de combinatoire de filtres. Mesurez d’abord via les logs avant de bloquer quoi que ce soit, sous peine de couper l’accès à des pages qui méritaient d’être explorées.