Budget de crawl PrestaShop : maîtriser URLs de filtres et facettes

Table des matières :

Budget de crawl sur PrestaShop : le problème n’est pas Google, c’est l’explosion combinatoire
Comprendre les formats d’URLs de filtres et facettes (et où PrestaShop piège l’indexation)
Diagnostiquer le gaspillage de crawl : logs serveur, GSC, et symptômes côté perf
Stratégie de contrôle : décider ce qui doit être indexé, puis empêcher le reste de polluer
Implémentation pratique sur PrestaShop 8.1 / 9.x (PHP 8.2/8.3) : noindex, canonical, normalisation, sitemaps

Budget de crawl sur PrestaShop : le problème n’est pas Google, c’est l’explosion combinatoire

Le budget de crawl n’est pas une notion abstraite : sur un site e-commerce, c’est la capacité réelle des bots à parcourir vos URLs utiles (catégories stratégiques, produits, contenus éditoriaux) sans se perdre dans du bruit. Google le résume sans détour dans sa documentation : « Crawl budget isn’t something most publishers have to worry about. » (Google Search Central, Managing crawl budget : https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget). Sur PrestaShop, vous commencez à “devoir vous en soucier” quand :

votre catalogue devient volumineux (beaucoup de catégories + produits),
votre site publie/actualise souvent (stock, prix, nouveautés),
et surtout quand la navigation à facettes génère des milliers d’URLs techniquement distinctes mais sémantiquement redondantes.

La navigation à facettes (souvent portée par ps_facetedsearch, ex-“block layered navigation”) fabrique une combinatoire quasi-infinie : couleur × taille × marque × prix × disponibilité × tri × pagination. Exemple simple : 8 couleurs × 10 tailles × 12 marques = 960 combinaisons sur une seule catégorie, avant même d’ajouter des ranges de prix, le tri et page=. Et en pratique, PrestaShop ajoute aussi des paramètres de tri (order=product.price.asc), des paramètres de pagination (page=2) et parfois des paramètres liés au mode d’affichage ou au nombre de produits par page, ce qui multiplie encore la surface de crawl.

Mini-scénario (très fréquent sur des boutiques FR) : vous vendez des chaussures. Une catégorie “Baskets” a des facettes pointure (35–46), couleur, marque, prix, disponible en stock. Une recherche “baskets noires 42” est pertinente pour un utilisateur, mais si chaque combinaison devient une URL crawlable + maillée, Googlebot peut passer des journées à re-crawler des variantes “noires / 42 / tri par prix” plutôt que vos fiches produit qui changent (stock/prix), vos catégories principales, ou vos pages éditoriales.

Le cœur de PrestaShop ne fournit pas un contrôle SEO fin de ces variantes. La canonicalisation par défaut est généralement insuffisante sur les pages filtrées, et la plupart des thèmes laissent ces URLs accessibles et maillées (liens de facettes crawlables). Résultat :

Googlebot consomme ses hits sur des pages quasi-duplicats,
les pages catégories “propres” sont crawlées moins souvent,
et côté serveur vous payez la facture (CPU/PHP, DB, cache) sur des pages à faible valeur.

Un point important : ce n’est pas seulement un sujet “SEO”. Sur une boutique hébergée avec des ressources contraintes (CPU/RAM) ou un MySQL déjà chargé, une exploration disproportionnée des pages facettées peut devenir une charge continue, notamment pendant les pics (lancements, soldes, campagnes).

Comprendre les formats d’URLs de filtres et facettes (et où PrestaShop piège l’indexation)

Sur PrestaShop (1.7/8/9), deux grandes familles existent selon configuration, thème et module :

Paramètres querystring : /categorie?couleur=rouge&taille=m ou /categorie?q=....
Réécriture dans le chemin (souvent via q encodé) : /categorie?q=marque-nike/couleur-rouge/taille-m.

