Structure d’URL PrestaShop : URL propres, canonicals et contenu dupliqué

La structure d'URL de votre boutique PrestaShop est la décision SEO qui façonne discrètement tout le reste. Elle décide combien de copies de chaque produit Google peut trouver, combien de crawl budget part dans des doublons, et — le jour où vous la changez — si des années de positions survivent ou disparaissent. PrestaShop est particulièrement exposé à un problème précis : par défaut, il intègre le chemin de catégorie dans les URL produit, donc un seul produit présent dans deux catégories devient deux URL pour la même chose. C'est du contenu dupliqué que la plateforme crée automatiquement pour vous, et c'est le coeur de ce guide : arriver à une URL propre et unique par page, puis migrer vers elle sans brûler votre trafic.

C'est la version pratique — réglages back-office, colonnes de base de données, mécanique de redirection — pas le cours théorique sur « ce qui fait une bonne URL ». Si vous voulez seulement savoir ce que sont les friendly URLs et pourquoi les activer, la question plus courte est traitée dans ce que sont les friendly URLs et pourquoi chaque boutique PrestaShop en a besoin. Cet article suppose que vous les avez déjà activées et que vous devez maintenant corriger la structure d'URL dessous.

Où vit réellement le comportement d'URL de PrestaShop

Avant de changer quoi que ce soit, sachez quels interrupteurs vous manipulez. Le comportement d'URL de PrestaShop se contrôle depuis Shop Parameters → Traffic & SEO → Set up URLs (en 1.6, c'était Preferences → SEO & URLs). Les réglages importants pour la structure :

• Friendly URL (PS_REWRITING_SETTINGS) — transforme ?id_product=42&controller=product en slug lisible. Cela demande la réécriture d'URL (Apache mod_rewrite ou règles Nginx équivalentes) et écrit le bloc de rewrite dans votre .htaccess.
• Accented URL (PS_ALLOW_ACCENTED_CHARS_URL) — laissez désactivé sauf raison volontaire ; les slugs ASCII sont plus sûrs pour les crawlers et les partages.
• Redirect to the canonical URL (PS_CANONICAL_REDIRECT) — réglé sur 301 Moved Permanently, PrestaShop redirige lui-même une requête qui ne correspond pas au slug canonique de la page vers le bon. C'est votre première défense contre les URL dupliquées, et ce réglage est souvent laissé par erreur sur le plus faible 302 ou No redirection.

Le slug réel de chaque page est stocké comme link_rewrite dans la base de données — ps_product_lang, ps_category_lang et ps_cms_lang ont chacun une colonne link_rewrite, une ligne par langue. C'est cette valeur que PrestaShop assemble pour construire votre URL. C'est important parce qu'un « changement d'URL » dans PrestaShop est en réalité une modification de ces colonnes plus du modèle de route — pas une réécriture libre — et tout ce que vous corrigez dans le back office finit ici.

Pour un audit rapide des slugs dupliqués, commencez par la table produit dépendante de la langue. Ajustez le préfixe ps_ si votre boutique utilise un autre préfixe de base :

SELECT id_lang, link_rewrite, COUNT(*) AS products
FROM ps_product_lang
GROUP BY id_lang, link_rewrite
HAVING COUNT(*) > 1
ORDER BY products DESC, link_rewrite;

Le problème de contenu dupliqué que PrestaShop construit

Voici la faille structurelle précise. Les routes produit, catégorie et CMS natives de PrestaShop incluent normalement des tokens d'ID, et la route produit inclut souvent aussi le chemin de catégorie. Un produit affecté à Bags et à Sale peut donc être accessible par plusieurs adresses teintées de catégorie, avec l'ID produit toujours présent dans la route. Même produit, même contenu, plusieurs adresses.

PrestaShop essaie de couvrir cela en émettant une balise canonique vers le chemin de la « catégorie par défaut » du produit et, si PS_CANONICAL_REDIRECT est réglé sur 301, en redirigeant les autres. En pratique, nous voyons encore Google indexer les variantes non canoniques sur beaucoup de boutiques — les liens internes, anciens sitemaps et liens externes continuent d'alimenter les alternatives, et les signaux de classement se divisent entre des copies qui devraient n'en faire qu'une. Qu'est-ce que cela vous coûte ? Un produit qui pourrait se classer avec la force de tous ses liens se retrouve à se concurrencer lui-même, et votre crawl budget est dépensé à récupérer des doublons au lieu de découvrir de nouvelles pages.

