Gestion de catalogue WooCommerce : structuration SEO et filtres

Sur WooCommerce, ce sujet arrive rarement “proprement” sur la table. C’est plutôt un enchaînement : refonte, migration de thème, ajout d’un plugin de filtres “clé en main”, puis une demande marketing du type “on veut plus de pages qui rankent”. Côté tech, on voit vite le risque (URLs, règles, monitoring). Côté métier, on veut des pages collection qui sortent vite. Et entre les deux, les filtres finissent par créer des pages… mais sans intention, sans contenu, et souvent sans contrôle.

L’idée de cet article est simple : poser une méthode SEO-first pour structurer le catalogue, décider ce qui mérite une page indexable, et verrouiller le reste sans se retrouver avec 50 000 variantes crawlées “par défaut”.

L’essentiel en 30 secondes

Les filtres servent l’UX. Le risque apparaît quand des paramètres (attributs, tri, pagination, tracking) deviennent des URLs explorées et parfois indexées en masse. Le chemin le plus robuste combine :

(1) un catalogue gouverné (taxonomies propres), (2) des pages de collection dédiées pour les combinaisons à potentiel, (3) un contrôle strict (noindex/canonical/robots + monitoring logs/GSC).

Vos filtres ne sont pas un problème. Le problème, c’est de les laisser créer des pages “par accident”.

Le scénario est classique : l’utilisateur “filtre”, tout va bien à l’écran… mais techniquement, chaque filtre, chaque tri, chaque pagination peut produire une URL distincte. Pour Googlebot, c’est une machine à générer des variantes. Et quand on ajoute les paramètres marketing (UTM, gclid, fbclid), on obtient un volume d’URLs qui n’a plus grand-chose à voir avec votre offre.

L’impact SEO n’est pas toujours immédiat. Souvent, ça s’installe : exploration qui s’étire, pages stratégiques découvertes plus tard, signaux dilués, et un plafond de perf qui finit par apparaître. Google rappelle justement que la navigation à facettes peut générer énormément d’URLs et consommer des ressources de crawl si elle n’est pas maîtrisée.

Comme le contenu entre ces URLs est très proche (mêmes produits, juste réordonnés/filtrés), on se retrouve vite avec du duplicate content, de la cannibalisation (plusieurs pages “candidates” pour la même intention), et un crawl budget consommé sur du bruit plutôt que sur vos pages business.

Dans les audits, l’objectif n’est pas de “blâmer les filtres”, mais de repérer où l’explosion se produit vraiment.

Dans les logs, quelles familles d’URLs Googlebot visite le plus : paramètres de filtre, pagination, tri, tracking ?

Dans la Search Console, quelles catégories d’URL remontent dans Explorée – actuellement non indexée, Dupliquée, Alternative avec canonique appropriée ?

Et côté stack, quel plugin / thème pilote les URLs (query strings, réécriture, AJAX) ?

Exemples : /boutique/?filter_couleur=noir&orderby=price, /categorie/chaussures/?page=12, ?utm_source=...

Symptômes observables

On retrouve souvent les mêmes signaux. Dans la Search Console, une hausse d’URLs “Découverte mais non indexée” ou “Explorée – actuellement non indexée”, avec des patterns du type ?filter_ / ?orderby=. Dans les logs, Googlebot passe parfois plus de temps sur ?page= et des combinaisons de facettes que sur les catégories mères. Et côté SERP, ce sont des pages filtrées qui se positionnent, pas forcément bien, à la place de vos catégories/collections, ce qui crée mécaniquement de la cannibalisation.

La suite logique consiste donc à reprendre le sujet à la racine : la structure catalogue.

1) Structurer un catalogue WooCommerce “SEO-first”

Catégories : penser en intention, pas en arborescence infinie

Le réflexe fréquent, c’est d’empiler les sous-catégories : c’est rassurant, ça “range”. Mais à l’arrivée, on obtient des pages faibles, peu différenciées, et une arborescence que personne n’a envie de maintenir. À l’inverse, une catégorie performante se comporte plutôt comme une page d’intention : une promesse claire, un assortiment cohérent, et une raison d’exister.

