SEO PrestaShop : maîtriser les URL de la navigation à facettes

Le calcul qui justifie l’arbitrage

Avant de discuter de mécanismes, il faut mesurer l’ampleur du problème. Prenons une catégorie avec cinq filtres :

Filtre	Valeurs
Marque	8
Taille	6
Couleur	5
Matière	4
Prix (tranches)	3

Si les combinaisons sont libres, le nombre d’URL atteignables pour cette seule catégorie est de 9 × 7 × 6 × 5 × 4 = 7 560, en comptant l’absence de filtre comme une valeur. Multipliez par le nombre de tris disponibles, puis par les pages de pagination, et une boutique de 200 produits expose des dizaines de milliers d’URL.

Le robot n’a pas un budget infini. Chaque URL de facette explorée est une exploration qui n’a pas servi à une page catégorie ou à une fiche produit.

Phase 1 — Relever les motifs d’URL réels

N’inventoriez pas les URL une par une : regroupez-les par motif. Sur une boutique PrestaShop, les motifs habituels sont :

• /{id}-{slug} — catégorie
• /{id}-{slug}#/{filtre}-{valeur} ou /{id}-{slug}?q=... — facette, selon la version et le module
• /{id}-{slug}?order=... — tri
• /{id}-{slug}?page=N — pagination
• /recherche?controller=search&s=... — recherche interne
• /{id}-{slug}-{attribut} — déclinaison, selon le thème

Pour chacun : combien d’URL, combien sont dans le sitemap, combien sont connues de Search Console, combien reçoivent des impressions. Ce tableau décide de tout ce qui suit.

Phase 2 — Décider par motif

La règle est unique : une URL n’est indexable que si une demande de recherche correspond à ce qu’elle affiche, et qu’elle a un contenu propre.

Motif	Décision courante	Mécanisme
Catégorie	Indexable	Canonical auto-référente, description propre
Facette à un filtre, à demande réelle	Indexable	Canonical auto-référente, titre et description spécifiques
Facette à un filtre, sans demande	Non indexable	Canonical vers la catégorie
Facette à deux filtres ou plus	Non indexable	Canonical vers la catégorie, lien non explorable
Tri	Non indexable	Canonical vers la version sans tri
Pagination	Indexable, non prioritaire	Canonical auto-référente sur chaque page
Recherche interne	Non générée pour les robots	Disallow et absence de lien
Déclinaison sans demande propre	Non indexable	Canonical vers le produit parent

Le point important : la pagination porte une canonical auto-référente, pas une canonical vers la page 1. Les pages 2 et suivantes contiennent des produits différents ; les canonicaliser vers la page 1 revient à déclarer que ces produits n’existent pas.

Phase 3 — Choisir le bon mécanisme

Les trois mécanismes ne sont pas interchangeables :

Canonical. L’URL reste explorable, le moteur lit la canonical et consolide les signaux. Consomme du budget de crawl, mais le signal est transmis correctement. C’est le défaut raisonnable pour les facettes.

noindex sur une URL explorable. L’URL est explorée, puis exclue de l’index. Plus radical qu’une canonical, utile quand la page n’apporte rien et qu’on ne veut pas consolider vers un parent.

Lien non généré. Le plus efficace sur le budget de crawl : si le thème ne produit pas de lien <a href> vers ces combinaisons, le robot ne les découvre pas. À combiner avec une canonical pour les URL déjà découvertes.

Disallow dans robots.txt. À réserver aux motifs qui ne doivent jamais être explorés, typiquement la recherche interne. Attention : une URL bloquée reste indexable si elle est liée depuis l’extérieur, et le moteur ne peut alors lire ni sa canonical ni son noindex. Bloquer n’est pas désindexer.

Phase 4 — Vérifier par re-crawl

C’est le contrôle objectif, et c’est pour cela que l’inventaire par motif de la phase 1 était nécessaire.

Avant : 14 312 URL explorables, dont 13 988 de facettes
Après : 1 204 URL explorables, dont 880 de facettes retenues

Autres contrôles, dans les semaines qui suivent :

• le nombre d’URL « explorées, non indexées » dans Search Console doit baisser ;
• la fréquence d’exploration des pages catégories doit augmenter, visible dans les statistiques d’exploration ;
• les impressions sur les requêtes de catégorie doivent progresser avant les clics.

Pourquoi les modules SEO cumulés aggravent le problème

Sur beaucoup de boutiques, deux ou trois modules écrivent les mêmes balises. Le résultat varie selon le gabarit : sur une page, c’est le module A qui produit la canonical ; sur une autre, le thème la réécrit.

Avant tout arbitrage de facettes, établissez qui produit quoi :

Balise	Produite par
title	?
meta description	?
canonical	?
meta robots	?
JSON-LD produit	?

Un seul responsable par ligne. Tant que ce tableau comporte des doublons, les corrections de facettes seront instables : elles seront écrasées à la prochaine mise à jour de l’un des modules.

Ce que l’arbitrage ne résout pas

Réduire les URL explorables améliore l’exploration des pages utiles. Cela ne rend pas ces pages pertinentes. Une catégorie sans description, sans guide de choix et sans réponse aux questions d’achat ne se classera pas mieux parce que le robot la visite plus souvent.

L’arbitrage des facettes est le premier maillon. L’enrichissement des catégories est le second, et c’est généralement là que se trouve le gain commercial.