La correction propre consiste à retirer la dépendance à la catégorie des URL produit et, si vous voulez des chemins sans ID, à utiliser un module de friendly URL qui fournit le routing pour les URL en {rewrite} seul :

Une URL produit plate donne à chaque produit une seule adresse, quel que soit le nombre de catégories auxquelles il appartient. Les catégories elles-mêmes bénéficient encore d'une hiérarchie peu profonde (/bags/leather-bags indique aux utilisateurs et à Google où ils se trouvent) — gardez-la simplement à environ deux niveaux et ne placez pas les produits dessous. Le routing sans ID relève d'un module, pas d'une simple modification de route native PrestaShop ; notre Smart SEO Friendly URL Manager gère modèles d'URL personnalisés, overrides, collisions et redirections depuis le back office, afin de changer la structure sans modifier les routes à la main ni risquer une faute qui met le catalogue en erreur 500.

Les sources plus petites de contenu dupliqué, au même endroit

Les chemins de catégorie sont le gros problème, mais quatre duplications moins chères à fermer méritent d'être traitées dans la même passe — chacune est une correction serveur d'une ligne :

• www vs non-www — si www. et le domaine nu répondent tous deux, chaque page existe deux fois. Choisissez-en un, redirigez l'autre en 301 dans .htaccess (PrestaShop expose aussi un réglage Redirect to the canonical URL/domaine dans Traffic & SEO).
• HTTP vs HTTPS — même problème ; forcez HTTPS avec une 301 et activez Enable SSL on all pages dans PrestaShop.
• Trailing slash — /wallets et /wallets/ sont deux URL différentes. Le défaut PrestaShop est sans slash final ; gardez-le et redirigez la variante avec slash.
• Paramètres de tracking — ?utm_source=… crée une infinité de variantes. Une canonique auto-référente correcte les neutralise ; vérifiez seulement que PrestaShop ne recopie pas les paramètres dans la balise canonique elle-même.

La balise canonique est l'outil qui fait la plupart du travail discret dans cette liste, et elle mérite plus qu'une note de bas de page — sa génération, le moment où remplacer le comportement par défaut de PrestaShop, et les cas limites de pagination sont expliqués dans canonical URLs: one simple tag that prevents duplicate content problems. Pour contrôler finement ce que PrestaShop place dans la canonique des pages produit, notre Product Canonical Manager vous permet de la définir par produit au lieu d'accepter la logique de catégorie par défaut.

Quand vous devez — et ne devez pas — changer les URL

Changer la structure d'URL comporte un vrai risque, donc la première question est de savoir si vous en avez besoin. Bonnes raisons : chemins de catégorie qui divisent les produits en URL dupliquées, migration de 1.6 vers 1.7/8/9 qui a modifié vos patterns, ou restructuration de catalogue qui a déjà déplacé vos URL catégorie. Raisons cosmétiques — « les ID sont laids », « je préférerais sans .html » — ne valent généralement pas le risque.

La règle que nous suivons : une URL qui ranke vaut plus qu'une jolie URL qui repart de zéro. Si un produit situé sur /42-blue-wallet est en première page, retirer l'ID ne vous apporte rien et met la position en danger. Ne restructurez que là où la structure actuelle crée activement des doublons ou du gaspillage.

Ce que coûte vraiment une migration d'URL quand elle tourne mal

Soyons directs, parce que nous avons nettoyé assez de cas : un changement d'URL sans plan complet de redirection provoque de manière fiable une vraie baisse immédiate de trafic pendant que Google recrawle et réévalue chaque adresse modifiée, et certaines pages peuvent sortir de l'index pendant cette période. Les dégâts viennent de quatre endroits :

