Comment configurer les URL simplifiées sur PrestaShop ?

Activer les URL simplifiées sur PrestaShop tient en trois clics. Le vrai sujet commence après : quel format choisir, ce qui se passe réellement quand vous renommez une fiche produit déjà indexée, et comment ne pas transformer un simple changement de slug en vague de 404. La documentation officielle décrit les champs à remplir, rarement leurs conséquences.

Activer les URL simplifiées : la manipulation de base

Le réglage vit dans Paramètres de la boutique > Trafic et SEO (le libellé exact glisse légèrement selon la version, parfois affiché seul sous « SEO & URLs »). Quatre étapes suffisent pour l’activation elle-même, la difficulté se loge ailleurs : dans ce que votre serveur accepte réellement de faire.

Sur Apache : mod_rewrite et AllowOverride, deux prérequis invisibles

PrestaShop écrit ses règles de réécriture dans un fichier .htaccess, un mécanisme propre à Apache. Il faut que le module mod_rewrite soit chargé (vérifiable en ligne de commande via apache2ctl -M | grep rewrite si vous avez l’accès serveur) et que la directive AllowOverride All soit active sur le virtual host, sans quoi le .htaccess est tout simplement ignoré, quelle que soit la configuration côté PrestaShop.

Sur Nginx : rien d’automatique, tout se recrée à la main

Sur Nginx, le .htaccess ne sert à rien : ce serveur ne le lit pas. La réécriture doit être recréée manuellement dans le bloc server {}, typiquement avec une directive try_files $uri $uri/ /index.php?$args;, et rechargée (nginx -t puis systemctl reload nginx). Sur un hébergement mutualisé, cette étape échappe souvent à la main du marchand : c’est l’hébergeur qui la pose, ou elle n’est jamais faite, et l’option « Oui » côté back-office reste sans effet sans qu’aucun message d’erreur ne le signale.

Choisir le format d’URL : un arbitrage que la doc ne détaille pas

Une fois la réécriture active, PrestaShop propose plusieurs gabarits dans Format des URLs, construits à partir de variables : {id}, {rewrite}, {category:/}, {-:ean13}. Le choix par défaut combine ID et slug : {id}-{rewrite}.html. Beaucoup de guides recommandent de retirer l’ID pour une URL « plus propre » en {rewrite}.html seul. C’est esthétiquement vrai et opérationnellement risqué.

Avec ID : l’identifiant numérique reste le repère technique

Deux produits ne peuvent jamais entrer en collision, même si leurs noms se ressemblent, puisque l’identifiant les distingue. C’est le choix pragmatique par défaut au-delà de quelques centaines de références, là où la probabilité de noms proches ou identiques cesse d’être négligeable.

Sans ID : une URL plus lisible, mais qui dépend entièrement de la discipline de saisie

Le format {rewrite}.html produit des adresses plus courtes et plus agréables à partager, mais retire le filet de sécurité de l’ID : si deux fiches génèrent le même slug, PrestaShop doit trancher, et un module tiers (type « Pretty URL » cité par plusieurs guides) devient nécessaire pour détecter ces collisions avant qu’elles ne créent une page qui écrase silencieusement l’autre dans les résultats de recherche.

Sur un catalogue de service, une boutique de niche ou un site vitrine avec quelques dizaines de références maîtrisées une par une, le format sans ID reste défendable. Au-delà, gardez l’ID : le gain esthétique ne compense pas le risque de collision non détectée sur un catalogue qui évolue vite.

Rédiger des URLs qui servent réellement le référencement

Trois règles suffisent, le reste relève du bon sens plus que d’une checklist rigide.

Différenciez sans complexifier. Deux produits au nom proche ne se distinguent pas en ajoutant une référence technique ou un code EAN13 dans le slug : ce texte n’a aucune valeur de recherche pour un visiteur et alourdit l’URL sans rien apporter à Google. Préférez un détail réellement identifiant pour l’acheteur, la couleur, la taille, la matière (montre-chrono-bracelet-cuir-noir plutôt qu’un numéro de référence fournisseur).