Si une sous-catégorie ne raconte rien (pas de sélection, pas d’usage, pas de promesse), elle a de fortes chances de dupliquer une autre page. Les recommandations Google sur la structure e-commerce vont dans ce sens : rendre votre structure compréhensible et mettre en avant vos pages importantes.

Attributs (taxonomies) : la colonne vertébrale des filtres

WooCommerce laisse une grande liberté, ce qui rend la frontière floue en pratique. Pourtant, distinguer catégories et attributs, c’est surtout une question de gouvernance:

• Catégorie : un univers produit + une intention principale (ex. “Chaussures running”).
• Attribut : une dimension filtrable stable (ex. “Gore-Tex”, “Drop”, “Largeur”, “Pointure”, “Marque”).

Ce qui fait la différence au quotidien, ce sont des règles simples : qui crée un attribut, comment on le nomme, quelles valeurs sont autorisées, et comment on évite les doublons (“Noir” vs “noir”, “GORE TEX” vs “Gore-Tex”…). Sans ce cadre, vos données produit se dégradent et les filtres deviennent incohérents. Et c’est généralement là que les “pages accidentelles” commencent à proliférer.

Tags : utiles… à condition d’avoir un rôle clair

Les tags peuvent servir pour des sélections ponctuelles ou des besoins éditoriaux. Mais en e-commerce, ils finissent souvent en pages quasi vides, non gouvernées, parfois indexées “par erreur”. Si vous en gardez, l’idée est surtout de leur donner un rôle net (ex. “Nouveautés”, “Idées cadeaux”) et d’éviter d’en faire un second système de catégories.

Règle d’or : une intention = une page cible

Dès qu’une intention peut conduire à plusieurs URLs “plausibles” (catégorie, tag, filtre, tri…), Google se retrouve à arbitrer. Et dans la vraie vie, il choisit parfois la page la moins utile. L’objectif est donc d’aboutir à une page cible claire (catégorie, collection, landing). Le reste sert l’UX, mais ne doit pas devenir un candidat SEO par défaut.

Le moment délicat, c’est quand on veut une page pour chaque filtre. Pour trancher sans se raconter d’histoires, on revient souvent à trois questions :

quelle intention (et quelle valeur business) ? quels signaux de demande (GSC, PPC, recherche interne) ? et quel coût de maintenance (contenu, maillage, règles d’indexation) ?

Exemple : “Marque” indexable pour les 5 marques top ventes, mais “Couleur” réservée à l’UX.

Après cette structuration, on peut aborder les facettes sans tomber dans le débat “AJAX vs pas AJAX” — parce que le vrai sujet, c’est UX versus SEO.

2) Filtres (facettes) : séparer UX et SEO

Pourquoi les filtres créent du bruit

Un filtre, dans la majorité des implémentations, devient un paramètre d’URL. Et pour un crawler, un paramètre = une nouvelle page potentielle. Google documente explicitement le fait que la navigation à facettes peut générer énormément d’URLs et consommer des ressources de crawl, surtout quand chaque combinaison déclenche une page distincte.

Le bruit augmente encore avec le tri (orderby=price, orderby=rating), la pagination (page=2) et les paramètres marketing (utm_*, gclid). Même avec une bonne UX, la surface SEO peut exploser si on ne décide pas à l’avance ce qui doit exister (et surtout ce qui ne doit pas devenir indexable).

Une grille simple : universelles, différenciantes, bruit

Une approche pragmatique consiste à classer les facettes avant même de parler “indexation”.

• Les facettes universelles sont utiles partout (prix, disponibilité, taille) : elles servent l’UX, mais donnent rarement de bonnes pages SEO.
• Les facettes différenciantes changent réellement le sens de la sélection (Gore-Tex, largeur, type de semelle, usage) : ce sont les seules qui peuvent parfois justifier des pages dédiées.
• Le bruit, enfin, regroupe tout ce qui réordonne ou segmente sans intention (tri, affichage, tracking).

