Navigation à facettes PrestaShop : stratégie SEO pour filtres, tri et pagination

76 % des acheteurs en ligne utilisent les filtres de navigation avant d’acheter, selon le Baymard Institute. Sur PrestaShop, ce même module de filtres peut générer plus de 10 000 combinaisons d’URL sur un catalogue de seulement 200 produits et 5 attributs. La question n’est donc pas de savoir s’il faut activer les facettes, mais comment éviter qu’elles noient votre budget de crawl, dont un risque précis qu’aucun guide généraliste ne surveille : les combinaisons qui ne renvoient aucun produit.

Les combinaisons à zéro produit : le risque que personne ne surveille

Les guides sur la navigation à facettes PrestaShop traitent presque tous le même problème : la duplication de contenu entre combinaisons de filtres proches. Ils passent à côté d’un second risque, distinct du premier et souvent plus dommageable : les combinaisons de filtres qui ne correspondent à aucun produit. Combinez un filtre couleur rare avec une taille peu courante, et le module de recherche génère malgré tout une URL valide, avec un code 200, affichant « aucun produit ne correspond à votre sélection ». Cette page est crawlable et indexable comme n’importe quelle autre page de filtre, alors qu’elle ne contient strictement aucun contenu utile.

Ce n’est pas un problème de duplication : c’est un problème de contenu fin, comparable à une page en soft-404 aux yeux de Google. Une balise canonical vers la catégorie parente ne suffit pas toujours à corriger le signal, parce que ces pages continuent d’être crawlées à chaque nouvelle combinaison possible, gaspillant du budget de crawl sur des URLs qui n’existeront peut-être jamais en tant que contenu réel. Le test pour vérifier si vous êtes concerné : croisez volontairement deux filtres rares sur votre boutique et regardez ce qui s’affiche. Si la page renvoie un code 200 avec zéro résultat et reste accessible sans restriction, elle est probablement déjà indexée ou en passe de l’être. La correction spécifique consiste à appliquer un noindex automatique, généré par condition (0 résultat = noindex), plutôt qu’une simple canonical qui ne règle pas le gaspillage de crawl.

La stratégie en trois niveaux

Une fois ce risque spécifique traité, la gestion générale des facettes PrestaShop se structure en trois niveaux de décision, à appliquer combinaison par combinaison plutôt qu’en bloc.

Niveau 1 : noindex par défaut sur toute combinaison de filtres

C’est le réglage de départ le plus sûr : toute page générée par une combinaison de filtres reçoit une balise noindex, follow tant qu’elle n’a pas été explicitement validée pour l’indexation. Le follow est important : il préserve la transmission du maillage interne vers les fiches produit, ce qu’un blocage via robots.txt ne permet pas puisqu’il empêche même le crawl.

Niveau 2 : indexation sélective sur les combinaisons à volume de recherche réel

Certaines combinaisons méritent l’exception, quand elles correspondent à une requête que vos clients tapent réellement dans Google : « chaussures running homme » ou « baskets blanches femme » sont des exemples de combinaisons filtre + catégorie qui portent un volume de recherche propre, largement supérieur à l’intérêt SEO d’une combinaison filtre au hasard. Ces pages-là méritent d’être retirées du noindex par défaut, et idéalement enrichies d’un texte de présentation propre pour ne pas se limiter à une simple liste de produits filtrés.

Niveau 3 : canonical vers la page parente pour tout le reste

Pour les combinaisons qui ne rentrent dans aucune des deux catégories précédentes (ni volume de recherche propre, ni page à zéro produit), une balise canonical pointant vers la catégorie parente consolide les signaux sans bloquer le crawl ni l’indexation complète de la page.

Le cas particulier de la pagination

La pagination des catégories (?page=2, ?page=3) suit une logique différente des filtres : chaque page contient des produits distincts, ce n’est donc pas du duplicate content au sens strict. La bonne pratique consiste à donner à chaque page paginée sa propre balise canonical, pointant vers elle-même et non vers la page 1, précisément parce que le contenu diffère d’une page à l’autre. L’erreur fréquente consiste à canonicaliser systématiquement toutes les pages vers la page 1 : cela retire de l’index des produits qui n’apparaissent que sur les pages suivantes, avec un effet inverse à celui recherché.

Configuration technique sur PrestaShop

Sur PrestaShop 1.7 et 8.x, la variable native {$urls.canonical_url} gère la canonical dans le thème Classic ; vérifiez qu’elle reste bien active si vous utilisez un thème tiers, où elle est parfois omise. Sur PrestaShop 1.6, la méthode {$link->getProductLink($product)} est à privilégier plutôt qu’une reconstruction manuelle de l’URL, plus sujette aux erreurs de paramètres oubliés. Pour le blocage de crawl complémentaire, le fichier robots.txt, accessible depuis Préférences puis SEO et URLs, doit exclure spécifiquement les paramètres dynamiques de tri (order) et de recherche (q), sans bloquer les paramètres de filtre eux-mêmes si vous appliquez la stratégie en trois niveaux ci-dessus : un blocage robots.txt et une stratégie noindex fine ne se combinent pas, le premier empêche Google de découvrir la balise noindex de la page qu’il ne peut pas crawler.

Checklist de mise en œuvre

1. Testez une combinaison de filtres raresConfirmez si votre boutique génère des pages à zéro produit indexables, avant tout le reste.
2. Auditez les combinaisons déjà indexéesCroisez le rapport de couverture Search Console avec un export des URLs de filtres pour repérer celles sans contenu utile.
3. Appliquez le noindex par défaut sur les filtresRéglage de départ, à lever ensuite au cas par cas.
4. Identifiez les combinaisons à volume de recherche réelCroisez vos filtres les plus utilisés avec un outil de mots-clés pour repérer celles à sortir du noindex.
5. Corrigez la canonical de paginationChaque page paginée pointe vers elle-même, jamais systématiquement vers la page 1.
6. Nettoyez le robots.txtExcluez les paramètres de tri et de recherche, sans bloquer le crawl des filtres sous stratégie noindex fine.