Ne diluez pas le sens par excès de longueur. Une URL qui empile catégorie, sous-catégorie, marque et variante devient difficile à lire pour un humain et complexifie le maillage interne, chaque lien devant reproduire exactement cette chaîne. Le préfixe de catégorie ({category:/}) apporte de la hiérarchie utile jusqu’à deux niveaux, rarement au-delà.

Gardez une cohérence de nommage. Si la page qui liste vos marques s’appelle marques, la fiche d’une marque particulière devrait suivre le même vocabulaire plutôt que basculer sur brand ou fabricant selon les pages : l’incohérence ne pénalise pas directement le référencement, mais elle complique la maintenance et finit toujours par produire des oublis.

Modifier une URL déjà en ligne : ce qui casse et ce qui a été corrigé

C’est le point que les guides généralistes n’abordent presque jamais, alors qu’il concerne toute boutique qui vit (renommage d’une catégorie pour une opération commerciale, correction d’une fiche produit mal nommée à l’origine). Le comportement de PrestaShop n’est pas le même selon le type de page, et cette différence n’est écrite nulle part dans la documentation utilisateur.

Catégories et pages CMS : un couplage supprimé depuis PrestaShop 8

Pendant longtemps, renommer le nom affiché d’une catégorie ou d’une page CMS modifiait automatiquement son URL rewrite : deux champs qu’un marchand modifie pour des raisons purement éditoriales (clarifier un intitulé, corriger une faute) étaient techniquement couplés. Un simple renommage marketing, sans aucune intention SEO, cassait donc silencieusement une URL indexée. Le problème est documenté et corrigé côté PrestaShop : l’issue officielle sur le dépôt GitHub du projet (« No link at all between category name/CMS page name and category rewrite ») a été fermée avec un correctif validé pour la version 8.0.0. Sur une boutique à jour, renommer l’intitulé d’une catégorie ne modifie donc plus automatiquement son URL.

Sur une installation qui n’a pas suivi cette montée de version, le couplage peut subsister : un renommage de catégorie fait par l’équipe marketing, sans passer par vous, reste un scénario de rupture d’URL silencieuse à vérifier explicitement si le socle technique n’a pas été mis à jour récemment.

Fiches produit : un champ resté totalement manuel, à toutes les versions

Le champ « URL réécrite » d’un produit (onglet SEO & Référencement de la fiche) n’a, lui, jamais bénéficié de ce correctif, et pour cause : ce n’est pas un champ dérivé automatiquement d’un autre, c’est un champ libre que vous éditez directement. Le modifier change immédiatement l’URL résolue par PrestaShop. L’ancienne adresse ne redirige nulle part par défaut : elle devient une 404 dès l’enregistrement, sans avertissement dans le back-office et sans redirection automatique créée par le CMS, quelle que soit la version de PrestaShop utilisée.

La règle opérationnelle qui en découle est simple : avant de toucher au champ URL réécrite d’un produit déjà indexé, créez la redirection 301 en premier (cf. section suivante), ou immédiatement après l’enregistrement, jamais après coup une fois l’erreur 404 remontée dans Search Console.

Renommer des centaines d’URLs sans tout casser

Éditer un slug produit par produit devient intenable au-delà de quelques dizaines de références. La méthode par import CSV, documentée par plusieurs guides PrestaShop, répond au volume mais amplifie mécaniquement le risque décrit plus haut : renommer 300 slugs en un seul import, c’est 300 ruptures potentielles si les redirections ne suivent pas dans la même opération.