Le module ps_facetedsearch a historiquement tendance à s’appuyer sur un paramètre q (ou une structure similaire) qui encode la sélection. C’est “pratique” pour l’UX, mais SEO-toxique si vous ne décidez pas explicitement quelles combinaisons sont indexables. Dans la plupart des implémentations, l’ordre des facettes dans l’URL peut varier selon l’interaction utilisateur (ou selon les widgets), générant des URLs différentes pour un même ensemble de filtres (/q=couleur-rouge/taille-m vs /q=taille-m/couleur-rouge). Sans normalisation (ordre stable), vous fabriquez du duplicate par design.

Ajoutez à ça les variantes non sémantiques :

tri (order= / orderby= selon modules/thèmes),
pagination (page=),
taille de page (resultsPerPage, n=, etc. selon intégrations),
paramètres de tracking (UTM, gclid, fbclid…).

Sur une page catégorie, order= et les filtres “cosmétiques” sont typiquement à traiter comme non indexables.

Dernier piège PrestaShop : la réutilisation de la même page catégorie avec un contenu HTML quasi identique, mais une liste produits légèrement différente. Sans règles strictes (meta robots, canonicals, gestion des facettes “SEO”), vous envoyez des signaux contradictoires : maillage interne vers des variantes, canonicals non stabilisées, sitemaps parfois pollués.

Une règle simple pour raisonner : si une variante n’a pas vocation à être une page d’atterrissage (intention de recherche claire + contenu différenciant + maillage voulu), elle ne doit pas entrer en concurrence avec vos catégories / produits. Pour consolider la base technique avant d’aller plus loin, gardez une vue d’ensemble avec une checklist dédiée (voir : SEO PrestaShop : checklist technique 2025 pour indexation et performance).

Diagnostiquer le gaspillage de crawl : logs serveur, GSC, et symptômes côté perf

Le diagnostic fiable ne se fait pas à partir d’un crawl Screaming Frog “au hasard”, mais à partir des logs (Nginx/Apache) + Google Search Console. Les logs vous disent ce que les bots consomment réellement et combien ça coûte en temps serveur.

Concrètement, vous cherchez :

Un volume élevé de hits sur des URLs contenant q= / filter / orderby / order / page=.
Un ratio élevé de hits bots sur des URLs à faible valeur (variantes) vs catégories canon et fiches produits.
Des réponses 200 sur des pages filtrées qui devraient être noindex, et/ou des 301 en boucle (normalisation ratée).
Une surreprésentation de paramètres de tracking dans les URLs crawlées (souvent signe de liens partagés/maillés “sales”).

Exemples rapides (à adapter à votre format de logs). Pour isoler Googlebot et voir les URL les plus visitées contenant q= :

# Nginx/Apache (approche simple) : top URLs avec ?q= crawlées par Googlebot
grep -i "googlebot" access.log | grep -F "q=" | awk '{print $7}' | sort | uniq -c | sort -nr | head -50

Pour estimer l’impact serveur, regardez aussi :

la distribution des temps de réponse (si loggués : $request_time, $upstream_response_time),
le taux de 5xx ou 499 (clients qui coupent),
les pics sur certaines catégories (souvent les plus filtrées).

Côté GSC (Statistiques sur l’exploration), corrélez les pics de crawl avec des changements : activation d’une facette, ajout d’une catégorie, refonte thème, ou mise à jour du module. Indices typiques que le crawl part “dans le décor” :

“Pages explorées par jour” augmente, mais vos pages stratégiques n’entrent pas plus vite dans l’index.
Dans “Indexation > Pages”, vous voyez monter des statuts du type doublons / autre page canonique choisie / explorée actuellement non indexée sur des variantes de catégories.
Le graphe “Temps de réponse” se dégrade en même temps que l’exploration augmente : souvent le signe que les pages facettées tapent trop la DB.

Et c’est là que le SEO rejoint l’ops : sur PrestaShop, les pages catégories filtrées sollicitent la DB (combinaisons, stock, prix spécifiques, règles catalogue) et déclenchent souvent des requêtes coûteuses. Si vous observez une hausse de latence TTFB sur ces pages, ouvrez le slow query log et identifiez les requêtes les plus chères (voir : PrestaShop MySQL : analyser slow query log et optimiser index). Sur un gros catalogue, un “mauvais crawl” peut devenir une charge permanente, et pas juste un sujet SEO.

