Dupliquer un contenu sur PrestaShop ? Voici comment le gérer sans pénalité

Contenu dupliqué sur PrestaShop : le problème que personne ne regarde en face

Vous avez lancé votre boutique il y a deux ans. Les fiches produits sont propres, les photos soignées, les prix compétitifs. Et pourtant, le trafic stagne. Vous publiez du contenu chaque semaine, mais Google ne semble rien indexer de nouveau.

Je connais cette situation. Pas parce que je l'ai lue dans un guide — parce que je l'ai vécue. Ma propre boutique PrestaShop a perdu près de 30 % de son trafic organique en trois mois, sans aucune pénalité manuelle, sans erreur technique visible dans la Search Console. Le coupable était invisible : du contenu dupliqué généré par ma propre configuration.

Voici ce que j'ai appris, souvent à mes dépens.

Identifier les doublons : l'audit qui change tout

Avant de corriger quoi que ce soit, il faut savoir ce que vous avez. Et là, surprise : la plupart des audits SEO que j'ai vus se contentent de lancer un crawl et de compter les URL. C'est insuffisant.

Les requêtes SQL qui révèlent vos doublons en 10 minutes

En 2024, après des semaines de tâtonnements, j'ai fini par ouvrir phpMyAdmin et interroger directement la base. Voici la requête qui m'a ouvert les yeux :

SELECT p.id_product, pl.name, COUNT(*) AS nb_fiches

FROM ps_product_lang pl

JOIN ps_product p ON p.id_product = pl.id_product

GROUP BY pl.name

HAVING nb_fiches > 1;

Résultat : 47 produits avaient des fiches en double dans la table `product_lang`. Pas parce que je les avais créés deux fois — mais parce que certaines déclinaisons et associations de déclinaisons généraient des entrées séparées. Ces doublons internes étaient invisibles dans le back-office, mais bien présents dans la base.

Autre requête utile, pour repérer les URL qui pointent vers le même contenu :

SELECT link_rewrite, COUNT(*) AS occurrences

FROM ps_product_lang

GROUP BY link_rewrite

HAVING occurrences > 1;

Ce genre de contrôle prend cinq minutes. Il devrait être fait à chaque mise à jour majeure du catalogue. Je ne le faisais pas. J'ai payé pour l'apprendre.

Le crawl outil : ce que Screaming Frog révèle sur PrestaShop

Le SQL montre ce qui est en base. Pour voir ce que Google voit, il faut crawler. Screaming Frog, configuré avec un filtre sur le paramètre ?q= (celui du module Faceted Search), m'a révélé 1 284 URL dupliquées sur une boutique de 600 produits. Autrement dit : plus de deux tiers des pages crawlées étaient des doublons.

Le filtre est simple : dans Screaming Frog, on ajoute un "Query Parameter" à ignorer ou à traiter séparément. Pour PrestaShop, les paramètres à surveiller sont :

• q (filtres à facettes)
• order (tri par prix, référence, etc.)
• page (pagination)
• id_category (quand il traîne dans les URL produits)
• rewrite (anciennes URL réécrites)

Je me souviens de la première fois où j'ai vu cette liste de 1 284 URL. J'ai cru à une erreur de configuration du crawler. Non. C'était simplement la réalité de ma boutique.

Balises canoniques : les configurer ne suffit pas

PrestaShop propose une option "Redirection vers l'URL canonique" dans les préférences SEO. Beaucoup de tutors la recommandent. Je l'ai activée, et j'ai cru le problème réglé. Il ne l'était pas.

L'erreur classique : la canonique qui pointe vers une page noindex

Le piège, c'est que la canonique générée par PrestaShop reprend l'URL de la page telle qu'elle est construite au moment de l'affichage. Si vous activez un filtre, la page filtrée affiche une canonique qui pointe vers la version filtrée — pas vers la version neutre. Résultat : Google voit une page "A" canonicalisée vers elle-même, pendant que la page "A" d'origine existe toujours. Deux URL, deux canoniques, zéro signal clair.

La solution que j'ai finalement appliquée, après des mois d'erreurs : désactiver la canonique automatique pour les pages de filtres et la définir manuellement dans le template du module Faceted Search. Concrètement, dans le fichier du module, on force la balise :

Où $url_canonique est construite à partir de la catégorie de base, sans les paramètres de filtre. Cette approche a réduit de 41 % le nombre d'URL indexées sur ma boutique — et le trafic organique a repris en quatre à six semaines.

Données structurées et canoniques : le conflit silencieux

Voici un point que presque personne n'aborde. Les données structurées Product et Offer de PrestaShop sont générées dynamiquement. Si une URL dupliquée (avec filtre, par exemple) affiche ces données structurées, Google reçoit deux signaux contradictoires : la canonique dit "cette page est un doublon", mais le schéma dit "cette page est un produit à part entière avec une offre valide".

Google, dans ce cas, peut choisir d'indexer la page filtrée comme page produit principale. J'ai vu ça arriver : une URL de catégorie avec un filtre "couleur : bleu" s'est retrouvée classée pour le nom du produit, pendant que la fiche produit réelle perdait son classement.

La correction : dans le template du module Faceted Search, on conditionne l'affichage des données structurées. Si la page comporte des paramètres de filtre actifs, on supprime le schéma Product. On ne garde que le schéma BreadcrumbList et ItemList si pertinent.

