Robots sur les facettes : pourquoi ps_layered_filter_block explose

Vous videz la table du cache des filtres, elle a repris des centaines de mégaoctets quelques jours plus tard, et vos catégories rament à des heures où personne n’achète. Le plus souvent, la cause vient de l’extérieur : des robots parcourent les facettes de votre boutique PrestaShop et demandent une combinaison de filtres après l’autre. Sur les boutiques que nous hébergeons, 57 % des requêtes reçues en septembre 2026 venaient de robots.

Si vous voulez seulement vider la table, c’est dans notre index des tables : vider ps_layered_filter_block sans risque. Si elle se remplit de nouveau, il faut empêcher les robots des facettes d’y écrire. Les parades sont classées de la plus sûre à la plus technique, pour PrestaShop 1.7, 8 et 9.

Les signes que des robots balaient vos filtres

Trois endroits à regarder, tous en lecture seule :

Où regarder	Ce qui doit vous alerter
phpMyAdmin, liste des tables de la base, colonne Taille	La table du cache des filtres (préfixe de vos tables, puis layered_filter_block) parmi les plus grosses. Pour un simple cache, des centaines de mégaoctets ne sont pas normales ; des marchands rapportent sur GitHub et sur les forums des tables de 13 ou 40 Go.
Journal d’accès du serveur web (panel de l’hébergeur)	Des milliers d’adresses de catégorie avec ?q=, presque chacune venue d’une adresse IP différente, sans passage au panier.
Journal d’erreurs PHP (chez l’hébergeur)	« Uncaught … CoreException: Invalid argument » ou « Invalid SortOrder direction » : ce sont les faux ?order=.

Autre symptôme possible : des pointes de charge de la base à des heures creuses, 3 h du matin par exemple (cas décrit dans un ticket GitHub de PrestaShop). Si rien de tout cela ne ressort et que la boutique reste lente, la cause est ailleurs : commencez par notre diagnostic de lenteur PrestaShop.

Pourquoi le cache des filtres grossit

Une ligne par combinaison de filtres

Le module « Navigation à facettes » (ps_facetedsearch, livré avec PrestaShop 1.7, 8 et 9) écrit les filtres cochés dans l’adresse, après ?q= : ?q=Couleur-Bleu-Rouge/Taille-M. Pour ne pas recalculer le bloc de filtres à chaque affichage, il le range dans un cache, la table ps_layered_filter_block.

D’après le code du module, de la 3.14 (livrée avec la 1.7.8.11) à la 5.1 (livrée avec la 9.2), la clé de ce cache combine six éléments : la boutique, la devise, la langue, le pays, la page de liste (catégorie, marque ou fournisseur) et les filtres cochés. Chaque combinaison jamais vue coûte un calcul complet, plusieurs requêtes SQL, puis une ligne de plus, qui contient tout le bloc de filtres. Le tri et le numéro de page n’entrent pas dans la clé.

Les liens des filtres portent un rel="nofollow" dans le gabarit du module. Google et Bing le prennent comme une indication, les aspirateurs de catalogue l’ignorent. Selon Google, un nofollow ne suffit que s’il est posé sur tous les liens vers ces pages, y compris ceux des autres sites.

Chaque combinaison ralentit aussi vos catégories. Elle a une adresse unique, qu’aucun cache de page ne sert : chaque requête de robot fait travailler PHP et la base et, en mutualisé, consomme le même quota SQL que vos clients.

Le prix et le poids : des combinaisons sans fin

Les glissières de prix et de poids prennent leurs bornes telles quelles dans l’adresse (lu dans le code du module, de la 3.14 à la 5.1). Rien ne les compare aux prix réels avant le calcul de la clé : chaque paire de valeurs inventée crée une ligne. Le nombre de combinaisons n’a alors plus de limite.

