Un catalogue PrestaShop de quelques centaines de références peut générer des dizaines de milliers d’URLs quasi identiques, entre tris, filtres et pagination. La balise canonical est la réponse la plus connue, mais elle est souvent posée à côté de deux autres techniques (noindex, blocage robots.txt) qui, cumulées, peuvent l’annuler purement et simplement. Voici comment PrestaShop gère nativement le canonical selon votre version, et pourquoi le cumul des trois techniques recommandées par la majorité des guides se retourne parfois contre vous.
Sommaire
- Pourquoi PrestaShop génère naturellement du contenu dupliqué
- Comment fonctionne la balise canonical selon votre version de PrestaShop
- Navigation à facettes : la vraie source de duplication massive
- Pourquoi cumuler canonical, noindex et robots.txt peut se retourner contre vous
- Vérifier que vos canonicals fonctionnent réellement
- Cas particuliers à ne pas rater
- Questions fréquentes
Pourquoi PrestaShop génère naturellement du contenu dupliqué
Ce n’est pas un défaut de configuration, c’est le fonctionnement normal du moteur. PrestaShop construit des URLs à partir de paramètres, et chaque paramètre ajouté crée une variante techniquement distincte d’une page dont le contenu reste, pour Google, quasiment identique. Cinq sources reviennent systématiquement sur un catalogue actif.
| Source | Exemple | Contenu réellement différent ? |
|---|---|---|
| Tri et pagination | ?order=product.price.asc, ?page=2 |
Non, même liste de produits réordonnée |
| Recherche interne | ?q=recherche |
Non, contenu généré à la volée |
| Produit multi-catégories | /chaussures/basket-x et /promotions/basket-x |
Non, fiche produit identique |
| Filtres à facettes | ?couleur=noir&taille=42 |
Rarement, sauf combinaison à fort volume de recherche |
| Protocole / sous-domaine | http vs https, www vs sans www | Non, page strictement identique |
Chacune de ces sources, prise isolément, semble anodine. Le problème apparaît à l’échelle : un catalogue de 200 produits avec 5 attributs filtrables peut dépasser 10 000 URLs au contenu quasi identique. Google doit alors choisir lui-même quelle version afficher, l’autorité du produit se dilue entre les variantes plutôt que de se concentrer sur une seule, et le budget de crawl part sur des pages qui n’apportent rien.
Comment fonctionne la balise canonical selon votre version de PrestaShop
La bonne nouvelle : PrestaShop gère la canonicalisation nativement, mais différemment selon la génération du moteur. Vérifier ce point avant toute autre action évite de corriger un problème qui n’existe pas, ou d’ignorer une case à cocher qui suffirait.
PrestaShop 1.6 : une balise à construire dans le thème
Sur 1.6, la balise canonical n’est pas automatique : elle doit être posée dans header.tpl, entre les balises <head>, en s’appuyant sur les méthodes natives du thème ({$link->getProductLink($product)} pour une fiche produit, {$link->getCategoryLink($category)} pour une catégorie) plutôt que sur une reconstruction manuelle de l’URL courante, qui laisserait passer les paramètres de tri et de recherche.
PrestaShop 1.7 et 8.x : un mécanisme natif, à vérifier plutôt qu’à recréer
À partir de 1.7, le canonical repose sur la variable Smarty {$urls.canonical_url}, injectée automatiquement dans templates/_partials/head.tpl des thèmes basés sur Classic. La tâche n’est donc plus d’ajouter du code, mais de vérifier que ce bloc n’a pas été supprimé ou commenté lors d’une personnalisation de thème, ce qui arrive fréquemment sur les thèmes premium retravaillés par une agence tierce.
Le cas particulier de la pagination
Deux logiques coexistent selon que le contenu des pages paginées diffère réellement ou non. Si la page 2 d’une catégorie affiche des produits différents de la page 1, chaque page paginée doit conserver sa propre URL canonique (auto-référente). Si en revanche la pagination ne sert qu’à naviguer dans une liste identique triée différemment, une canonical unique vers la première page suffit à consolider le signal.
Navigation à facettes : la vraie source de duplication massive
Les filtres (couleur, taille, prix, marque) sont, de loin, la source qui produit le plus de volume. Une étude Baymard citée par plusieurs consultants indique que 76 % des utilisateurs e-commerce s’en servent, ce qui exclut de simplement les supprimer. Le problème n’est pas la fonctionnalité, c’est son exploration incontrôlée par Googlebot.
Le volume réel sur un catalogue courant
Avec 5 attributs filtrables combinables librement, un catalogue de 200 produits peut dépasser 10 000 URLs distinctes pour Google, la quasi-totalité sans intérêt de recherche propre. Deux traitements différents s’imposent selon la valeur de la combinaison.
Les deux tactiques recommandées par le marché
Pour l’immense majorité des combinaisons, sans volume de recherche identifiable, la pratique courante combine une balise canonical pointant vers la page catégorie parente et un noindex, follow sur la page filtrée elle-même, le follow préservant la remontée du maillage interne. Pour une minorité de combinaisons à fort volume de recherche identifié (« chaussures running homme rouge », par exemple), la recommandation inverse s’applique : créer une URL statique dédiée, avec un contenu et un H1 propres, plutôt que de la bloquer.
Pourquoi cumuler canonical, noindex et robots.txt peut se retourner contre vous
C’est le point que la plupart des guides PrestaShop, y compris ceux qui détaillent le mieux la navigation à facettes, ne relèvent jamais : ils recommandent souvent de cumuler les trois techniques (canonical, noindex, et blocage des paramètres dans le robots.txt) comme une protection renforcée. La documentation officielle de Google sur la consolidation des URLs dupliquées dit explicitement le contraire sur deux de ces trois points, et l’ignorer peut rendre votre configuration inopérante sans que rien ne le signale dans le back-office.
Ce que dit vraiment Google sur la consolidation des signaux
Google distingue deux objectifs qu’on confond trop souvent : consolider l’autorité d’une page vers une autre, ou simplement la retirer de l’index. La balise canonical fait le premier : elle indique à Google de transférer les signaux (liens, autorité) de la page dupliquée vers l’URL préférée. Le noindex ne fait pas ça : il retire la page de l’index, mais les signaux qu’elle avait accumulés (un lien externe pointant dessus, par exemple) ne sont PAS reversés vers la page canonique. Google le formule sans ambiguïté dans sa documentation officielle sur la gestion des doublons : le noindex n’est pas recommandé comme méthode de résolution des doublons internes, précisément parce qu’il ne consolide rien.
Le blocage via robots.txt aggrave le problème d’une autre façon : Googlebot ne peut tout simplement plus lire la page bloquée, donc ne peut plus y voir ni la balise canonical, ni la balise noindex que vous y avez posée. La page peut malgré tout apparaître dans les résultats (sans extrait, juste l’URL) si des liens externes ou internes continuent d’y pointer. Google le dit explicitement : le robots.txt n’est pas une méthode de canonicalisation fiable, « les pages peuvent s’indexer quand même ».
Ce que ça change concrètementSur PrestaShop, si vous posez une canonical vers la catégorie parente ET un noindex ET un blocage robots.txt sur les mêmes URLs de filtres, le blocage robots.txt empêche Googlebot de voir les deux autres signaux que vous venez de poser. Le résultat dépend alors des liens externes existants, pas de votre configuration.
Le bon choix selon votre objectif
La règle qui découle de cette documentation est plus simple qu’elle n’y paraît, à condition de choisir un seul objectif par groupe d’URLs :
Vérifier que vos canonicals fonctionnent réellement
Une configuration correcte dans le thème ne garantit pas qu’elle produit l’effet attendu en ligne, surtout après une mise à jour PrestaShop ou une personnalisation de thème par une agence tierce.
Le contrôle manuel, page par page
Ouvrez le code source de la page (Ctrl+U), cherchez <link rel="canonical"> dans le <head>, et vérifiez que l’URL indiquée ne contient aucun paramètre parasite (tri, filtre, identifiant de session). L’inspection d’URL de Search Console donne une deuxième lecture, celle que Google a effectivement retenue, qui ne correspond pas toujours à ce que votre balise déclare.
Le contrôle à l’échelle, avec un crawler
Sur un catalogue de plus de quelques dizaines de références, le contrôle page par page ne tient pas. Un crawl complet (Screaming Frog ou équivalent) permet de cartographier, en une passe, toutes les URLs canoniques déclarées et de repérer les incohérences : canonical vers une page qui redirige elle-même, canonical absente sur des fiches produit, ou canonical identique sur des pages qui ne devraient pas l’être.
Cas particuliers à ne pas rater
Un produit présent dans plusieurs catégories
Sur PrestaShop, un même produit peut être rattaché à plusieurs catégories, chacune générant sa propre URL d’accès au produit. Sans intervention, Google reçoit plusieurs chemins vers la même fiche et doit arbitrer seul. Les méthodes natives du thème (getProductLink) résolvent en principe ce cas en pointant systématiquement vers une URL de référence unique, mais une thème fortement personnalisé peut casser ce comportement sans avertissement visible côté back-office : c’est un point à vérifier explicitement après toute refonte de template.
HTTP vs HTTPS, www vs sans www
Ces variantes de domaine doivent être tranchées une bonne fois par redirection 301 côté serveur (.htaccess), pas par la seule balise canonical. Google indique lui-même préférer HTTPS par défaut, sauf certificat SSL invalide ou redirection incohérente vers HTTP : un site qui sert encore ses deux protocoles sans redirection laisse cette décision à l’algorithme plutôt qu’à l’administrateur du site.
Faut-il combiner canonical, noindex et robots.txt sur les pages de filtres PrestaShop ?
Non, ces trois techniques répondent à des objectifs différents et se neutralisent en partie si elles sont cumulées sur les mêmes URLs. Choisissez la canonical pour transférer l’autorité, le noindex pour simplement retirer une page sans transfert, ou le robots.txt pour économiser du budget de crawl sur des paramètres sans enjeu de lien externe, jamais les trois à la fois sur un même groupe d’URLs.
PrestaShop 1.7 et 8.x posent-ils la balise canonical automatiquement ?
Oui, via la variable Smarty {$urls.canonical_url} intégrée nativement aux thèmes basés sur Classic. Une personnalisation de thème peut toutefois supprimer ce bloc sans le signaler ailleurs, d’où l’intérêt de le vérifier après chaque changement de thème.
Quelle est la différence entre une redirection 301 et une balise canonical ?
La redirection 301 fait disparaître l’ancienne URL, le visiteur et Googlebot sont renvoyés directement vers la nouvelle. La balise canonical laisse les deux URLs accessibles, mais indique à Google laquelle doit faire autorité dans les résultats de recherche.
Comment savoir si mes filtres PrestaShop créent vraiment du contenu dupliqué ?
Un crawl complet du site (Screaming Frog ou équivalent) associé à l’onglet Couverture de Search Console permet de comparer le nombre d’URLs générées par les combinaisons de filtres et le nombre de pages réellement indexées avec un contenu jugé similaire par Google.
Faut-il indexer certaines pages de filtres PrestaShop ?
Oui, à la marge : une combinaison de filtres qui correspond à une vraie intention de recherche (volume mensuel identifiable) mérite une URL statique dédiée avec un contenu et un H1 propres, plutôt qu’un blocage systématique qui la priverait de tout trafic organique.
Ce qu’il faut retenir
La balise canonical ne se pose pas en complément systématique du noindex et du robots.txt, elle se choisit à leur place selon ce que vous cherchez à obtenir : transférer un signal, ou simplement retirer une page. Sur un catalogue PrestaShop, cette décision se prend groupe d’URLs par groupe d’URLs, jamais globalement, et se vérifie ensuite sur le site en ligne, pas seulement dans la configuration du thème. C’est un travail qui gagne à s’inscrire dans la durée plutôt qu’en correction ponctuelle, tant les mises à jour de thème et de modules peuvent silencieusement revenir dessus.
À propos de l’auteur
Aymeric Maingé
Consultant SEO senior avec plus de 10 ans d’expérience, côté agence et annonceur. J’accompagne des boutiques PrestaShop sur des problématiques de SEO technique, d’architecture de catalogue, d’indexation et de performance web. Mon approche croise audit terrain, priorisation métier et recommandations actionnables pour les équipes marketing et IT. Votre consultant SEO Prestashop peut auditer vos canonicals, vos filtres et votre budget de crawl en une seule intervention.
À lire aussi
Les autres articles sur le sujet
Déclinaisons PrestaShop et duplicate content : mécanique des URL, canonical officielle et un bug de liens catégorie encore ouvert,…
Lire l’article
Vérifier la balise canonical sur PrestaShop, produit par produit et à l’échelle du catalogue : le bug qui la casse en silence et…
Lire l’article
Retirer l’ID des URLs produit PrestaShop : gain SEO réel ou marginal, et le vrai risque de collision de slug sur un catalogue.…
Lire l’article
Activer les URL simplifiées sur PrestaShop est facile. Choisir le bon format et éviter les 404 après un changement d’URL l’est…
Lire l’article