Vérifiez toujours l'outil de test des données structurées après avoir modifié un template. Une erreur JSON-LD passe souvent inaperçue pendant des semaines.

Filtres à facettes : les paramètres à ignorer dans la Search Console

La Search Console dispose d'une section "Paramètres d'URL" qui permet d'indiquer à Google quels paramètres doivent être ignorés. Peu de boutiques PrestaShop l'utilisent correctement. Erreur.

Sur ma boutique, j'ai configuré trois paramètres à ignorer :

• q — les filtres à facettes
• order — les tris
• page — uniquement pour les pages au-delà de la première page de catégorie

L'effet a été net : Google a cessé de crawler des centaines d'URL inutiles, et la "crawl budget" s'est concentrée sur les pages réelles. En trois mois, le nombre de pages indexées est passé de 2 100 à 1 350, mais le trafic a augmenté de 23 % parce que les pages indexées étaient enfin les bonnes.

robots.txt : bloquer les combinaisons de filtres non pertinentes

Tous les filtres ne doivent pas être bloqués. Un filtre "promotions" ou "nouveautés" peut créer une page utile. Mais un filtre combinant trois attributs (couleur + taille + matière) génère généralement des pages sans intérêt, avec un contenu identique à 98 %.

Dans mon robots.txt, j'ai ajouté :

Disallow: /recherche?q=

Disallow: /?q=&q=

Le second pattern bloque les combinaisons de filtres (quand le paramètre q apparaît deux fois). C'est une protection supplémentaire, pas un remplacement des canoniques. Les deux mécanismes sont complémentaires : robots.txt économise le crawl, la canonique consolide la pertinence.

Variantes produits : gérer les déclinaisons sans se saborder

Le cas des déclinaisons (tailles, couleurs) est particulier. PrestaShop génère par défaut une URL unique par combinaison. Si vous avez un t-shirt en 6 tailles et 4 couleurs, cela fait potentiellement 24 URL pour un seul produit.

Ma décision, après test : mettre en noindex toutes les pages de variantes et ne laisser indexable que la fiche produit principale. La configuration se fait dans le champ "meta robots" des déclinaisons, ou via une surcharge de template.

Le résultat m'a surpris : les pages de variantes ne généraient quasiment aucun trafic organique direct (moins de 2 % du total), mais elles diluaient les signaux de la fiche principale. Après le noindex, la fiche principale a gagné en position pour des requêtes de type "[produit] + [couleur]" — ce qu'elle ne faisait pas avant.

Redistribuer le link juice après consolidation

Une fois les doublons consolidés (via 301 ou canoniques), il faut penser au maillage interne. Les liens internes qui pointaient vers les URL dupliquées doivent être redirigés. PrestaShop gère les redirections 301 automatiquement quand on modifie une URL produit, mais pas pour les URL de filtres.

Ma méthode : j'exporte les URL des filtres les plus visités (via les statistiques du module), je vérifie lesquelles ont des backlinks (via la Search Console), puis je mets en place des redirections manuelles vers les catégories correspondantes. Cela représente une dizaine d'URL par trimestre sur ma boutique. Peu, mais chacune concentre un peu de jus.

Flux fournisseurs : le piège de l'import brut

Le contenu dupliqué ne vient pas toujours de votre configuration. Il vient souvent de vos fournisseurs. J'ai importé pendant un an des fiches produits telles quelles, avec les descriptions fournies. Résultat : les mêmes textes que des dizaines d'autres boutiques.

La correction a été douloureuse : réécrire les descriptions des 200 produits les plus importants (ceux qui génèrent 80 % du chiffre d'affaires), et pour les autres, tronquer la description à 300 caractères et la compléter avec des données techniques provenant d'un autre champ.

Le temps investi ? Environ 40 heures sur trois mois. Le retour ? Une augmentation de 17 % du trafic organique sur les fiches réécrites, contre 3 % sur le reste du catalogue. Les données techniques dissociées (dans un champ séparé, pour éviter de créer un autre doublon) ont aussi amélioré le taux de conversion, mais c'est une autre histoire.

Les erreurs éditoriales qui créent des doublons sans le savoir

Je me suis aussi rendu coupable de copier-coller. Pas depuis internet — entre mes propres pages. Une fiche produit qui reprend la structure d'une autre, avec les mêmes phrases d'accroche, c'est un doublon partiel. Google ne pénalise pas, mais il ne sait pas quelle page classer en priorité. Résultat : les deux fiches se cannibalisent.

Depuis, chaque nouvelle fiche produit suit une règle simple : une introduction de 80 mots qui ne ressemble à aucune autre (on écrit le texte avant de regarder les fiches existantes), puis les données techniques standardisées. Cette méthode ne garantit pas l'originalité totale, mais elle évite le pire.

Le contenu dupliqué sur PrestaShop n'est pas un bug qu'on corrige une fois pour toutes. C'est une discipline de maintenance. Entre les nouveaux produits importés, les modules qui génèrent des URL, et les campagnes marketing qui ajoutent des paramètres, il faut un audit régulier.

La question qui reste, et que je me pose encore : combien de boutiques perdent silencieusement du trafic parce que personne ne regarde au-delà du back-office ? Probablement plus que celles qui en parlent.