Chaque couleur, chaque taille d’un produit PrestaShop génère techniquement sa propre URL. La balise canonical est censée neutraliser ce risque de duplication, et elle le fait, sur la fiche produit elle-même. Ce que personne ne vérifie, c’est ce que PrestaShop met dans les liens de VOS PAGES CATÉGORIE : un bug encore ouvert en 2026 y glisse discrètement l’URL d’une combinaison précise, pas celle que la canonical recommande.
Sommaire
- Comment une déclinaison devient une URL à part entière
- Ce que la canonical fait réellement sur une fiche à combinaisons
- Le bug encore ouvert : vos pages catégorie contournent la canonical
- Vérifier votre catalogue en cinq minutes
- Le cas particulier du multiboutique
- Flux fournisseur et déclinaisons : la double duplication
- Rédiger une fiche à déclinaisons sans se dupliquer soi-même
- Erreurs les plus fréquentes
- Questions fréquentes
- Ce qu’il faut retenir
Comment une déclinaison devient une URL à part entière
Sur PrestaShop 1.7 et 8.x, une fiche produit avec combinaisons ne porte pas une seule URL mais potentiellement autant que de variantes actives. Le format suit le schéma id_product-id_product_attribute-nom-produit.html : un tee-shirt en taille S coloris blanc peut ainsi répondre sur /1-1-tee-shirt.html, la même référence en taille M coloris noir sur /1-9-tee-shirt.html, et ainsi de suite pour chaque combinaison enregistrée dans le back-office.
Sur un produit à 3 tailles et 4 couleurs, cela représente jusqu’à 12 URLs distinctes pour un seul article vendu, sans compter l’ancre de navigation (#/1-size-s/8-color-white) que le thème ajoute pour permettre de changer de variante sans recharger la page. C’est ce volume, multiplié par la taille du catalogue, qui transforme un problème anecdotique en vrai sujet de budget de crawl sur les boutiques de plusieurs centaines de références.
Ce que la canonical fait réellement sur une fiche à combinaisons
La règle documentée par les spécifications officielles PrestaShop est nette : l’URL parente, sans identifiant de combinaison ni ancre, reste TOUJOURS la canonical de référence, y compris quand une variante précise est affichée à l’écran. Concrètement, que votre visiteur consulte /1-tee-shirt.html ou /1-9-tee-shirt.html, la balise <link rel="canonical"> présente dans le <head> pointe dans les deux cas vers /1-tee-shirt.html. C’est ce mécanisme qui, en théorie, consolide tout le poids SEO des variantes sur une seule URL indexable.
| Version | Comportement de la canonical sur combinaison |
|---|---|
| Avant 1.7.6 | Canonical déjà pointée vers l’URL parente, mais avec une redirection 301 cachée vers la combinaison par défaut, source de confusion pour les crawlers |
| 1.7.6 et supérieur | URL parente accessible directement, canonical stable même si la combinaison par défaut change en back-office |
Un point mérite d’être noté : deux erreurs de réécriture différentes ne produisent pas la même réponse serveur. Un identifiant de combinaison qui n’existe plus déclenche une redirection 301 propre vers la canonical. Un slug mal orthographié avec un identifiant valide redirige, lui, vers l’URL correcte de la combinaison. Dans les deux cas la mécanique fonctionne comme prévu, ce qui rend d’autant plus visible le problème qui suit : quand la canonical elle-même n’est jamais atteinte parce que le lien d’origine ne pointe pas vers elle.
Le bug encore ouvert : vos pages catégorie contournent la canonical
Ce que ni les guides ni la documentation officielle ne signalent clairement
Un ticket ouvert sur le dépôt officiel PrestaShop (issue #26676, toujours actif mi-2026, versions 1.7 et 8.0 concernées) documente un comportement contradictoire : sur les pages catégorie et liste de produits, PrestaShop génère lui-même des liens vers l’URL de la PREMIÈRE combinaison active du produit (avec son id_product_attribute), et non vers l’URL parente que sa propre balise canonical désigne comme référence. Le moteur qui applique la règle est aussi celui qui, ailleurs sur le site, ne la respecte pas.
Comment ça casse concrètement
Un visiteur ou un robot qui clique depuis une page catégorie n’arrive donc pas sur l’URL canonique du produit, mais sur l’URL de sa première combinaison enregistrée. Ce n’est pas qu’un détail cosmétique : c’est précisément la génération de liens internes vers des URLs à combinaison que la canonical est censée rendre inutile. Le maillage interne de votre propre catalogue pousse du poids SEO vers des URLs secondaires plutôt que vers la page de référence.
Que faire en attendant un correctif
Le ticket reste marqué « Needs Specs » sans date de correction annoncée. En attendant, deux leviers restent entre vos mains : vérifier que la balise canonical est bien présente et correcte sur CHAQUE URL de combinaison (elle absorbe l’essentiel du risque même si le lien d’origine est imparfait), et surveiller dans Search Console si des URLs de combinaisons s’indexent malgré tout à la place de l’URL parente, ce qui signalerait que la canonical n’est pas prise en compte sur votre thème ou une surcouche de cache.
Vérifier votre catalogue en cinq minutes
- Ouvrez une fiche produit à combinaisonsChangez de taille ou de couleur et notez comment l’URL affichée dans la barre d’adresse évolue (identifiant de combinaison, ancre après le #).
- Affichez le code sourceRecherchez
rel="canonical"dans le<head>: l’URL indiquée doit être celle du produit SANS identifiant de combinaison, quelle que soit la variante affichée. - Ouvrez la page catégorie qui liste ce produitPassez la souris sur la fiche produit et regardez l’URL de destination affichée en bas de navigateur avant de cliquer.
- Comparez les deux URLsSi l’URL du lien catégorie contient un identifiant de combinaison différent de l’URL canonical relevée à l’étape 2, vous êtes concerné par le comportement décrit plus haut.
- Croisez avec Search ConsoleFiltrez le rapport Pages par le motif d’URL de vos fiches produit : la présence de nombreuses URLs à combinaison réellement indexées, à la place de leur version parente, confirme un problème actif sur votre thème.
Cette vérification rejoint celle que notre guide sur le contrôle des balises canonical PrestaShop détaille pour l’ensemble du catalogue, au-delà du seul cas des déclinaisons.
Le cas particulier du multiboutique
Une installation PrestaShop en multiboutique multiplie le risque : un même produit, avec les mêmes déclinaisons, peut exister sur plusieurs boutiques du même compte, chacune avec son propre nom de domaine ou sous-domaine. Sans intervention, ce sont alors des contenus quasi identiques, déclinaisons comprises, qui se retrouvent dupliqués non plus au sein d’un seul catalogue mais entre plusieurs domaines indexables séparément par Google.
Trois leviers combinés limitent ce risque : une balise canonical inter-boutiques qui désigne la boutique de référence pour chaque produit partagé, un contenu réellement différencié (minimum utile : 100 à 150 mots propres) sur les boutiques secondaires quand la duplication ne peut pas être évitée, et un robots.txt ou un no-index ciblé sur les boutiques qui ne servent pas de référence SEO (boutique de test, marque blanche réservée à un partenaire). Le contenu multilingue échappe à cette logique : des traductions fidèles d’une même fiche ne constituent pas un duplicate content aux yeux de Google, à condition d’un balisage hreflang correct.
Flux fournisseur et déclinaisons : la double duplication
Sur un catalogue alimenté par un flux fournisseur (grossiste, dropshipping, import CSV automatisé), la duplication de déclinaisons s’ajoute à une seconde couche de duplication, plus grave celle-là : la description produit elle-même, identique chez tous les revendeurs qui utilisent le même flux. Le problème n’est alors plus seulement interne à votre site, il se joue face à des dizaines de concurrents qui publient le mot pour mot la même fiche technique.
Modifier uniquement le titre ou le H1 d’une fiche importée ne suffit pas : Google évalue la page dans son ensemble, et un paragraphe descriptif identique au concurrent pèse plus lourd que quelques mots changés en tête de page. Deux leviers fonctionnent réellement dans ce contexte : filtrer l’import pour ne récupérer du flux que les données techniques brutes (références, dimensions, compatibilités), en laissant le texte commercial à la rédaction interne ; et construire des gabarits de description qui croisent les variables du flux (matière, usage, compatibilité) avec une structure de phrase propre à votre site, pour que deux fiches partageant les mêmes données brutes ne se lisent jamais de façon identique.
Rédiger une fiche à déclinaisons sans se dupliquer soi-même
Le duplicate content ne vient pas seulement des concurrents ou du bug de liens catégorie : une fiche mal pensée se duplique aussi vis-à-vis d’elle-même, quand chaque variante reçoit une description entièrement réécrite qui ne dit rien de plus que la précédente. La bonne architecture sépare deux niveaux de contenu : un bloc commun au produit (usage, matière, avantages, fiche technique), rédigé une seule fois et partagé par toutes les combinaisons puisqu’elles ne portent qu’une seule URL indexable, et des attributs différenciants (coloris, taille, disponibilité) gérés par les champs structurés de PrestaShop plutôt que par du texte libre répété.
Cette approche a un effet secondaire utile : elle réduit la tentation de créer une page dédiée par variante « pour le SEO », une pratique qui recrée artificiellement le problème que la canonical est censée résoudre. Notre guide sur les URLs canoniques PrestaShop détaille les autres sources de duplication à surveiller sur un catalogue (pagination, recherche interne, facettes) au-delà du seul cas des déclinaisons produit.
Erreurs les plus fréquentes
- Créer une fiche par couleurDupliquer manuellement un produit pour chaque variante au lieu d’utiliser le système de combinaisons natif recrée exactement le duplicate content que PrestaShop sait éviter nativement.
- Laisser les facettes de filtre s’indexerLes URLs générées par les filtres couleur/taille en page catégorie multiplient les combinaisons de paramètres sans valeur SEO propre.
- Ne vérifier la canonical que sur l’URL parenteLe contrôle doit porter sur les URLs de COMBINAISON, celles réellement liées depuis les pages catégorie, pas seulement sur l’URL produit de base.
- Importer les descriptions fournisseur telles quellesSans filtrage ni enrichissement, chaque nouvelle référence importée ajoute un contenu déjà dupliqué ailleurs sur le web.
Questions fréquentes
PrestaShop gère-t-il automatiquement la canonical des déclinaisons produit ?
Oui, nativement depuis la version 1.7.6 : la balise canonical d’une fiche produit pointe toujours vers l’URL parente sans identifiant de combinaison, quelle que soit la variante affichée. Le point de vigilance se situe ailleurs : dans les liens que PrestaShop génère lui-même depuis les pages catégorie.
Faut-il créer une URL différente pour chaque couleur ou taille ?
Non, c’est déjà le comportement natif de PrestaShop via le système de combinaisons, et c’est voulu : chaque variante reste accessible par une URL propre pour l’expérience utilisateur, tout en consolidant son poids SEO sur l’URL canonique unique.
Comment savoir si mon catalogue est concerné par le bug de liens catégorie ?
Comparez l’URL affichée au survol d’une fiche produit sur une page catégorie avec la balise canonical de la fiche produit correspondante. Si les deux diffèrent par la présence d’un identifiant de combinaison, votre thème est concerné.
Le contenu multilingue est-il considéré comme dupliqué par Google ?
Non, une traduction fidèle d’une fiche produit n’est pas un duplicate content aux yeux de Google, à condition que le balisage hreflang identifie correctement chaque version linguistique.
Bloquer les URLs de combinaison via robots.txt est-il une bonne solution ?
Non, c’est contre-productif : un blocage robots.txt empêche Googlebot de lire la balise canonical présente sur ces mêmes URLs, ce qui rend la consolidation de signaux inopérante. Laissez-les crawlables et fiez-vous à la canonical pour rediriger le signal SEO.
Ce qu’il faut retenir
La mécanique native de PrestaShop protège correctement vos fiches à déclinaisons contre le duplicate content, sur le papier. Le bug de génération de liens catégorie montre qu’une règle bien implémentée à un endroit du CMS peut être contournée ailleurs, sans qu’aucune alerte ne le signale dans le back-office. Sur un catalogue de plusieurs centaines de références, cette vérification vaut la peine d’être faite une fois pour de bon plutôt que supposée acquise.
À 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 et des catalogues e-commerce volumineux sur les problématiques de SEO technique, d’indexation et de structure d’URL. Mon approche croise audit terrain, priorisation métier et recommandations actionnables. Faites appel à un prestataire SEO PrestaShop pour auditer les canonicals de votre catalogue.
À lire aussi
Les autres articles sur le sujet
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