C’est aussi par ce cache qu’est passée la faille critique de juin 2026 sur le module, notée 10 sur 10 et exploitable sans compte (avis de sécurité CVE-2026-54159) : versions 3.0.0 à 4.0.3, corrigée en 4.0.4. Vérifiez ce point en premier (voir « Avant de commencer »).

Ce qui la vide, et ce qui ne la vide jamais

Le module vide toute la table quand vous enregistrez un produit, un attribut, une caractéristique ou une règle de prix catalogue. Il la vide aussi quand vous ajoutez ou supprimez une catégorie, quand vous enregistrez ses réglages, et avec le bouton « Vider le cache ». Aucune limite de taille ni d’âge n’existe. Un catalogue qui bouge chaque jour garde une table modeste ; un catalogue stable la laisse grossir jusqu’au prochain vidage.

Sa voisine ps_layered_price_index n’a rien à voir avec les robots : elle suit le catalogue, pas le trafic. Si c’est elle qui pèse, voyez son entrée dans l’index des tables de la base.

Ce que nous voyons passer sur nos serveurs

Sur les boutiques que nous hébergeons, mesuré en 2026 :

La plus forte vague de filtres que nous avons documentée cet été visait une seule page de liste : 66 000 requêtes par jour, 32 000 combinaisons de filtres différentes, des navigateurs récents annoncés et un référent qui imitait la boutique elle-même. Les aspirateurs de facettes représentent 42 % des bannissements posés sur nos serveurs de juillet au 1er octobre 2026, souvent avec de faux ?order=.

Une limite de requêtes par adresse IP ne voit donc rien passer. Ces vagues s’arrêtent seules, puis reprennent : une baisse un matin ne prouve pas qu’une parade fonctionne.

Les faux ?order= qui font planter vos catégories

Le paramètre order (le tri) ne fait pas grossir la table. Les robots y mettent pourtant n’importe quoi : ?order=1003432845, ?order=product.name.a.

De la 1.7.8.11 à la 9.2.0, le cœur passe cette valeur à SortOrder::newFromString(). Avec moins de trois éléments séparés par des points, il lève « Invalid argument » ; avec un sens de tri autre que asc, desc ou random, « Invalid SortOrder direction ». Rien, dans le cœur, ne rattrape cette exception. Boutique en production (mode debug désactivé), la page peut alors répondre par une erreur 500 ; nous l’avons reproduit sur notre banc de test en août 2026.

Ce que vous trouverez dans le journal d’erreurs PHP (début des lignes) :

PHP Fatal error:  Uncaught PrestaShop\PrestaShop\Core\Exception\CoreException: Invalid argument
PHP Fatal error:  Uncaught PrestaShop\PrestaShop\Core\Product\Search\Exception\InvalidSortOrderDirectionException: Invalid SortOrder direction `a`. Expecting one of: `ASC`, `DESC`, or `RANDOM`.

