Comment empêcher les filtres à facettes sur PrestaShop de générer des milliers d’URL indexables ?

Vous découvrez dans la Search Console des milliers d’URL de filtres explorées par Google, et vous pensiez que le module natif de PrestaShop les empêchait d’être indexées. Ce n’est pas le cas sur PrestaShop 8. La correction n’est intégrée au cœur qu’à partir de PrestaShop 9, et le blocage robots.txt seul ne désindexe rien. Voici comment reprendre le contrôle, en bloquant la génération plutôt qu’en rattrapant après coup.

Pourquoi 200 produits deviennent 10 000 URL

Le module Recherche à facettes de PrestaShop génère une URL à paramètre pour chaque sélection de filtre, du type /categorie?q=Couleur-Rouge/Taille-42. Chaque valeur ajoutée multiplie le nombre de combinaisons possibles. Un catalogue de 200 produits avec cinq attributs de dix valeurs dépasse rapidement les dix mille URL, et chacune est un lien cliquable présent dans le code HTML de la page, donc explorable par Google.

Trois familles de paramètres aggravent le phénomène. Le tri (orderby, orderway) recrée la même liste dans un ordre différent : quasi-doublon pur. Les fourchettes de prix produisent des bornes quasi infinies. L’ordre des paramètres dans l’URL, enfin, crée des doublons supplémentaires quand couleur=rouge&taille=42 et taille=42&couleur=rouge renvoient la même page sous deux adresses. Google résume l’enjeu : « si les robots d’exploration explorent des URL inutiles, ils ont moins de temps à consacrer aux nouvelles URL utiles ».

Ce que le module natif de PrestaShop 8 ne fait pas

Le mythe du « c’est déjà géré dans le cœur »

Sur la discussion GitHub officielle 40335, un contributeur PrestaShop affirme que le sujet est « déjà traité dans le cœur » : les URL contenant q= seraient en noindex et bloquées par robots.txt. Un marchand sous PrestaShop 8.2.3 lui répond, capture à l’appui, que ses URL de filtres n’ont aucune balise noindex et restent parfaitement indexables. Les deux ont raison, à une nuance de version près : le comportement dépend de la branche de PrestaShop et du thème utilisé.

robots.txt bloque le crawl, pas l’indexation

C’est le malentendu le plus coûteux. Le fichier robots.txt livré avec PrestaShop contient bien des règles Disallow sur certains paramètres. Mais une URL bloquée au crawl peut tout de même être indexée si un lien pointe vers elle, y compris un lien interne. Google l’écrit noir sur blanc dans sa documentation sur la navigation à facettes, et tous les guides sérieux sur le sujet le répètent : le robots.txt économise du budget de crawl, il ne désindexe pas. Pour retirer une page de l’index, il faut une balise noindex lisible par Google, donc une page qu’il a le droit d’explorer.

La correction n’arrive qu’avec PrestaShop 9

La pose automatique d’un noindex sur les URL de filtres par le module natif est intégrée au cœur à partir de PrestaShop 9.0.0, ou en appliquant le correctif référencé 37066 sur une version antérieure. Elle suppose en plus que le thème contienne la condition d’affichage {if $page.meta.robots !== 'index'} dans son gabarit d’en-tête : un thème personnalisé ou ancien qui ne la porte pas ne rendra jamais la balise, même sur PrestaShop 9. Concrètement, si vous êtes en 8.x avec un thème maison, vous devez agir vous-même.

Bloquer la génération, pas rattraper après coup

La combinaison qui fonctionne sur PrestaShop 8 empile trois mesures complémentaires. Aucune ne suffit seule.

Poser le noindex via un hook d’en-tête

Un petit module ou un override qui s’accroche au hook displayHeader insère une balise <meta name="robots" content="noindex, follow"> dès qu’une URL contient un paramètre de filtre, de tri ou une pagination au-delà de la page 1. Le follow est important : Google sort la page de l’index mais continue de suivre les liens vers les fiches produit, le maillage interne est préservé. C’est la seule mesure qui désindexe réellement, parce qu’elle laisse Google explorer la page pour y lire la directive.

Neutraliser l’exploration sur les paramètres exacts

