Facettes PrestaShop : noindex, canonical ou blocage robots.txt ?

noindex, canonical, blocage robots.txt : on les présente souvent comme trois options interchangeables pour « gérer les facettes ». Ce sont trois outils qui répondent à trois questions différentes, et les empiler sans méthode produit l’erreur la plus courante des boutiques PrestaShop : des URL coincées dans l’index, impossibles à en sortir. Voici ce que chaque mécanisme fait vraiment, dans quel ordre les appliquer, et une matrice de décision par cas.

Trois mécanismes, trois questions

Avant de choisir, il faut savoir ce que chacun dit à Google.

• rel= »canonical » répond à « cette URL est-elle une variante d’une autre ? ». Elle désigne une page de référence. C’est un indice de regroupement, pas un ordre. Google peut le suivre ou l’ignorer, notamment quand le contenu de la page filtrée diffère nettement de la catégorie canonique.
• meta robots noindex répond à « faut-il classer cette URL ? ». C’est une directive : correctement lue, elle sort la page de l’index. Mais Google doit pouvoir crawler la page pour voir la balise.
• Disallow dans le robots.txt répond à « faut-il dépenser du budget de crawl ici ? ». Elle empêche l’exploration. Elle n’empêche pas l’indexation : une URL jamais crawlée mais connue de Google peut rester indexée, sans description, avec la mention « indexée malgré le blocage par le fichier robots.txt ».

La documentation Google est explicite : le canonical et le nofollow sont « généralement moins efficaces à long terme » que le robots.txt ou les fragments d’URL pour empêcher le crawl. Mais « empêcher le crawl » et « désindexer » ne sont pas le même objectif.

L’erreur qui bloque vos URL dans l’index

Le scénario se répète sur des centaines de boutiques. On veut « nettoyer les facettes », alors on fait les deux d’un coup : on ajoute Disallow: /*?q= dans le robots.txt et on active un noindex sur les pages filtrées.

Résultat : Google arrête immédiatement de crawler les URL ?q=. Il ne voit donc jamais le noindex que vous venez de poser. Les URL déjà indexées le restent, gelées, avec le libellé « indexée malgré le blocage par robots.txt » dans la Search Console. Vous avez rendu la désindexation impossible par la voie normale : pour la débloquer, il faudra retirer le Disallow, attendre que Google recrawle et lise le noindex, puis éventuellement remettre le blocage. Des semaines perdues.

La séquence correcte pour désindexer

Pour faire sortir de l’index des facettes déjà indexées, l’ordre des opérations n’est pas négociable.

1. Poser le noindex, laisser le crawl ouvertActivez la balise meta robots à noindex, follow sur les URL de facettes concernées. Ne touchez pas encore au robots.txt : Google doit pouvoir revenir lire ces pages.
2. Attendre la désindexation constatéeSuivez le rapport Indexation des pages de la Search Console. Selon le volume et la fréquence de crawl, comptez plusieurs semaines pour que les URL passent de « indexées » à « exclues par la balise noindex ».
3. Bloquer le crawl seulement ensuiteUne fois la désindexation confirmée sur l’essentiel du volume, ajoutez le Disallow dans le robots.txt pour couper définitivement la dépense de crawl. Le noindex peut rester, il ne gêne pas.
4. Traiter les combinaisons vides à partLes URL de filtres sans résultat doivent renvoyer un code 404, pas un 200 en noindex. C’est la recommandation explicite de Google pour ces cas.

Pour des facettes non encore indexées et sans valeur SEO, l’inverse est acceptable : un Disallow préventif suffit à éviter qu’elles n’entrent dans l’index, sans passer par le noindex.

La matrice de décision par cas

Le bon mécanisme dépend de ce que l’URL est et de ce que vous voulez en faire.

Cette matrice s’inscrit dans une stratégie SEO des facettes d’ensemble. Le canonical seul, vers la catégorie, n’apparaît nulle part comme solution de désindexation : il n’en est pas une. Il accompagne un autre traitement ou sert sur les pages qu’on garde. Le détail de la logique de tri est traité dans notre article sur la gestion des URL de tri sur PrestaShop, et la pagination dans celui sur la pagination des catégories.

Où agir dans PrestaShop

Concrètement, sur une boutique 1.7 ou 8 :

• robots.txt : régénérable depuis Paramètres avancés, SEO et URL, mais toute règle personnalisée ajoutée à la main est écrasée à la régénération. Mieux vaut un override propre ou une règle serveur.
• meta robots des facettes : le module natif ne pose pas de noindex sur les URL ?q= en 1.7 et 8.x. Il faut un override du contrôleur de recherche à facettes, un hook sur l’en-tête, ou passer par PrestaShop 9 où le coeur gère la condition.
• canonical : PrestaShop pose un canonical sur les pages catégorie et produit, mais pas toujours de façon cohérente sur les variantes filtrées. À vérifier au crawler.

Savoir quelles facettes relèvent de quelle ligne de la matrice suppose un inventaire préalable : c’est l’objet d’un audit SEO de la boutique PrestaShop, et la méthode de crawl en deux passes est détaillée dans notre guide pour auditer les facettes au crawler. La question de fond, faut-il indexer certaines pages filtrées, se tranche sur des données d’usage, pas sur un principe.

Vérifier que ça a marché

Trois contrôles, à espacer de quelques semaines après la mise en oeuvre :

• Search Console, rapport Indexation : le volume d’URL de facettes indexées doit baisser, et les motifs d’exclusion doivent afficher « exclue par la balise noindex », pas « indexée malgré le blocage ».
• Test de l’URL en direct dans la Search Console sur un échantillon : la balise noindex est bien lue, la page est bien crawlable au moment du test.
• Crawl de contrôle : plus de facettes combinatoires en index,follow, plus de combinaisons vides en 200.

En pratique

Le canonical regroupe, le noindex déclasse, le Disallow économise le crawl. On ne les empile pas au hasard : sur des facettes déjà indexées, noindex d’abord, blocage robots.txt seulement une fois la désindexation constatée, 404 pour les combinaisons vides, et self-canonical pour ce qu’on garde. Choisir la bonne ligne de la matrice pour chaque famille d’URL demande un inventaire au crawler et une lecture des données : je peux vous accompagner sur ce diagnostic, le détail est juste en dessous.