• Backlinks perdus — chaque lien externe vers une ancienne URL arrive sur une 404 s'il n'est pas redirigé, et l'équité portée par ces liens ne se transfère nulle part.
• Liens internes cassés — menus, footers, cross-sells, pages CMS et templates e-mail contiennent des URL codées en dur qui cassent simplement.
• Crawl budget gaspillé — si les anciennes URL renvoient encore 200 en parallèle des nouvelles, Google crawle les deux, doublant la demande pour zéro gain.
• Temps de récupération en semaines, pas en jours — même une migration parfaite demande du temps à Google pour retraiter ; les retours du secteur parlent souvent de migrations bien exécutées qui récupèrent sur quelques mois, mais prenez tout pourcentage comme directionnel et surveillez vos propres données.

Rien de cela n'est une raison d'éviter une migration nécessaire. C'est la raison de faire les quatre étapes suivantes dans l'ordre.

Étape 1 — Cartographiez chaque URL avant de toucher quoi que ce soit

Vous ne pouvez pas rediriger ce que vous n'avez pas listé. Construisez un seul tableur qui devient votre carte de migration, avec une ligne pour chaque URL qui a déjà été indexée, liée ou qui a reçu du trafic :

• Crawlez le site en ligne avec Screaming Frog, Sitebulb ou équivalent et exportez toutes les URL. Marquez les patterns spécifiques à PrestaShop : produits accessibles via plusieurs chemins de catégorie, URL préfixées par ID, URL à paramètres (?id_product=…&controller=product) et pagination profonde (?page=2…50).
• Exportez vos URL qui rankent depuis Search Console → Performance → Pages sur les 16 mois complets. Ce sont les pages que Google valorise activement — chacune a besoin d'une destination.
• Exportez les données de backlinks (Ahrefs, Semrush ou rapport Links de GSC) pour savoir quelles anciennes URL portent de l'équité externe. Ce sont vos redirections les plus prioritaires.

Colonnes à garder : URL actuelle, statut HTTP, canonique actuelle, nombre de backlinks, clics organiques mensuels, et URL cible. Cette dernière colonne est le travail des étapes 2 et 3.

Étape 2 — Concevez la nouvelle structure

Pour PrestaShop, les décisions de structure se réduisent à une courte liste :

• Aplatir les URL produit — avec un module de friendly URL, utilisez un pattern produit de type {rewrite} afin que les produits soient à la racine et cessent de se dupliquer entre catégories. C'est le changement de plus forte valeur pour la plupart des boutiques qui ont besoin d'URL sans ID.
• Gardez une hiérarchie de catégories peu profonde — deux niveaux, minuscules, séparés par des tirets.
• Retirez les ID, .html et préfixes de langue inutiles — mais seulement sur les URL qui ne rankent pas déjà (voir la règle plus haut). Une boutique monolingue ne gagne rien avec /en/ dans chaque chemin.
• Tirets, toujours en minuscules — Google lit blue-wallet comme deux mots et blue_wallet comme un seul ; les URL sont sensibles à la casse, donc /Blue-Wallet et /blue-wallet sont deux pages différentes. Vos valeurs link_rewrite doivent être en minuscules, avec tirets, sans accents ni caractères spéciaux.

Étape 3 — Construisez une carte de redirection un-à-un

C'est l'étape qui décide si la migration survit. La règle d'or : chaque ancienne URL redirige en 301 vers son équivalent direct — le même contenu à sa nouvelle adresse, jamais une redirection globale vers la page d'accueil. Tout mapper vers la page d'accueil est lu par Google comme une soft 404 ; les signaux de classement de l'ancienne URL sont simplement jetés.

/42-wallets                      → /wallets
/bags/leather-bags/blue-wallet   → /blue-wallet
/123-blue-wallet.html            → /blue-wallet

Pour les pages sans équivalent — un produit arrêté — suivez cet ordre : rediriger vers le produit de remplacement le plus proche ; à défaut, vers la catégorie parente ; et seulement si aucun n'existe, retourner un 410 Gone (qui indique à Google de supprimer l'URL plus vite qu'une 404).

Évitez les chaînes de redirection. A → B → C compte comme plusieurs URL crawlées pour un seul contenu, ajoute de la latence à chaque saut et perd un peu d'équité à chaque étape. Si vous portez des redirections d'une migration précédente, repointez-les directement vers la destination finale :

Bad:  /old-url → /intermediate → /final
Good: /old-url → /final

Étape 4 — Implémentez les redirections dans PrestaShop

