Comment gérer les URL de tri sur une boutique PrestaShop ?

PrestaShop bloque déjà les URL de tri dans son robots.txt par défaut. C’est vrai, et c’est ce qui trompe : la protection a deux trous précis. Elle ne bloque le tri que lorsqu’il est le premier paramètre de l’URL, pas quand il suit la pagination. Et le réglage « redirection vers l’URL canonique » ne touche pas les paramètres. Résultat : des milliers d’URL ?p=2&order=... qui passent entre les mailles.

Ce que PrestaShop génère comme URL de tri

Sur une page catégorie, le sélecteur de tri produit des URL à paramètres. Selon la version, la syntaxe diffère : ?order=product.price.asc ou ?order=product.name.desc sur PrestaShop 1.7 et 8, ?orderby=price&orderway=asc sur PrestaShop 1.6. S’y ajoutent la pagination, ?p=2, et le nombre de produits par page, ?n=48. Ces paramètres se combinent : ?p=3&order=product.price.desc est une URL parfaitement valide, qui répond en 200.

Dans le thème classique, le sélecteur de tri est un menu déroulant dont les entrées sont de vrais liens <a href>. Googlebot les découvre donc à l’exploration, même s’il ne peut pas les suivre si le robots.txt les bloque. Une catégorie avec quatre options de tri et dix pages de pagination, c’est déjà une quarantaine d’URL de tri découvrables pour une seule catégorie.

Le tri n’est pas un filtre : contenu identique

C’est la distinction qui commande tout le traitement. Un filtre à facettes réduit la liste : « chaussures rouges pointure 42 » affiche un sous-ensemble de produits. Une URL de tri, elle, affiche exactement les mêmes produits, dans un autre ordre. Le contenu est identique, seul l’ordonnancement change.

Conséquence pratique : le tri est le seul cas de la navigation à facettes où la balise rel="canonical" suffit vraiment. Pour un filtre, la canonical seule ne règle pas le gaspillage de budget de crawl sur des pages au contenu différent, comme expliqué dans notre guide pour empêcher les filtres de générer des milliers d’URL indexables, et dans celui qui détaille quels filtres méritent d’être indexés. Pour le tri, une canonical qui pointe vers la version sans paramètre de tri dit à Google la stricte vérité : cette page est un doublon d’ordonnancement, indexe l’autre.

Ce que PrestaShop fait déjà, et ses limites

Deux mécanismes natifs traitent partiellement le sujet.

Le robots.txt généré par défaut