Une fois la désindexation en route, le robots.txt reprend son rôle utile : économiser le budget de crawl. Ciblez les paramètres réels de votre installation, pas des motifs génériques : Disallow: /*?orderby=, Disallow: /*?orderway=, et le paramètre de filtre propre à votre version ou à votre module tiers. Testez toujours la règle dans l’outil dédié de la Search Console avant de déployer : un robots.txt trop large bloque des pages utiles. Attention à l’ordre des opérations : ne bloquez au crawl que les URL déjà désindexées, sinon Google ne pourra plus lire le noindex et les pages resteront dans l’index sans description.

Rendre les liens de filtres non explorables

La mesure de fond, celle que la discussion GitHub désigne comme la vraie solution : ne pas produire de lien crawlable du tout. Deux voies. Un rendu des filtres en AJAX qui ne change pas l’URL, ou qui n’utilise qu’un fragment après le # : Google indique explicitement que « la recherche Google n’accepte pas les fragments d’URL pour l’exploration et l’indexation ». Ou, à défaut, un data- attribut sur les liens de filtres avec un gestionnaire JavaScript, plutôt qu’un vrai href vers l’URL à paramètre. C’est le chantier le plus lourd, mais c’est celui qui tarit la source.

Nettoyer les URL déjà indexées

Les mesures ci-dessus arrêtent l’hémorragie ; elles ne vident pas l’index de ce qui y est déjà. Commencez par l’inventaire : un crawl complet exporte toutes les URL à paramètres, que vous croisez avec le rapport d’indexation de la Search Console pour distinguer ce qui est indexé, exploré sans indexation, ou orphelin. Un audit technique PrestaShop produit cet état des lieux sans y passer la semaine.

Ensuite, laissez le noindex, follow faire son travail : Google repasse sur les pages, lit la directive, les sort de l’index en quelques semaines à quelques mois selon la fréquence de crawl. Ne bloquez ces URL au robots.txt qu’une fois la sortie de l’index confirmée. Résistez à l’envie de traiter les cas « explorée, actuellement non indexée » un par un : sur des URL de filtres, c’est le résultat attendu. La question de savoir quelles pages filtrées méritent au contraire de rester dans l’index est traitée dans notre article sur la décision d’indexer ou non les pages filtrées.

Le cas des combinaisons à zéro résultat

Une combinaison de deux filtres rares renvoie souvent zéro produit, tout en générant une URL qui répond en HTTP 200 avec une page de gabarit vide. Google recommande de « renvoyer un code d’état HTTP 404 lorsqu’une combinaison de filtres ne renvoie pas de résultat ». Sur PrestaShop, ce comportement n’est pas natif : il demande une adaptation du contrôleur de catégorie pour renvoyer un vrai 404 quand le nombre de résultats est nul. Notre stratégie SEO de la navigation à facettes, filtres, tri et pagination détaille ce point et le réglage qui déclenche la désindexation automatique sur ces pages.

Plan d’assainissement des URL de filtres

1. Identifier votre version et votre thèmePrestaShop 8 ou 9, thème natif ou personnalisé, module de filtres natif ou tiers : cela détermine si le noindex est posé automatiquement ou non.
2. Poser le noindex, follow sur les URL à paramètresVia un hook displayHeader déclenché sur présence d’un paramètre de filtre, de tri ou d’une pagination au-delà de la page 1.
3. Faire l’inventaire des URL déjà indexéesCrawl complet exporté puis croisé avec le rapport d’indexation de la Search Console.
4. Attendre la sortie de l’index avant de bloquer au crawlLe noindex doit être lu par Google ; le Disallow ne vient qu’après confirmation.
5. Cibler le robots.txt sur vos paramètres réelsorderby, orderway et le paramètre de filtre exact de votre installation, testés dans l’outil de la Search Console.
6. Tarir la source : liens de filtres non crawlablesRendu AJAX sans changement d’URL, fragment #, ou gestionnaire JavaScript sur data- attribut plutôt que href.
7. Renvoyer un 404 sur les combinaisons videsAdaptation du contrôleur de catégorie pour un vrai code 404 quand le filtre ne donne aucun résultat.

Reprendre la main sur ce que Google explore

Empêcher les filtres à facettes de PrestaShop de générer des milliers d’URL indexables n’est pas un réglage unique, c’est trois mesures qui s’articulent : désindexer avec un noindex, follow lisible, économiser le crawl avec un robots.txt ciblé ensuite, et surtout ne plus produire de liens explorables. Le piège à connaître est que le module natif ne fait ce travail que sur PrestaShop 9, et seulement si le thème le prévoit. Sur PrestaShop 8, c’est à vous de le mettre en place, dans le bon ordre.