Facettes et indexation PrestaShop : laisser Google lire les bonnes pages, pas chaque combinaison de filtres

Chaque combinaison de filtres d’une catégorie PrestaShop porte une adresse propre, introduite par le paramètre « q ». Trois outils décident de son sort dans Google : le fichier robots.txt (liste des adresses interdites d’exploration), la balise noindex (consigne de ne pas afficher la page) et la canonique (adresse que Google doit préférer). Ils ne s’additionnent pas sans précaution. Au 14 octobre 2026, d’après le code de PrestaShop, les versions 9.0.0, 9.1.5 et 9.2.0 appliquent le blocage et le noindex ensemble ; la 8.2.8 ne pose ni l’un ni l’autre et s’en remet à la canonique.

• Une boutique PrestaShop produit une adresse par combinaison de filtres
• Un robots.txt empêche l’exploration d’une adresse, sans l’effacer de l’index
• La balise noindex n’agit que sur une page que Google peut explorer
• La canonique oriente Google sans l’obliger
• Le code de PrestaShop 9 bloque les filtres dans robots.txt et les marque noindex en même temps
• Une combinaison de filtres très recherchée se traite comme une catégorie
• La Search Console montre, adresse par adresse, ce que Google a retenu
• Une boutique dont les filtres restent hors de l’index n’a rien à corriger
• Sources consultées
• Foire aux questions

Une boutique PrestaShop produit une adresse par combinaison de filtres

Le module de recherche à facettes (Faceted search, ps_facetedsearch) inscrit les filtres cochés dans le paramètre « q » de l’adresse de la catégorie. D’après son code, une barre oblique sépare les facettes et un tiret relie un filtre à ses valeurs : « ?q=Couleur-Noir/Taille-M » désigne les produits noirs en taille M. Scénario : une catégorie dotée de quatre filtres de dix valeurs chacun dépasse dix mille combinaisons.

Les robots de Google explorent beaucoup d’adresses de filtres avant d’en reconnaître la faible valeur, et il leur reste moins de temps pour les pages nouvelles. D’après le code du module, le gabarit livré pose un attribut rel="nofollow" sur les liens de filtres. Votre thème peut le remplacer : ouvrez le code source d’une catégorie pour vérifier. La rapidité et la pertinence du module relèvent de la recherche à facettes.

Un robots.txt empêche l’exploration d’une adresse, sans l’effacer de l’index

Le fichier robots.txt sert à régler le trafic d’exploration ; la page de Google consacrée à ce fichier précise qu’il ne sert pas à garder une page hors de Google. Une adresse bloquée peut apparaître dans les résultats, sans description, dès qu’un autre site la lie. Le rapport Pages de la Search Console nomme ce cas « Indexée malgré le blocage par le fichier robots.txt » (« Indexed, though blocked by robots.txt »).

Le blocage garde sa valeur pour des filtres sans intérêt de recherche. La page de Google sur la navigation à facettes le range en première option. Son exemple interdit à Googlebot les paramètres de filtre et autorise une seule liste non filtrée.

La balise noindex n’agit que sur une page que Google peut explorer

Une page marquée noindex quitte les résultats de Google une fois explorée et la balise (ou l’en-tête X-Robots-Tag) lue, même si d’autres sites la lient. Le fichier robots.txt ne doit pas la bloquer : la consigne resterait illisible et la page pourrait paraître. Une règle « noindex » écrite dans le robots.txt lui-même n’est pas prise en charge par Google.

La canonique oriente Google sans l’obliger

La page de Google sur les adresses dupliquées qualifie la canonique de signal fort et précise qu’aucune méthode de canonisation n’est obligatoire. Elle déconseille le robots.txt pour désigner une canonique, et le noindex pour départager deux adresses d’un même site : l’annotation canonique reste la voie préférée.