Depuis Trafic et SEO, PrestaShop génère un robots.txt qui contient des règles du type Disallow: /*?orderby=, Disallow: /*?orderway=, ainsi que le blocage de ?search_query=, ?tag=, ?id_currency= et des paramètres de suivi. Sur le papier, le tri est couvert. Attention : ce fichier est écrasé à chaque régénération, tout ajout manuel disparaît sans avertissement.

La canonical sur la page catégorie

PrestaShop pose une balise rel="canonical" sur les pages catégorie. Le problème : selon la version et le thème, elle pointe tantôt vers l’URL de la page 1, tantôt vers l’URL de la page courante, et son comportement face aux paramètres de tri n’est pas garanti. Il faut donc la vérifier, pas la supposer correcte.

Les deux trous de la protection par défaut

Voici ce que les guides SEO PrestaShop ne précisent jamais.

Le robots.txt ne bloque le tri que s’il est le premier paramètre

Une règle Disallow: /*?orderby= exige la présence de la chaîne ?orderby=, avec le point d’interrogation juste avant. Elle bloque donc /ma-categorie?orderby=price. Elle ne bloque pas /ma-categorie?p=2&orderby=price : dans cette URL, le tri est précédé d’un &, pas d’un ?. Dès qu’un visiteur trie une page de pagination, l’URL produite échappe à la règle. C’est exactement le cas le plus fréquent en navigation réelle. La correction est une règle sans point d’interrogation, du type Disallow: /*orderby= et Disallow: /*order=, à adapter à la syntaxe de votre version.

La redirection canonique ne touche pas les paramètres

Le réglage « Rediriger vers l’URL canonique » de Trafic et SEO gère la barre oblique finale, les accents dans l’URL, ou une fiche produit appelée depuis la mauvaise catégorie. Il ne redirige pas ?order=... vers la version sans tri. Un marchand qui a activé ce réglage et pense être couvert pour le tri se trompe : ce réglage et le tri ne se croisent jamais.

Vérifier l’état réel de votre boutique

Quatre contrôles, une quinzaine de minutes, avant toute correction.

1. Tester une URL de tri simple dans l’outil robots.txtPrenez /une-categorie?order=product.price.asc et vérifiez qu’elle est bien bloquée.
2. Tester une URL tri + paginationPrenez /une-categorie?p=2&order=product.price.asc. Si l’outil la dit autorisée, le premier trou est confirmé chez vous.
3. Inspecter la canonical de trois URLLa page catégorie nue, la même triée, la même triée et paginée. Noté vers quoi pointe chaque rel="canonical".
4. Lire le rapport Indexation des pagesCherchez les motifs « indexée malgré le blocage par le fichier robots.txt » et « explorée, actuellement non indexée » : ils listent les URL de tri déjà connues de Google.

Ce diagnostic fait partie d’un audit technique de boutique PrestaShop plus large, qui croise ces contrôles avec l’analyse des logs serveur pour mesurer le budget de crawl réellement gaspillé.

La configuration cible pour le tri

L’objectif : une seule URL indexable par catégorie et par page de pagination, les variantes de tri reconnues comme des doublons d’ordonnancement.

Pas besoin de noindex sur le tri, contrairement aux filtres : le contenu étant identique, la canonical fait foi. Une exception : si des milliers d’URL de tri sont déjà indexées, un noindex temporaire accélère la sortie de l’index, puis on repasse à la canonical seule une fois le nettoyage fait. L’ordre des opérations reste le même que pour les filtres : noindex d’abord, resserrage du robots.txt ensuite, jamais l’inverse, comme détaillé pour la stratégie de navigation à facettes.

Poser la canonical quand PrestaShop ne le permet pas nativement

PrestaShop n’expose aucun réglage pour décider vers quoi pointe la canonical d’une page catégorie triée. Trois voies pour la contrôler. Un module SEO du catalogue d’extensions, qui prend la main sur la balise et permet de retirer les paramètres de tri et de pagination selon vos règles. Un override de CategoryController, si vous avez un développeur : quelques lignes qui reconstruisent l’URL canonique en ignorant order et n, en gardant p. Ou, à défaut, un module qui se branche sur le hook displayHeader pour réécrire la balise dans le <head>. Dans les trois cas, on teste le rendu final sur une dizaine d’URL triées et triées-paginées avant de considérer le sujet clos.

Traiter la pagination dans le même geste

Le tri et la pagination sont couplés : impossible de régler proprement l’un sans toucher à l’autre, puisque leurs paramètres se combinent dans la même URL.

Chaque page paginée reste indexable

La page 2, la page 3 d’une catégorie doivent rester indexables, avec une canonical auto-référencée : la canonical de ?p=2 pointe vers ?p=2, pas vers la page 1. Sans quoi les produits qui n’apparaissent qu’à partir de la page 2 perdent leur chemin d’accès pour Google. Renoncez au balisage rel="prev" et rel="next", que Google n’utilise plus depuis des années.

Le paramètre du nombre par page

Le paramètre ?n=, qui change le nombre de produits affichés, crée des doublons de la même liste découpée autrement. Traitez-le comme le tri : canonical vers la valeur par défaut, et blocage robots.txt.

Mesurer le gaspillage de crawl dans les logs

Avant et après la correction, un chiffre vaut mieux qu’une intuition. Les journaux d’accès du serveur, passés dans un analyseur de logs, montrent la part des visites de Googlebot qui tombe sur des URL à paramètre order, n ou p plutôt que sur des catégories et des fiches produit. Sur une boutique négligée, il n’est pas rare que 20 à 40 % du crawl parte dans ces URL sans valeur.

Prenez une semaine de logs de référence, appliquez la canonical propre et le robots.txt corrigé, attendez trois à quatre semaines que Googlebot intègre les changements, puis reprenez une semaine de logs. La part de crawl sur les URL de tri doit s’effondrer, et celle sur les fiches produit remonter. C’est la seule preuve directe que l’opération a servi, et elle se compare d’un audit à l’autre.

Ce qu’il ne faut pas faire

Trois erreurs fréquentes, chacune crée un problème à la place de celui qu’elle prétend résoudre.

Tout mettre en noindex, pagination comprise. Vous désindexez alors les pages 2 et suivantes, et les produits qui n’y figurent qu’à partir de là deviennent orphelins. Le noindex se réserve au tri et au ?n=, jamais à la pagination.

Rediriger le tri en 301 vers la page sans tri. C’est brutal pour l’utilisateur : il clique sur « prix croissant », il est renvoyé sur la liste non triée, le bouton retour du navigateur boucle. La canonical fait le travail côté SEO sans casser l’UX.

Compter sur le robots.txt seul. Il bloque le crawl, pas l’indexation. Une URL de tri déjà indexée, ou découverte via un lien, peut rester dans l’index sans description. Le robots.txt est un complément de la canonical, pas un substitut.

Une canonical propre vaut mieux qu’un blocage troué

Gérer les URL de tri sur PrestaShop tient en trois décisions : une canonical qui pointe vers la version sans tri, un robots.txt corrigé pour attraper le tri même après la pagination, et des liens de tri non explorables quand le thème le permet. Le tri est le cas le plus simple de la navigation à facettes, parce que son contenu est identique à la page d’origine : inutile de sortir l’artillerie du noindex, il suffit de dire la vérité à Google avec la bonne balise. La seule vraie difficulté est de ne pas croire que PrestaShop a déjà tout réglé : la protection par défaut a deux trous, et ils se vérifient en quinze minutes.

Questions fréquentes