1. Exporter le catalogue actuelDepuis Catalogue > Produits > Exporter, en conservant la colonne link_rewrite et les URLs actuelles : c’est votre seule trace des adresses avant modification.
2. Construire la table de correspondanceAvant toute réimportation, dressez la liste ancienne URL / nouvelle URL dans un tableur séparé. C’est ce fichier, et non votre mémoire, qui alimentera les redirections à créer juste après.
3. Modifier la colonne link_rewriteÉditez les nouveaux slugs dans le CSV exporté, sans toucher aux autres colonnes.
4. Réimporter en cochant « Charger les champs par leur nom »Cette option évite de réimporter par position de colonne, source d’erreurs si l’ordre des champs a bougé entre export et import.
5. Créer les redirections dans la foulée, pas plus tardÀ partir de votre table de correspondance, postez les 301 (interface native ou .htaccess, cf. section suivante) avant de considérer l’opération terminée.

Configurer les redirections : interface native ou .htaccess

PrestaShop propose une interface dédiée dans SEO & URLs > Redirections : ancienne URL, nouvelle URL, code 301 (permanent, Google remplace l’ancienne adresse dans son index) ou 302 (temporaire, Google conserve l’ancienne en mémoire). Pour un volume raisonnable, c’est la voie la plus sûre : elle survit aux régénérations du .htaccess.

L’édition manuelle du .htaccess reste possible pour les profils techniques, à une condition stricte : les règles personnalisées doivent être insérées avant le commentaire # ~~start~~ qui ouvre le bloc géré par PrestaShop. Ce bloc est entièrement réécrit à chaque régénération automatique (activation d’une option, changement de format d’URL) : toute redirection ajoutée à l’intérieur des marqueurs ~~start~~ et ~~end~~ disparaît au prochain enregistrement, silencieusement, sans qu’aucun message ne le signale. C’est une cause fréquente de redirections qui « fonctionnaient hier » et ont disparu après un simple changement de réglage SEO sans rapport apparent.

La redirection 301 n’est pas le seul outil de ce chantier : quand deux URLs valides coexistent pour un même contenu (produit rattaché à plusieurs catégories, variantes de tri), c’est la balise canonical qui s’applique, pas la redirection. Nous détaillons cette distinction et son implémentation native selon votre version de PrestaShop dans notre guide sur les URLs canoniques et la consolidation des signaux SEO.

URLs et multilingue : éviter la duplication silencieuse

Sur une boutique multilingue, l’option « URL multilingue » ajoute un préfixe par langue (/fr/, /en/, /de/). Chaque langue doit recevoir sa propre traduction du slug, jamais une copie du slug français avec le seul préfixe changé : une URL anglaise qui reprend un mot français ne sert ni le référencement anglophone, ni la lisibilité. Les balises hreflang, associées au sitemap XML, indiquent ensuite à Google quelle version linguistique proposer selon la langue de recherche, évitant qu’une seule version domine artificiellement les résultats dans toutes les langues.

Vérifier que le changement n’a pas cassé l’indexation

Un changement de format ou un renommage massif ne se referme pas à la réimportation : il se vérifie ensuite, sur le site en ligne, pas seulement dans la configuration.

Testez d’abord une poignée d’anciennes URLs connues (celles de votre table de correspondance) pour confirmer qu’elles redirigent bien en 301 vers la nouvelle adresse, plutôt que de répondre en 404 ou en 200 sur un contenu obsolète encore accessible. Surveillez ensuite le rapport Pages de Search Console dans les jours qui suivent : un pic soudain d’erreurs « Introuvable (404) » signale des redirections manquantes ou mal placées. Pour un volume important, un crawl complet (Screaming Frog ou équivalent) détecte en une passe les chaînes de redirection, les redirections qui pointent elles-mêmes vers une 404, et les anciennes URLs encore présentes dans votre propre maillage interne alors qu’elles devraient pointer directement vers la nouvelle adresse.

Ce qu’il faut retenir

Activer les URL simplifiées est la partie facile. La partie qui protège réellement votre référencement se joue après : le format choisi à l’échelle du catalogue, la vigilance sur ce qui casse une URL déjà indexée (différemment selon qu’il s’agit d’une catégorie ou d’un produit), et la discipline de poser une redirection avant, pas après, chaque changement. Sur un catalogue de plusieurs centaines de références, cette discipline vaut largement l’audit ponctuel qui la met en place.