Faut-il supprimer les identifiants dans les URL PrestaShop ?

Un module promet des URLs produit sans le fameux 12-mon-produit.html, juste mon-produit.html. L’idée séduit tout le monde, mais la question à trancher n’est pas « est-ce plus joli », elle est « combien de collisions de slug ça va créer sur mon catalogue, et suis-je prêt à gérer la migration ». Voici l’arbitrage complet.

Le débat, tel qu’il existe vraiment

D’un côté, des modules comme Pretty URL promettent de retirer l’identifiant numérique en tête d’URL produit, avec l’argument qu’une URL plus courte et plus lisible aiderait le référencement. De l’autre, des experts PrestaShop de longue date qualifient carrément ces modules d’arnaque, pointant une complexité de routage accrue, des risques de collision et une dégradation potentielle des performances puisque le serveur doit rechercher le produit par son texte plutôt que d’accéder directement via son identifiant.

Les deux camps ont raison sur des points différents : le gain SEO de retirer l’ID est réel mais marginal, le risque technique est réel mais gérable si on le traite sérieusement. Le tort commun aux deux discours, c’est de présenter la question comme binaire alors qu’elle dépend presque entièrement d’une variable que personne ne chiffre : la taille de votre catalogue.

Ce que l’ID fait techniquement dans l’URL

PrestaShop propose nativement deux formats d’URL réécrite pour un produit : {id}-{rewrite}.html (avec l’identifiant, format par défaut) et {rewrite}.html (sans, option à activer dans Préférences puis SEO et URLs). Le champ rewrite est le « slug » du produit : un texte dérivé du nom, unique par construction quand l’ID le précède, mais qui doit être unique À LUI SEUL dès que vous retirez l’ID.

C’est là que la promesse de simplicité rencontre sa limite. PrestaShop ne garantit pas nativement l’unicité d’un slug produit à travers tout le catalogue quand deux fiches portent un nom proche : « T-shirt col rond noir » en taille S et en taille M, deux variantes de couleur du même modèle, ou simplement deux produits différents avec un nom commercial similaire. Avec l’ID en préfixe, cette collision est structurellement impossible. Sans lui, elle devient une question de probabilité, qui grandit avec le nombre de références.

Le vrai risque : la collision de slug à l’échelle du catalogue

Sur un catalogue de quelques dizaines de produits aux noms très différents (boutique de services, catalogue de niche), le risque de collision reste faible : chaque fiche a un nom suffisamment distinct pour générer un slug unique. Sur un catalogue de plusieurs centaines ou milliers de références avec des variantes de couleur, taille ou modèle (mode, pièces détachées, équipement), le risque grimpe mécaniquement : plus vous avez de produits qui partagent un radical de nom commun, plus vous avez de chances que deux slugs générés automatiquement entrent en collision.

Quand une collision survient, PrestaShop ne bloque pas la création du produit : il modifie silencieusement le slug généré pour le rendre unique, en général en ajoutant un suffixe numérique (mon-produit-2.html). Résultat concret : une partie de vos URLs finit quand même avec un nombre dedans, sauf que ce n’est plus l’identifiant stable du produit, c’est un suffixe arbitraire qui peut changer si vous modifiez ou recréez une fiche. Vous perdez l’avantage de stabilité de l’ID natif sans obtenir la promesse de propreté totale de l’URL.

Ce que Google fait réellement de l’ID dans l’URL

Sur le plan strictement SEO, la position de Google est constante depuis des années : la présence d’un identifiant numérique en début d’URL n’est pas un facteur de classement négatif. Google explore et indexe sans difficulté des URLs contenant des chiffres ; ce qui compte pour le classement, c’est le contenu de la page, sa pertinence, son maillage interne et son autorité, pas l’esthétique de son URL. L’argument « l’ID nuit au référencement » que l’on retrouve dans certains argumentaires commerciaux de modules n’est pas soutenu par la documentation officielle de Google sur la structure d’URL.

Ce qui reste vrai, en revanche, c’est l’argument d’expérience utilisateur et de partage : une URL sans ID est plus lisible dans une barre d’adresse, plus propre à coller dans un email ou un réseau social, plus facile à mémoriser. C’est un gain réel, mais un gain de forme, pas un gain de fond sur le classement.

Comment décider pour votre boutique

Si vous décidez de le faire : traitez-le comme une migration

Changer le format d’URL de tout un catalogue produit n’est pas un simple réglage qu’on bascule un dimanche soir. C’est un changement d’URL de masse, avec toutes les conséquences qu’implique une migration.

1. Auditez les doublons de nommage avant de basculerExportez la liste de vos noms de produits et repérez les radicaux communs (mêmes premiers mots) qui généreraient des slugs proches, avant que PrestaShop ne les découvre à votre place.
2. Activez la redirection automatiquePrestaShop propose nativement, dans Préférences puis SEO et URLs, une option de redirection automatique vers l’URL canonique : assurez-vous qu’elle est active avant le changement de format, pour que les anciennes URLs avec ID redirigent en 301 vers les nouvelles.
3. Surveillez la Search Console pendant 4 à 6 semainesSuivez le rapport Pages pour vérifier que les nouvelles URLs sont indexées et que les anciennes basculent proprement en « Page avec redirection », sans pic d’erreurs 404.
4. Ne touchez pas au catalogue la même semaineÉvitez de lancer une opération de changement d’URL en même temps qu’un import massif de nouveaux produits : cela complique le diagnostic si une anomalie apparaît.

Questions fréquentes