Vos clients ne tombent jamais dessus, aucun lien de la boutique ne produit ces valeurs. Ces erreurs noient les journaux et font sonner la supervision pour rien. Le bug est signalé depuis décembre 2023 (ticket #34819) ; le correctif proposé vise la 9.3.0 et n’est pas encore intégré au 3 octobre 2026.

Le robots.txt n’y peut rien : ?order= y est déjà interdit depuis la 1.7.4, et ces robots l’ignorent. La protection se pose devant PHP, sans rien changer à PrestaShop : une règle qui refuse les valeurs de tri mal formées (détail en parade 3).

Ce que PrestaShop fait déjà, selon votre version

Depuis la 9.0.0, le cœur bloque ?q= dans le robots.txt qu’il génère. En 1.7 (depuis la 1.7.4) et en 8, il y interdit ?order=, mais pas ?q=.

Ce que fait le cœur	1.7 et 8	9
?q= dans le robots.txt généré	non	oui, depuis la 9.0.0
noindex sur les pages filtrées ou triées	non	oui, depuis la 9.0.0, si le thème affiche la balise
Module « Navigation à facettes » livré	3.14.1 en 1.7.8.11 (à mettre à jour) ; 4.0.4 en 8.2.8	4.0.4 en 9.1.5 ; 5.1.0 en 9.2.0

Le noindex ne soulage pas la base : pour le lire, le robot doit charger la page, donc faire calculer le bloc de filtres et écrire sa ligne. Seul le robots.txt évite la requête, auprès des robots qui le respectent, et encore faut-il qu’il soit à jour : une boutique passée de la 8 à la 9 garde l’ancien fichier, sans ?q=. Ouvrez-le ; s’il manque ces lignes, copiez vos ajouts manuels, régénérez-le, puis remettez-les.

Bloquer les robots sur les facettes : les parades dans l’ordre

Les trois premières parades ne demandent aucun module payant : le robots.txt, le module livré avec PrestaShop et l’offre gratuite de Cloudflare.

1. robots.txt : les deux lignes à ajouter, et le piège de « Générer le fichier robots.txt »

Ouvrez le fichier robots.txt à la racine de la boutique (FTP ou gestionnaire de fichiers de l’hébergeur). Sous la ligne User-agent: *, vérifiez la présence de ces lignes, et ajoutez celles qui manquent :

Disallow: /*?q=
Disallow: /*&q=
Disallow: /*?order=
Disallow: /*&order=

• L’étoile compte. Un Disallow: /?q=, sans étoile, ne vise que la page d’accueil.
• Vérifiez le fichier servi : ouvrez l’adresse de votre boutique suivie de /robots.txt dans le navigateur. Les lignes doivent y apparaître.
• Générer le fichier robots.txt depuis le back-office (Paramètres de la boutique > Trafic et SEO, bouton « Générer le fichier robots.txt ») réécrit tout le fichier. En 1.7 et 8, vos lignes q= disparaissent : revérifiez après chaque clic.
• Et Google ? Sa documentation sur la navigation à facettes recommande elle-même de bloquer ces adresses dans le robots.txt, et la 9 le fait d’office. Googlebot y passe plus ou moins selon la boutique : aucune requête de facette sur 2 322 relevées sur trois boutiques que nous hébergeons le 31/07/2026, plus de 100 000 en un mois sur une autre. Seule exception : des pages filtrées que vous avez fait indexer exprès, avec un module de pages SEO. Parlez-en avant.

Cette parade arrête les robots qui déclarent respecter le robots.txt : Google, Bingbot, le robot d’indexation de Meta, les outils d’analyse de liens (l’un d’eux envoyait près de 18 000 requêtes de filtres par jour à une seule boutique fin juillet 2026). Contre les aspirateurs, qui passent outre, c’est la parade 3.

2. Le module : version, cache et vidage planifié

Tout se passe dans Modules > Gestionnaire de modules > « Navigation à facettes ».

1. La version. Regardez celle du module, pas celle de PrestaShop. Elle s’affiche sous son nom (« v3.14.1 ») ou, par FTP, dans modules/ps_facetedsearch/config.xml. Il faut 4.0.4 ou plus, installable dès PrestaShop 1.7.7 ; la 1.7.8.11 est livrée avec la 3.14.1, vulnérable. Avant la mise à jour, sauvegardez les fichiers et la base. Un module de filtres touche toutes vos catégories, donc passez d’abord par une copie de test de la boutique si vous en avez une. Sans copie de test, faites la mise à jour quand même, et sans attendre, vu la gravité de la faille.
2. Après la mise à jour. La mise à jour ferme la porte mais ne retire rien de ce qui aurait pu être déposé avant : si vous étiez en dessous de 4.0.4, regardez si modules/ps_facetedsearch/ contient des fichiers que personne n’a posés, sans rien supprimer (voir « Où s’arrêter »).
3. Le cache. Dans Configurer, laissez « Activer le système de cache » sur Oui. Le couper arrête la croissance de la table, mais chaque page filtrée est alors recalculée en entier, robots compris : vous échangez du disque contre du processeur. Ne le coupez que si, disque presque plein, la table se remplit de nouveau en quelques heures après un vidage, et seulement le temps de poser les parades 1 et 3.
4. Le vidage chaque nuit. Dans le bloc « Index et caches », copiez l’adresse affichée sous « Vider le cache des blocs : » et faites-la appeler chaque nuit par une tâche planifiée chez l’hébergeur ; le module recommande lui-même des tâches cron quotidiennes ou hebdomadaires. La table ne garde plus qu’une journée de combinaisons. Cette adresse contient un jeton : ne la publiez nulle part. Le lendemain matin, vérifiez dans phpMyAdmin que la table est bien plus petite que la veille ; sinon, la tâche n’a pas tourné.
5. Les glissières inutiles. Si personne ne filtre par poids, retirez le « Filtre des poids de produits (glissière) » de vos modèles de filtres : comme celle des prix, cette glissière accepte n’importe quelles bornes dans l’adresse.

3. Cloudflare ou votre pare-feu : vérifier les visiteurs des pages filtrées

Le principe vient de nos captures. Quand un client clique sur un filtre, son navigateur indique que la requête part d’une page de la boutique : en-tête Sec-Fetch-Site: same-origin, que votre thème recharge la page ou non. Les robots chargent l’adresse filtrée directement, comme une adresse tapée, ou n’envoient pas cet en-tête du tout.

Pas de Cloudflare devant la boutique ? Le mettre en place touche les DNS et les certificats : pas en pleine vague. Demandez d’abord à votre hébergeur s’il peut appliquer la même logique sur son pare-feu.

Sur Cloudflare, une règle personnalisée du pare-feu (WAF), possible dès l’offre gratuite, avec l’action Managed Challenge : une vérification que les vrais navigateurs passent, pas un blocage. L’expression en place sur des boutiques que nous hébergeons depuis août 2026 :

(http.request.uri.query contains "q="
 and not cf.client.bot
 and not any(http.request.headers["sec-fetch-site"][*] == "same-origin"))

• not cf.client.bot laisse passer les robots que Cloudflare a vérifiés, Google compris. Bing et Meta passent donc aussi : pour eux, c’est la parade 1.
• Qui verra la vérification. Un visiteur qui arrive directement sur une adresse filtrée, depuis Google, un e-mail ou un favori, la passe puis navigue normalement. Les clics sur les filtres ne sont pas concernés, sauf sur un navigateur trop ancien pour envoyer l’en-tête : le clic part en arrière-plan, où la vérification ne peut pas s’afficher, et le filtre échoue. D’où le test ci-dessous, et un coup d’œil sur les navigateurs de vos clients dans vos statistiques.
• Testez la règle après l’avoir créée. Collez une adresse filtrée dans une fenêtre privée : la vérification doit apparaître. Cliquez un filtre depuis la catégorie : rien ne doit apparaître. Nous avons déjà vu deux fois une règle enregistrée sans erreur qui ne filtrait rien : ne vous fiez jamais à une règle non testée.
• Inutile d’ajouter une limite par adresse IP (voir nos chiffres) ; en offre gratuite, la limitation de débit de Cloudflare ne sait de toute façon pas viser q=.
• Le serveur fermé à tout sauf Cloudflare. Un robot qui connaît l’adresse IP du serveur passe à côté de Cloudflare et de toutes vos règles. Demandez à votre hébergeur de n’accepter que les adresses de Cloudflare. Cet été, sur une boutique, le trafic que la vérification semblait laisser passer arrivait en réalité par là.
• Si le volume ne baisse pas alors que le serveur est bien fermé, passez à un défi interactif. Gardez le blocage pour la fin : il refuse aussi les clients arrivés de Google, d’un e-mail ou d’un favori sur une page filtrée.

Pour les faux ?order=, la règle se pose sur le serveur web : refuser les valeurs qui n’ont pas la forme product.champ.sens (asc, desc ou random), en excluant le dossier d’administration, dont la page Stocks utilise aussi order. Demandez-la à votre hébergeur ou à votre développeur ; elle peut attendre que les parades 1 à 3 soient en place.

Prudence avec le Bot Fight Mode : d’après Cloudflare, aucune règle ne permet de l’éviter et il peut défier du trafic d’API. Si vous l’activez, vérifiez aussitôt les retours de vos modules de paiement et, le lendemain matin, que la table a bien été vidée. Mode Under Attack et limites du mutualisé : voyez notre article sur le pic de trafic PrestaShop.

4. Vider la table, et juger les parades

Avec la tâche de la parade 2, la table est vidée dès la première nuit ; sans elle, videz-la une fois les parades 1 et 3 en place, avec la méthode de vidage de notre index des tables. Relevez ensuite sa taille juste avant le vidage de la nuit : si elle reprend des centaines de mégaoctets en une journée, une parade ne fonctionne pas.

Revenir en arrière

Changement	Pour l’annuler
Lignes ajoutées au robots.txt	Remettre la copie téléchargée avant.
Règle Cloudflare	La désactiver ou la supprimer dans la liste des règles personnalisées. Effet immédiat.
Cache du module coupé	Remettre « Activer le système de cache » sur Oui. La table repart vide.
Glissière retirée	La remettre dans le modèle de filtres.
Table vidée	Rien à faire : le cache se reconstruit seul.
Tâche planifiée de vidage	La supprimer chez l’hébergeur. La table recommence à grossir sans limite.
Règle sur les faux ?order=	La retirer du serveur web ou du pare-feu. Effet immédiat.
Module mis à jour	Ne pas revenir sous la 4.0.4 : ce retour rouvrirait la faille. Si les filtres s’affichent mal, faites-vous aider. Si toute la boutique est en erreur, restaurez la sauvegarde faite juste avant : elle remet l’ancienne version, vulnérable, donc seulement le temps de corriger.

Où s’arrêter

Arrêtez-vous et faites-vous aider si :

• la table reprend des centaines de mégaoctets en quelques heures malgré les parades 1 à 3 ;
• le disque du serveur est plein, ou MySQL ne redémarre plus ;
• des catégories répondent en erreur 500 sans ?order= dans l’adresse : cette fois, vos clients sont touchés ;
• votre boutique est en 1.7.6 ou plus ancienne : la version corrigée du module ne s’y installe pas ;
• vous trouvez dans modules/ps_facetedsearch/ des fichiers que personne n’a posés : ne supprimez rien et lisez notre page boutique PrestaShop piratée ;
• vous n’avez la main ni sur le robots.txt ni sur Cloudflare, ou votre hébergeur ne peut rien poser devant PHP.

La purge elle-même est décrite dans l’index des tables de la base. Vous préférez ne pas y toucher ? Avec la maintenance PrestaShop, le module de filtres reste à jour, et si la table vous met en difficulté, le dépannage est inclus. Quand l’hébergeur ne peut rien poser devant PHP, notre hébergement, en option de la maintenance, s’en charge. Boutique déjà à l’arrêt : appelez le 09 72 03 59 17. Une intervention de dépannage PrestaShop démarre dès 150 € HT, prix fixe validé avant toute intervention.

Le suivi, à votre place : maintenance, et hébergement en option

Ces parades ne se posent pas une fois pour toutes : un clic sur « Générer le fichier robots.txt » efface vos lignes, et un robot finit parfois par trouver l’adresse directe du serveur. Les tenir vous-même demande de relever la table chaque jour et de retester la règle à chaque vague.

La maintenance PrestaShop, 69 € HT/mois, sans engagement, même si vous gardez votre hébergeur : le module de filtres reste à jour, le nettoyage courant de la base (journaux, statistiques, paniers abandonnés) tourne automatiquement chaque jour, et le dépannage est inclus, même si une vague passe malgré les parades. Sans maintenance, chaque dépannage coûte dès 150 € HT, prix fixe validé avant toute intervention. L’audit complet est offert au démarrage.

L’hébergement PrestaShop en option, 30 € HT/mois, soit 99 € HT/mois au total : nous tenons alors aussi le serveur. Sur les boutiques que nous hébergeons, nous posons la vérification Cloudflare des pages filtrées dès qu’une vague arrive, et nous bannissons les adresses récidivistes. Sur nos serveurs mutualisés, une tâche de nuit reconstruit aussi l’index des filtres, ce qui vide la table du cache. Le journal d’accès n’est plus à surveiller de votre côté.

• Serveur dédié : 269 € HT/mois au total.
• Disponibilité et lieu : SLA de 99 %, serveur dédié compris ; serveurs en France, sauvegardes quotidiennes chiffrées aux Pays-Bas, gardées 30 jours.
• Changer d’hébergeur : migration gratuite avec l’abonnement d’hébergement.

Questions fréquentes sur les robots et les facettes PrestaShop

Comment bloquer les robots sur les facettes PrestaShop ?

D’abord, le module « Navigation à facettes » en 4.0.4 ou plus : une faille critique passait par son cache. Ensuite, dans l’ordre : Disallow: /*?q= et Disallow: /*&q= dans le robots.txt, puis une règle Cloudflare qui vérifie les visiteurs des pages filtrées, sauf vos clients et les robots vérifiés.

Comment générer le fichier robots.txt de PrestaShop sans perdre les règles des filtres ?

Paramètres de la boutique > Trafic et SEO, bouton « Générer le fichier robots.txt ». En 1.7 et 8, le fichier généré bloque ?order= (depuis la 1.7.4) mais pas ?q= : ajoutez les deux lignes q= à la main, puis après chaque régénération, qui réécrit tout le fichier.

Faut-il désactiver le cache de la navigation à facettes ?

Non, sauf urgence de disque. Sans cache, la table cesse de grossir, mais chaque page filtrée est recalculée en entier, robots compris. Gardez-le actif, videz-le chaque nuit par une tâche planifiée et traitez les robots.

Bloquer ?q= dans le robots.txt fait-il perdre du référencement ?

Non, sauf pages filtrées indexées exprès avec un module SEO. Google recommande de bloquer les adresses de navigation à facettes dans le robots.txt, et PrestaShop 9 le fait dans le fichier qu’il génère.

Cloudflare gratuit suffit-il contre les robots des facettes ?

Souvent, avec une règle personnalisée du pare-feu : l’offre gratuite en accepte cinq. La limitation de débit gratuite ne sait pas viser q=. Si le volume ne baisse pas, vérifiez d’abord que le serveur ne répond qu’à Cloudflare, puis passez à un défi interactif.

Que veut dire « Invalid SortOrder direction » dans le journal ?

Un robot a appelé une catégorie avec un faux paramètre de tri ?order=. De la 1.7.8.11 à la 9.2.0, le cœur ne rattrape pas l’erreur : en production, la page peut répondre en 500. Vos clients ne sont pas touchés ; la protection se pose au pare-feu ou sur le serveur web.

ps_layered_price_index grossit aussi : est-ce à cause des robots ?

Non. Elle grossit avec le catalogue, pas avec le trafic : une ligne par produit, devise, boutique et pays (depuis la version 5.1 du module, pour chaque pays actif).

Nous confier la boutique

Indiquez l’adresse de votre boutique (celle que voient vos clients), sa version si vous la connaissez, la taille de ps_layered_filter_block si vous l’avez relevée, et ce que vous constatez : catégories lentes, erreurs 500, factures d’hébergement qui montent. N’écrivez ni mot de passe ni adresse d’administration dans le formulaire.

Réponse en moins d’une heure, 7j/7, de 8 h à 22 h. Boutique à l’arrêt : appelez le 09 72 03 59 17 ou passez par notre dépannage PrestaShop en urgence. La maintenance PrestaShop à 69 € HT/mois est sans engagement, audit complet offert.