Côté PrestaShop, la canonique d’une liste filtrée est l’adresse de la catégorie, plus le numéro de page quand il dépasse 1 ; « q » n’y figure pas. Ce comportement ressort du code des versions 8.2.8, 9.0.0, 9.1.5 et 9.2.0. La documentation utilisateur de PrestaShop 8 précise que les adresses canoniques dépendent aussi de la balise placée par le thème. Dans la Search Console, un filtre rattaché à sa catégorie apparaît sous « Autre page avec balise canonique correcte » (« Alternate page with proper canonical tag »). Google indique qu’aucune action n’est nécessaire pour ce motif.

Décrire mon besoin →

Le code de PrestaShop 9 bloque les filtres dans robots.txt et les marque noindex en même temps

D’après le code de PrestaShop 9, la liste d’une catégorie reçoit la consigne noindex dès que « q » ou « order » figure dans l’adresse. Le robots.txt généré bloque « ?q= » comme « ?order= ». Un commentaire du code demande que les deux réglages restent alignés. Le tableau reprend ce que le code de chaque version fait.

Les versions 1.7.8.11, 8.0.0, 8.1.7 et 8.2.0 se comportent comme la 8.2.8 sur les deux premiers points.

Sur une boutique 9 au robots.txt fraîchement généré, Google n’explore pas les adresses « ?q= » et ne lit pas le noindex. Le blocage agit seul, avec sa limite : une adresse liée ailleurs peut entrer dans l’index sans description.

Une boutique montée de 8.2 en 9 garde le fichier de l’ancien code tant que personne ne clique sur « Générer le fichier robots.txt ». Ce bouton se trouve dans Paramètres de la boutique > Trafic et SEO > SEO et URL (en anglais Shop Parameters > Traffic & SEO > SEO & URLs, « Generate robots.txt file »). Sans ligne « ?q= », Google lit alors le noindex. Ce raisonnement est une déduction du code et de la documentation de Google : seul l’affichage de /robots.txt tranche pour votre boutique.

Une combinaison de filtres très recherchée se traite comme une catégorie

D’après le code de PrestaShop 9, toute liste filtrée porte noindex : « chaussures de randonnée imperméables », obtenue par deux filtres, ne peut pas se positionner comme filtre. Il lui faut une sous-catégorie, avec sa propre adresse, son propre texte et sa propre canonique. Sous la 8.2.8, la liste filtrée n’est pas en noindex mais sa canonique désigne la catégorie : elle ne vise pas de position non plus.

Le rapport Performances de la Search Console liste les requêtes réellement tapées. Une combinaison qui s’y trouve déjà mérite une sous-catégorie. Le texte de ces pages relève des contenus de catégories.

La Search Console montre, adresse par adresse, ce que Google a retenu

Le rapport Pages et l’outil d’inspection d’URL disent si Google a gardé un filtre, sa catégorie ou aucun des deux. Cinq relevés établissent ce que fait votre boutique.

• Ouvrez /robots.txt et cherchez « ?q= » : sa présence indique le blocage.
• Affichez le code source d’une page filtrée : la balise « robots » et le lien canonique y figurent.
• Dans le rapport Pages, ouvrez les exemples de chaque motif et repérez les adresses contenant « q= ». Motifs à lire : « URL bloquée par le fichier robots.txt » (« URL blocked by robots.txt »), « URL marquée “noindex” » et « Explorée, actuellement non indexée » (« Crawled - currently not indexed »).
• Dans l’outil d’inspection d’URL, comparez la canonique déclarée à celle que Google a retenue.
• Appliquez une combinaison de filtres sans produit et relevez le code HTTP dans l’onglet Réseau (Network) des outils du navigateur. Google recommande un code 404 pour une combinaison sans résultat.

Une boutique dont les filtres restent hors de l’index n’a rien à corriger

Si le rapport Pages ne montre les adresses « q= » que sous des motifs d’exclusion (blocage, noindex, canonique vers la catégorie), l’état est celui qu’on cherche.

Attendre se justifie après chaque changement : le motif « Explorée, actuellement non indexée » peut évoluer sans intervention.