“Indexable” ne veut pas dire “pertinent” : comment décider ?

Une page filtrée devient “candidate SEO” seulement si elle coche des critères très concrets : demande identifiable, offre suffisante, promesse claire, contenu possible, et maillage naturel. Les bonnes pratiques e-commerce côté Google insistent sur l’accès aux pages clés sans noyer l’exploration dans des variantes infinies.

Cas	Décision	Exemple	Traitement
Intention claire + volume + offre stable	SEO candidate	“Chaussures running homme Gore-Tex”	Page collection dédiée indexable
Utile à la navigation mais trop combinatoire	UX only	couleur, taille, prix	Filtre AJAX/paramètre + non indexable
Paramètre de bruit	À bloquer	orderby=, utm_*, gclid	Neutralisation + règles crawl/index

Cette matrice pose le cadre. Ensuite, on peut dérouler une stratégie de production qui évite les “filtres sauvegardés” indexés n’importe comment.

3) La stratégie gagnante : pages de collection (landings) + contrôle du reste

Identifier les combinaisons à potentiel (ex. “chaussures running homme gore-tex”)

L’objectif n’est pas d’indexer des combinaisons “par principe”. Il est souvent plus rentable d’en sélectionner quelques dizaines, comme on construirait une gamme : requêtes GSC, campagnes SEA, recherche interne, marge, saisonnalité, stock. On vise des pages solides, pas des milliers de variantes fragiles.

Point important : une page collection doit rester cohérente même quand le stock bouge. Si elle disparaît dès que l’assortiment fluctue, vous créez une page SEO instable, et c’est rarement une bonne base.

Créer des pages dédiées : contenu, template, FAQ, maillage

Une page collection “propre” n’est pas juste un filtre sauvegardé. C’est une page gouvernée, avec une intention claire :

Un titre aligné avec la recherche (plutôt qu’un empilement d’attributs), un texte court utile (sélection, critères, usage), une FAQ qui répond aux objections, et un maillage interne naturel depuis les catégories mères, guides, pages marques, etc.

C’est aussi un bon moment pour cadrer la production, surtout si vous êtes en refonte ou en évolution de thème : mieux vaut décider maintenant comment naissent ces pages, plutôt que de corriger une dette plus tard. Si vous êtes en chantier, nos approches de développement et refonte WooCommerce vont dans ce sens : garder le contrôle côté build.

Laisser les filtres servir la navigation, et empêcher l’indexation du non-stratégique

Ici, une nuance fait gagner du temps : crawl (exploration) et indexation (présence dans l’index) ne sont pas la même chose. Google rappelle notamment que les directives meta robots (noindex, etc.) doivent être accessibles au robot pour être prises en compte.

noindex / canonical / robots.txt : quand utiliser quoi ?

Plutôt que de “tout mettre en robots.txt”, on gagne à raisonner par familles d’URLs.

• noindex aide à dire “tu peux crawler, mais n’indexe pas”. C’est pratique pour les pages filtrées utiles à l’UX, mais sans valeur SEO. Attention : si l’URL est bloquée via robots.txt, Google peut ne pas voir le noindex.
• canonical consolide plusieurs variantes vers une URL principale. Mais ce n’est pas une baguette magique : si les pages sont trop différentes, Google peut l’ignorer. Et “canoniser toute la pagination vers la page 1” est un classique… qui crée d’autres problèmes.
• robots.txt sert surtout à économiser du crawl sur des familles d’URLs sans intérêt. En revanche, ce n’est pas une garantie de non-indexation si des liens externes existent, et cela empêche Google de lire le contenu de ces URLs. Google évoque ce type d’usage pour éviter le crawl des facettes quand on ne veut pas qu’elles apparaissent dans la recherche.

Les arbitrages UX/SEO les plus “propres” sont souvent ceux qui restent simples à expliquer :