Checklist diagnostic (pragmatique) :

[ ] Top 50 URLs crawlées par Googlebot : combien sont des facettes ?
[ ] Les facettes retournent-elles 200 + contenu complet (donc crawl coûteux) ?
[ ] Les facettes ont-elles noindex effectif (vu dans le HTML ou l’en-tête) ?
[ ] Vos sitemaps contiennent-ils zéro URL facettée utilitaire ?
[ ] Le cache (applicatif/CDN) varie-t-il “trop” dès qu’il y a des paramètres ?

Stratégie de contrôle : décider ce qui doit être indexé, puis empêcher le reste de polluer

La stratégie robuste consiste à séparer :

1) les facettes qui créent de vraies pages d’atterrissage (intention claire, volume de recherche, contenu différenciant), 2) les facettes purement utilitaires (tri, ranges arbitraires, combinaisons trop fines), 3) les variantes à risque (multi-filtres profonds, pagination filtrée, ordres multiples).

Un outil simple pour décider, avant même de parler de technique : une matrice “valeur SEO vs risque de duplication”. Exemple (à adapter) :

Type de variante	Exemple	Valeur SEO attendue	Risque duplicate / explosion	Traitement recommandé
Facette “marché”	`marque=nike` sur “baskets”	Élevée	Moyen	Page d’atterrissage contrôlée (indexable)
Facette “stock”	`disponible=1`	Faible	Élevé	`noindex,follow` + canonical catégorie
Facette “tri”	`order=price.asc`	Nulle	Élevé	`noindex,follow` + canonical catégorie
Multi-filtres profonds	marque + couleur + pointure + prix	Variable	Très élevé	`noindex` + réduction maillage + normalisation
Pagination filtrée	`q=...&page=3`	Faible	Très élevé	`noindex` (souvent) + canonical catégorie filtrée si page SEO, sinon catégorie “propre”

Pour le point (1), évitez de “laisser Google découvrir au hasard”. Vous créez des landing pages contrôlées (texte, maillage, contenu unique, canonical stable). Le sujet est déjà traité en profondeur ici : Pages d’atterrissage SEO : maîtriser facettes, indexation Google et maillage interne. Sur PrestaShop, ça implique souvent une couche de routage/rewriting ou un module dédié, parce que le core ne fait pas nativement une “facette SEO” propre.

Pour (2) et (3), la règle pragmatique est : laisser crawler (pour que Google voie le noindex), mais empêcher l’indexation.

Ne tombez pas dans le réflexe Disallow systématique sur robots.txt : un blocage empêche l’exploration, mais ne garantit pas l’absence d’indexation si l’URL est découverte autrement (liens externes, historiques, etc.). La doc Google explique bien la différence entre contrôle du crawl et contrôle de l’indexation (Google Search Central, robots.txt : https://developers.google.com/search/docs/crawling-indexing/robots/intro). Donc, pour les pages facettées “inutiles”, privilégiez :

meta robots noindex,follow (ou X-Robots-Tag: noindex,follow) sur les URLs filtrées,
canonical vers la catégorie “propre” (sans paramètres) si le contenu est essentiellement un sous-ensemble (en gardant en tête qu’une canonical est un signal, pas une directive),
réduction du maillage : liens de facettes en rel="nofollow" ou déclenchement via JS (à manier avec prudence, et surtout de façon cohérente avec votre stratégie “pages SEO”).

Enfin, ne sous-estimez pas la dimension “capacité de crawl” : si votre infra rame, vous perdez sur tous les fronts. Sur LiteSpeed, PHP-FPM ou LSAPI, et sur la gestion du cache, vous avez des leviers concrets (voir : Performance PHP LiteSpeed : optimiser LSAPI, cache opcode et concurrence et PrestaShop performance : optimiser gros catalogues et Core Web Vitals). Un bot qui rencontre du 500 ou du 2s+ TTFB sur des pages filtrées va réduire l’intensité de crawl, y compris sur vos pages money.

Implémentation pratique sur PrestaShop 8.1 / 9.x (PHP 8.2/8.3) : noindex, canonical, normalisation, sitemaps

Pré-requis : accès au code (thème + modules), environnement de staging fidèle (sinon vous cassez l’indexation sans le voir), et capacité à déployer proprement. Si vous n’avez pas de staging reproductible, commencez par ça : Staging PrestaShop : créer un environnement Docker fidèle à la production. Côté versions, les exemples ci-dessous visent PrestaShop 8.1+ et 9.x ; sur 1.6, la logique est différente et le module layered navigation a d’autres comportements.

1) Ajouter un `noindex,follow` fiable sur les pages filtrées