Éditer le robots.txt à la main avant de connaître la version expose à une perte. Le bouton de génération remplace le fichier existant, et la documentation utilisateur de PrestaShop 8 conseille d’ajouter ses propres règles après la génération.

Reportez ces relevés dans le message du formulaire de cette page. Aucun accès à la Search Console ne s’y transmet.

Décrire mon besoin →

Sources consultées

• Google, « Managing crawling of faceted navigation URLs », mis à jour le 18 décembre 2025, consulté le 14 octobre 2026.
• Google, « Introduction to robots.txt », mis à jour le 10 décembre 2025, consulté le 14 octobre 2026.
• Google, « Block Search indexing with noindex », mis à jour le 10 décembre 2025, consulté le 14 octobre 2026.
• Google, « How to specify a canonical URL with rel="canonical" and other methods », mis à jour le 10 juillet 2026, consulté le 14 octobre 2026.
• Google, « Pagination and incremental page loading », section « Avoid indexing URLs with filters or alternative sort orders », mis à jour le 10 décembre 2025, consulté le 14 octobre 2026.
• Google, aide Search Console, « Page indexing report », consulté le 14 octobre 2026.
• PrestaShop, code source du cœur, fichiers classes/Tools.php, classes/controller/ProductListingFrontController.php et controllers/front/listing/CategoryController.php, versions 8.2.8, 9.0.0, 9.1.5 et 9.2.0, consulté le 14 octobre 2026.
• PrestaShop, code source du module ps_facetedsearch, branche de développement, fichiers src/URLSerializer.php et views/templates/front/catalog/facets.tpl, consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de la version 8, « SEO and URLs » et sa version française « SEO et URL », consulté le 14 octobre 2026.
• PrestaShop, code du cœur 9.2.0, gabarit robots_file_generation.html.twig et fichier AdminNavigationMenu.xlf, pages des versions publiées sur GitHub, consulté le 14 octobre 2026.
• PrestaShop, spécifications de la version 1.7, « ps_facetedsearch specifications », consulté le 14 octobre 2026.

Foire aux questions

Faut-il choisir entre robots.txt et noindex ?

Oui, selon le but. Le blocage économise l’exploration. Pour faire sortir des adresses déjà indexées, l’aide de la Search Console demande de retirer le blocage puis de poser noindex : Google doit pouvoir lire la balise.

Le module natif propose-t-il des options d’indexation des filtres ?

La spécification du module pour PrestaShop 1.7 décrit une option qui autorise les robots à utiliser les filtres de condition, de disponibilité et de fabricant. La branche de développement actuelle du module n’en garde aucune trace, ni de réglage noindex. Ouvrez Modules > Gestionnaire de modules (Module Manager), puis le bouton Configurer (Configure) du module, pour voir ce que votre version expose.

Un module de filtres tiers change-t-il la réponse ?

Oui : il peut remplacer la fabrication des adresses et poser ses propres consignes. Le code de PrestaShop ne le couvre pas. Appliquez-lui les mêmes relevés : fichier /robots.txt, code source d’une page filtrée, rapport Pages. La documentation du module reste la référence pour ses réglages.

Le tri des produits suit-il les mêmes règles ?

Le paramètre « order » est bloqué dans le robots.txt généré par toutes les versions lues, de la 1.7.8.11 à la 9.2.0. Le noindex qui l’accompagne n’existe que dans les versions 9 lues. Google cite lui-même un tri par prix, de forme « ?order=price », parmi les variantes d’une même liste à écarter de l’index.

Combien de temps faut-il pour que Google retire ces adresses ?

Selon la page de Google sur le noindex, revisiter une page peut prendre des mois, suivant son importance. La balise n’est lue qu’à la prochaine exploration. Le rapport Pages et l’outil d’inspection d’URL montrent l’état courant d’une adresse : relevez-le avant le changement, puis comparez à intervalles réguliers.