quelles facettes restent crawlables mais noindex (UX prioritaire) ? quelles familles sont en disallow robots.txt (bruit pur) ? et où est la frontière entre “collection SEO” et “filtre UX” (et qui valide) ?

Exemple : tri et tracking en disallow, facette prix en noindex, collections “Marque + Usage” en pages dédiées.

4) Mise en œuvre dans WooCommerce

Natif WooCommerce (layered navigation) : utile, mais pas “stratégique” tout seul

La layered navigation native fait le job côté UX. En revanche, elle ne porte pas, à elle seule, une stratégie SEO : sans règles, elle expose vite des URLs filtrées crawlables, des combinaisons infinies, et des templates qui se ressemblent.

Avant de changer de plugin, il est souvent plus rentable de cadrer : format d’URL, règles d’indexation, canonicals, monitoring. Dans ce contexte, un audit technique SEO & performance WordPress est souvent le point de départ le plus rentable quand on soupçonne une explosion d’URLs.

Pattern A (souvent le plus stable) : filtres UX + pages collections statiques indexables

C’est un pattern qui tient bien dans le temps : les filtres servent à naviguer (AJAX ou paramètres), et les pages collections “gouvernées” servent le SEO. Marketing y gagne en autonomie (une page collection se travaille comme une page), et l’IT gagne en testabilité (moins de surprises, règles plus simples).

Pattern B : facettes indexables via règles strictes + monitoring (plus risqué)

C’est faisable, mais plus exposé : il faut limiter sévèrement les combinaisons, imposer un ordre d’URL stable, contrôler pagination/tri, et monitorer en continu (logs, alerting, correctifs). Sans gouvernance, c’est typiquement le genre de choix qui semble “OK” le jour 1… et qui réapparaît en prod six mois plus tard.

Points de vigilance : canonical, pagination, tri, tracking

Sur la pagination, Google recommande que chaque page paginée ait sa propre URL et son canonical propre (plutôt que de tout canoniser vers la page 1).

Sur le tri et le tracking, l’objectif est simple : éviter que ces paramètres deviennent des pages candidates.

5) Checklist de validation avant mise en prod

Indexation maîtrisée : combien d’URLs indexables vous visez ?

Avant déploiement, c’est souvent utile de poser un chiffre-cible : “on veut X pages indexables” (catégories + collections), plutôt que “on verra bien”. Ensuite, on vérifie que les règles techniques servent ce chiffre.

Avant : inventaire des facettes, décision (SEO candidate / UX only / à bloquer), liste des paramètres à neutraliser, mapping des pages collections.

Pendant : tests sur un environnement proche prod (canonicals, meta robots, pagination, tri), vérification des sitemaps (collections incluses, facettes exclues).

Après : contrôle GSC (couverture, exclusions, indexation), échantillon de logs Googlebot, et correctifs rapides si dérive.

Crawl & logs : éviter que Googlebot “dépense” au mauvais endroit

Les logs sont un détecteur de fumée très fiable. Le but est de voir Googlebot majoritairement sur vos catégories/collections, pas sur ?orderby= ou ?utm_. Google insiste sur le coût potentiel du crawl des facettes : si tout reste ouvert, vous payez (ressources serveur + opportunité SEO).

Performance : filtres rapides, pages légères

Des filtres lents poussent à surcharger en JS, multiplient les requêtes, et compliquent l’exploration. L’objectif est une UX fluide et des pages stables. Quand un plugin ajoute des dépendances partout, ce n’est pas forcément “mauvais”, mais c’est souvent un signal : le pattern (ou l’intégration) mérite d’être re-challengé.

Conclusion : reprendre le contrôle, sans complexifier

Les filtres ne sont ni “bons” ni “mauvais” pour le SEO. Tout se joue dans la gouvernance : décider quelles intentions méritent une vraie page, et empêcher le reste de devenir indexable par accident.

Sur WooCommerce, les projets qui performent sont rarement ceux qui ont “le plus de facettes”, mais ceux qui ont fait des choix clairs — côté SEO, UX et technique.

FAQ