Le point dur : détecter “page facettée” de manière déterministe. Dans beaucoup de shops, c’est un q non vide, ou un ensemble de paramètres de filtre connus.

Conseil pratique : listez explicitement les paramètres que vous considérez comme “facettes utilitaires” (souvent q, order, page, resultsPerPage, etc.). Si vous avez des paramètres marketing (UTM, gclid), traitez-les à part (souvent via canonical + nettoyage).

Exemple minimal (module technique) : dans un module, via hookDisplayHeader, injecter une variable Smarty si une facette est active (et laisser le template générer la balise).

public function hookDisplayHeader($params)
{
    $q     = (string) Tools::getValue('q');
    $order = (string) Tools::getValue('order');
    $page  = (int) Tools::getValue('page');

    // Ajustez selon votre boutique : si q est le vecteur principal des facettes,
    // et si order/page doivent toujours être non indexables
    $isFaceted = ($q !== '') || ($order !== '') || ($page > 1);

    if ($isFaceted) {
        $this->context->smarty->assign([
            'force_robots_noindex' => true,
        ]);
    }
}

Et dans themes/…/_partials/head.tpl (ou via un override propre au thème), vous conditionnez l’ajout :

{if !empty($force_robots_noindex)}
  <meta name="robots" content="noindex,follow">
{/if}

Deux points de contrôle (à faire “comme un robot”) :

Vérifiez la présence de la meta sur toutes les variantes (facette + tri + page 2).
Vérifiez que les pages qui doivent rester indexables (catégorie propre, produits, pages SEO) ne reçoivent jamais le noindex.

Enfin, sur les boutiques où ps_facetedsearch est fortement personnalisé, gardez un œil sur les mises à jour et le durcissement global : une implémentation bricolée peut introduire des comportements inattendus (et des risques). Si vous avez un plan de durcissement, vous pouvez l’intégrer à votre chantier SEO (voir : Sécurité PrestaShop : durcir psfacetedsearch et réduire la surface d’attaque).

2) Canonical : stabiliser sur la catégorie “propre” (et normaliser les paramètres)

Pour les pages filtrées non indexables, l’objectif est que toutes les variantes pointent vers une canonical stable : l’URL de la catégorie sans paramètres. Attention : si vous avez des pages facettées volontairement indexables (landing pages), ne canonisez pas tout vers la catégorie, sinon vous neutralisez votre stratégie.

Approche robuste : ne tentez pas de “deviner” la canonical à partir de l’URL ; récupérez l’ID catégorie et générez le lien via Link.

if ($isFaceted && $this->context->controller->php_self === 'category') {
    $idCategory = (int) Tools::getValue('id_category');
    if ($idCategory > 0) {
        $category = new Category($idCategory, $this->context->language->id);
        if (Validate::isLoadedObject($category)) {
            $canonical = $this->context->link->getCategoryLink($category);
            $this->context->smarty->assign('force_canonical_url', $canonical);
        }
    }
}

Dans le template head :

{if !empty($force_canonical_url)}
  <link rel="canonical" href="{$force_canonical_url|escape:'htmlall':'UTF-8'}">
{/if}