Trois routes réalistes, adaptées à différentes boutiques :

Pour une approche .htaccess, les règles de pattern couvrent proprement les changements de masse :

# remove .html extension
RewriteRule ^(.+)\.html$ /$1 [R=301,L]
# strip leading ID prefix
RewriteRule ^[0-9]+-(.+)$ /$1 [R=301,L]
# drop /en/ on a single-language store
RewriteRule ^en/(.*)$ /$1 [R=301,L]

[R=301,L] signifie « retourner une redirection permanente et arrêter de traiter les règles suivantes ». Pour la plupart des marchands, la route module est plus sûre : un gestionnaire de redirections basé en base donne l'import CSV pour des milliers de lignes, la capture automatique des 404 avec suggestions de cibles, et aucun risque qu'une faute de regex casse la boutique.

Étape 5 — Mettez à jour tout ce qui pointe encore vers les anciennes URL

Les redirections sont un filet de sécurité, pas un substitut. Chaque référence interne doit pointer directement vers la nouvelle URL, sinon vous gaspillez du crawl budget et ajoutez de la latence à votre propre navigation. Balayez :

• Menus de navigation, footer, liens de sidebar
• Contenu des pages CMS et liens produit/catégorie codés en dur dans les descriptions produit
• Templates e-mail — confirmation de commande, expédition, panier abandonné
• Flux Google Merchant Center et données structurées JSON-LD (les deux embarquent des URL produit)
• La base elle-même — confirmez que les valeurs link_rewrite dans ps_product_lang, ps_category_lang et ps_cms_lang sont propres pour chaque langue, pas seulement la langue par défaut
• Votre sitemap XML — régénérez-le avec seulement les nouvelles URL ; la mécanique est dans le guide complet des sitemaps XML pour le SEO PrestaShop

Boutiques multilingues : le nombre de redirections se multiplie

Chaque produit existe une fois par langue — /en/blue-wallet, /de/blaue-brieftasche, /fr/portefeuille-bleu — donc un changement de structure en anglais demande une redirection correspondante dans chaque autre langue. Gardez les préfixes de langue (ils indiquent à Google quelle version servir), assurez-vous que vos balises hreflang pointent vers les nouvelles URL dans toutes les versions, et mettez à jour link_rewrite pour toutes les langues. Un catalogue de 5 000 produits en quatre langues peut demander environ 20 000 redirections pour une restructuration complète — exactement pourquoi le tableur de l'étape 1 doit être complet avant de commencer.

Après le déploiement : vérifiez, puis surveillez

Les 72 premières heures sont mécaniques, pas stratégiques. Vérifiez 50–100 anciennes URL et confirmez que chacune renvoie une seule 301 vers la bonne destination, scannez vos logs serveur pour repérer tout pic de 404 signalant un mapping manqué, et resoumettez le nouveau sitemap. Ensuite, la migration devient un travail de suivi Search Console — lecture semaine par semaine des rapports Performance et Pages, différence entre une baisse normale et un vrai problème, et moment où « Crawled – currently not indexed » signifie quelque chose — un workflow traité dans Google Search Console for PrestaShop: setup, monitoring and fixing errors. Gardez en place définitivement les redirections qui ont des backlinks ; les autres peuvent être retirées après environ un an, une fois que les sites externes ont mis à jour leurs liens.

Le résumé honnête

Une restructuration d'URL PrestaShop est un projet — audit, plan, carte de redirections, implémentation, nettoyage des liens internes, régénération du sitemap, semaines de monitoring — pas un bouton de vendredi après-midi. Mais quand les chemins de catégorie divisent vos produits entre URL dupliquées et que le crawl budget se vide dans des variantes à paramètres, la structure plus plate, une URL par page, se rembourse par la consolidation des signaux de classement et un crawl plus propre. Planifiez correctement, redirigez tout un-à-un, corrigez les références internes, et laissez à Google quelques mois pour se stabiliser. Une migration bien exécutée récupère. Une migration précipitée est le genre de dégâts que l'on nous appelle pour réparer. Pour le cadre SEO plus large dans lequel ce travail d'URL s'inscrit, commencez par le guide complet pour mieux classer votre boutique PrestaShop.