Le vrai gain vient souvent de la normalisation : si vous gardez des URLs filtrées crawlables (même en noindex), faites en sorte qu’un même set de filtres produise une seule URL :

ordre stable des facettes dans q=,
suppression des segments vides,
suppression des paramètres par défaut (ex. page=1),
et idéalement une redirection 301 vers la forme normalisée.

Sinon, vous “noindexez” correctement… mais vous continuez à gaspiller du crawl (et vous compliquer la vie côté logs, cache, analytics).

3) Maillage interne et sitemaps : arrêter d’inviter les bots au buffet infini

Même avec noindex, si votre maillage interne est une machine à fabriquer des millions de liens, vous augmentez l’exploration inutile. Deux actions efficaces :

Limiter les liens crawlables sur les facettes non stratégiques (ex. rel="nofollow" sur les combinaisons, ou déclenchement via JS en conservant une URL propre seulement pour les facettes SEO). C’est une décision d’architecture : vous choisissez ce qui mérite une URL.
Nettoyer les sitemaps : aucun sitemap ne doit contenir des URLs facettées “utilitaires”. Un sitemap est un signal d’“importance”. Pour la méthode et les pièges, voir : Plan de site : optimiser l’indexation Google avec un sitemap clair.

Astuce concrète : dans vos templates, repérez les blocs qui génèrent des liens de facettes sur toutes les pages (catégories, parfois même pages marque). Souvent, désactiver le caractère “lien” sur certaines facettes (ou en limiter l’indexation) a un impact immédiat sur le crawl… et sur le cache (moins de variations).

En complément, si vous avez un flux de mises à jour produit intense et que vous voulez accélérer l’exploration des pages vraiment importantes, vous pouvez vous appuyer sur IndexNow côté Bing/Yandex (Google n’en dépend pas). Pour l’intégration PrestaShop et la stratégie, voir : IndexNow : intégration PrestaShop et stratégie d’indexation pour e-commerce.

4) Robots.txt et règles serveur : à utiliser pour cadrer, pas pour masquer

Un robots.txt peut aider à cadrer l’exploration (ex. bloquer des endpoints internes, paramètres purement techniques), mais sur les facettes c’est souvent un mauvais premier réflexe. Si vous bloquez /categorie?q= alors que vous comptez sur noindex, vous créez une zone grise : Google peut conserver des URLs découvertes sans pouvoir les re-crawler pour rafraîchir les signaux (canonical/noindex), ce qui complique le nettoyage.

Quand vous avez besoin d’un contrôle fort, préférez les en-têtes HTTP : X-Robots-Tag. Exemple Nginx (à adapter, tester en staging) pour marquer q= en noindex :

location / {
  if ($arg_q != "") {
    add_header X-Robots-Tag "noindex, follow" always;
  }
}

Ce type de règle est brutal mais efficace, et indépendant du thème. Risque majeur : si vous avez des landing pages facettées indexables basées sur q=, vous les tuez aussi. D’où la nécessité d’une convention d’URL (ex. /landing/…) pour les pages SEO et de garder q= uniquement pour l’UX, ou à défaut de mettre en place une liste blanche (cas autorisés) avant d’appliquer le noindex côté serveur.

En pratique, “maîtriser les URLs de filtres et facettes” sur PrestaShop revient à accepter une réalité : le core n’a pas été conçu pour arbitrer SEO vs combinatoire. Vous devez choisir vos pages indexables, instrumenter les signaux (noindex/canonical), normaliser les URLs, et empêcher le maillage de fabriquer un espace infini.

Si vous cherchez une approche opérationnelle (sans vous disperser), l’ordre qui donne le plus de résultats est souvent :

1) mesurer (logs + GSC), 2) sortir les facettes utilitaires de l’index (noindex,follow), 3) stabiliser les canonicals + normaliser les variantes, 4) nettoyer sitemap + réduire le maillage vers le “bruit”, 5) puis optimiser performance/DB pour augmenter la capacité de crawl (et la conversion).

Le reste n’est que du réglage fin — mais sans ces fondamentaux, vous ne ferez que déplacer le problème.