Neuf

URL propres dans PrestaShop – Pretty URLs Pro | PrestaDev

URLs propres Pro module pour PrestaShop

Module version: 1.0.5

PrestaShop compatibility: 1.7.x 8.x 9.x

Fichier du module mis à jour : 2026-09-20 15:02:05

Données du produit mises à jour : 2026-08-30 06:07:35

URL propres Pro remplace les adresses PrestaShop natives avec des numéros ID par des URL courtes et canoniques construites selon des modèles que vous définissez vous-même — séparément pour chaque type de contenu, langue et boutique. Le module prend en charge les produits, catégories, pages et catégories CMS, fabricants, fournisseurs ainsi que les pièces jointes. Le déploiement est progressif : les modes observation, parallèle et actif permettent de construire et de vérifier un registre complet d’adresses avant que quoi que ce soit ne change pour les clients, et le contrôle préalable bloque l’activation tant que les problèmes détectés n’ont pas été résolus. Les anciennes adresses ne disparaissent pas : les URL natives avec ID ainsi que toute forme antérieure d’adresse sont redirigées de manière permanente (301 ou 308) en conservant les paramètres de campagne et les identifiants de clics publicitaires. Les conflits d’adresses sont résolus par une politique de collision configurable — suffixe lisible automatique, chemin parent ou décision manuelle dans une file dédiée. Grâce à la surcharge de la classe Link, les adresses propres sont également injectées automatiquement dans les flux produits, les plans de site et les autres modules, sans modifier leur code. L’ensemble repose sur son propre registre de routes avec cache fichier, tâches en arrière-plan, cron et journal d’audit, dans une architecture fail-closed : au moindre doute, la boutique utilise l’adresse native éprouvée. Le module est compatible avec PrestaShop 1.7–9.x, PHP 7.0–8.5, le multiboutique et plusieurs langues, sans Composer ni bibliothèques externes.

123,00 zł
100,00 złnetto

Price history: Show chart

La description

Principales caractéristiques et avantages

Des URL sans ID selon vos propres modèles — vous décidez vous-même de l’apparence de l’URL pour chaque type de contenu, par ex. product/nom-du-produit ou — après activation des modèles sans préfixe — même nom-du-produit.html directement à la racine de la boutique.
Zéro perte SEO lors du changement d’URL — des redirections permanentes 301/308 depuis les URL natives et depuis toute forme d’URL précédente transfèrent le positionnement acquis dans les moteurs de recherche vers les nouvelles URL au lieu de créer des doublons et des erreurs 404.
Déploiement sûr et réversible — rien ne change dans la boutique tant que vous n’activez pas vous-même le moteur ; auparavant, vous préparez et vérifiez tout en arrière-plan, et le retour en arrière se fait de manière aussi progressive que le déploiement.
Compatibilité avec les autres modules sans les modifier — la surcharge de la classe Link fait que chaque module récupérant les URL via l’API standard de PrestaShop (flux Google/Facebook, sitemaps, modules exécutés par cron et depuis le back-office) reçoit automatiquement les URL canoniques.
Gestion automatique des conflits de noms — lorsque deux éléments portent le même nom, le moteur attribue lui-même un suffixe lisible ou un chemin parent ou — si vous le définissez ainsi — attend votre décision ; rien n’est publié à l’aveugle.
Protection des pages existantes — le module détecte et réserve automatiquement les URL déjà utilisées par PrestaShop lui-même ainsi que par d’autres modules (panier, contact, plan du site), de sorte qu’une URL produit propre ne reprenne jamais une page existante.
Un panneau compréhensible même pour un non-spécialiste — un tableau de bord avec guide pas à pas, une description pour chaque option, des explications d’état sur chaque onglet ainsi que des messages de diagnostic qui indiquent clairement quoi cliquer et où, y compris des boutons de réparation en un clic.
Architecture fail-closed — en cas de moindre erreur (registre endommagé, panne du cache, conflit avec une autre modification), la boutique revient immédiatement aux URL natives au lieu d’afficher des erreurs aux clients.

Fonctionnalités en détail

Modèles et construction des URL

Un modèle d’URL distinct pour chaque type de contenu (produits, catégories, pages CMS, catégories CMS, fabricants, fournisseurs, pièces jointes) dans chaque langue et pour chaque boutique.
Jetons dans les modèles : nom convivial, chemin complet de catégorie, catégorie parente, fabricant, fournisseur, référence, préfixe de langue et autres — selon le type de contenu.
Politique globale des chemins : minuscules, caractères ASCII uniquement, slash final, limites de longueur du segment et du chemin complet, contrôle des slugs composés uniquement de chiffres — avec possibilité de surcharge par modèle.
Modèles sans préfixe fixe (URL directement à la racine) pour PrestaShop 8.1.2 et versions ultérieures, toujours vérifiés par un contrôle préalable.
Politique des URL des déclinaisons produit : une seule URL canonique commune à toutes les variantes (avec suppression de l’ancre de déclinaison après le signe #) ou conservation du paramètre fonctionnel de variante.

Déploiement progressif et diagnostic

Cinq modes du moteur : désactivé, observation uniquement, mode parallèle (les anciennes URL redirigent déjà, la boutique affiche encore les liens natifs), actif, ainsi que le mode d’urgence « actif avec fallback natif ».
Contrôle préalable (preflight) bloquant l’activation jusqu’à ce que toutes les conditions soient remplies : registre complet, validation récente, collisions résolues, tâches terminées, schéma de base correct, hooks enregistrés, absence de conflits de modèles.
Messages de diagnostic indiquant la cause exacte et l’emplacement de la correction, avec des boutons qui mettent en file d’attente en un clic les reconstructions ou validations manquantes pour les périmètres exacts concernés par le problème.
Tableau de couverture indiquant pour chaque langue et type de contenu combien d’éléments disposent déjà d’une URL propre, ainsi qu’un rapport d’intégrité du registre.
Transitions protégées entre les modes — il est impossible de passer accidentellement du mode actif au mode désactivé en contournant la vérification.

Redirections, alias et protection SEO

Redirections permanentes automatiques des URL natives avec ID vers les URL canoniques (301 ou 308 au choix), en excluant les pages de listing avec paramètres de tri et filtres.
Historique des URL : chaque modification de l’URL canonique laisse derrière elle une redirection fonctionnelle, de sorte que les favoris, publicités et résultats de recherche ne mènent jamais nulle part.
Alias manuels et importés avec comme cible un objet de la boutique, n’importe quelle URL (avec politique de sécurité des hôtes : boutique actuelle uniquement, liste de domaines HTTPS autorisés ou tout HTTPS) ou une réponse 410/404.
Codes de réponse pour les alias : 301, 302, 307, 308 ainsi que 404 et 410 ; les objets supprimés renvoient au choix 410 Gone (retrait plus rapide de l’index) ou 404.
Les redirections conservent les paramètres de campagne (utm_source, utm_medium, utm_campaign, utm_term, utm_content), les identifiants de clic publicitaire (gclid, fbclid, msclkid) ainsi qu’une liste définie de paramètres fonctionnels.
Normalisation des requêtes : les variantes d’URL différant par la casse ou le slash final sont redirigées vers une seule forme canonique, sans contenu dupliqué.
Statistiques optionnelles d’utilisation des redirections avec échantillonnage — vous voyez si quelqu’un utilise encore les anciens liens.

Compatibilité et intégrations

Surcharge (override) de la classe Link : tous les modules utilisant l’API standard des URL de PrestaShop — y compris les générateurs de flux produits et de sitemaps exécutés depuis le back-office ou par cron — reçoivent les URL canoniques sans aucune modification de leur code, avec retour automatique à l’URL native lorsqu’une URL propre n’est pas disponible.
API publique pour les développeurs : récupération unitaire et en lot des URL canoniques (avec préchargement du registre pour les générateurs de sitemaps) ainsi que des hooks permettant à d’autres modules de réserver leurs propres chemins et de réagir aux changements de routes.
Prise en charge complète du multiboutique (configuration, modèles et registre par boutique) ainsi que de plusieurs langues ; dans les anciennes versions de PrestaShop, lorsque le cœur l’exige, le module veille à l’identité des modèles entre les langues.
Compatibilité : PrestaShop 1.7.x–9.x, syntaxe PHP 7.0–8.5 (dans les limites des exigences du cœur utilisé), MySQL 5.6+/MariaDB 10.x, Apache et Nginx, boutiques en sous-répertoire — sans Composer ni bibliothèques externes.

Automatisation, tâches et performances

Mise à jour automatique : l’ajout, le changement de nom ou la suppression d’un produit, d’une catégorie ou d’une page actualise lui-même l’URL et met en file d’attente les reconstructions nécessaires, y compris les dépendances (un changement de catégorie actualise les produits, un changement de produit — les pièces jointes).
Système de tâches en arrière-plan : analyse, aperçu (sans enregistrement), reconstruction, validation, préchauffage du cache, import, export et nettoyage — exécutés par lots configurables, avec pause, reprise, annulation et vidage de toute la file d’attente par un seul bouton.
Cron en un seul lien : une URL prête à copier avec jeton secret (section Cron dans le panneau, avec instructions et ligne pour crontab) traite automatiquement la file d’attente ; les appels qui se chevauchent sont bloqués ; une interface CLI est également disponible.
Cache fichier fragmenté des routes (taille de fragment et durée de validité configurables) avec fallback vers la base de données — la résolution des URL ne surcharge pas la base à chaque affichage.
Journal d’audit des changements d’URL avec rétention configurable ainsi que nettoyage automatique des tâches terminées et des entrées expirées.
Import d’alias depuis un fichier CSV avec aperçu et validation séparés avant enregistrement (jusqu’à 500 lignes par fichier, enregistrement atomique) ainsi qu’export des paramètres, routes, alias, réservations, collisions et diagnostics en JSON/CSV — sans secrets ni données clients.

Back-office et sécurité

Un panneau clair avec tableau de bord (métriques du registre), guide repliable « Comment commencer — étape par étape » mémorisant son état, description de l’état de la configuration sur chaque onglet et descriptions pour chaque option.
Listes des chemins, alias, collisions et tâches avec le filtrage standard de PrestaShop : langue et type d’objet sous forme de listes déroulantes, ID, chemin et slug sous forme de champs texte, avec pagination native.
Autorisations conformes aux profils employés de PrestaShop (affichage, modification, suppression) appliquées dans le panneau et dans chaque action AJAX.
Sécurité : jetons et signatures des requêtes d’administration, vérification de l’origine des requêtes, comparaisons de clés résistantes aux attaques temporelles, clé opérationnelle secrète du cron par boutique, normalisation stricte des chemins rejetant les caractères de contrôle et le double encodage.
Fiabilité : installation transactionnelle avec rollback automatique et restauration de la configuration précédente en cas d’erreur, blocage de la désinstallation lorsque le routage est actif, marqueurs de panne persistants imposant le mode sûr après une erreur critique ainsi que nettoyage complet des tables et de la configuration lors de la désinstallation.

Exigences

PrestaShop 1.7.0–9.x avec les URL conviviales activées (Paramètres de la boutique → Trafic et SEO).
PHP 7.0–8.5 (version prise en charge par le cœur PrestaShop utilisé), MySQL 5.6+ ou MariaDB 10.x.
Aucune dépendance supplémentaire : le module n’utilise ni Composer ni bibliothèques externes.

détails du produit

Support pour Prestashop 9.x: Oui
Prise en charge de Prestashop 8.x: Oui
Prise en charge de Prestashop 1.7.x: Oui
Module de traduction: PL, ANG
Support gratuit: Alors
Mises à jour gratuites (1 an): Alors
Facilité d'installation: Alors

Référence PDPURLPRO

FAQ

Find answers to the most common questions about this product.

Le module remplace les adresses natives de PrestaShop contenant des numéros d’ID par des URL courtes et canoniques construites selon des modèles que vous définissez séparément pour chaque type de contenu, langue et boutique. Il prend en charge les produits, les catégories, les pages et catégories CMS, les fabricants, les fournisseurs ainsi que les pièces jointes. Les adresses sont stockées dans son propre registre de routes, et la boutique les sert depuis un cache de fichiers.

Oui, le déploiement se fait par étapes et rien ne change pour les clients tant que vous n’activez pas vous-même le moteur. Vous définissez d’abord les modèles, construisez le registre à l’aide de la tâche de reconstruction, résolvez les éventuels conflits et passez le contrôle préalable, qui bloque l’activation jusqu’à la suppression de tous les problèmes. Le mode parallèle permet en outre de tester les redirections avant que la boutique ne commence à afficher les nouvelles adresses et, en cas de panne, le module revient de lui-même aux adresses natives éprouvées.

Rien ne se perd. Les adresses natives avec numéros d’ID sont redirigées de manière permanente (301 ou 308 au choix) vers les adresses canoniques, de sorte que les moteurs de recherche transfèrent les positions acquises au lieu de voir des doublons. De plus, chaque modification ultérieure de l’adresse, par exemple après un changement du nom du produit, laisse automatiquement une redirection depuis la forme précédente, ce qui permet aux favoris, aux publicités et aux résultats de recherche de continuer à fonctionner.

C’est la politique de collision qui en décide. En mode automatique, le deuxième produit reçoit un suffixe lisible (-2, -3, etc.) ou un chemin parent ajouté, par exemple une catégorie, et la liste des collisions reste vide. Vous pouvez aussi choisir une politique de blocage ou de résolution manuelle — dans ce cas, les adresses en conflit ne sont pas publiées, mais attendent votre décision dans la file dédiée Collisions.

Oui, sans modifier leur code. Le module installe une surcharge de la classe Link, c’est-à-dire l’API standard des URL de PrestaShop, de sorte que chaque module récupérant les URL par ce biais — générateurs de flux Google et Facebook, plans de site, modules fonctionnant via cron ou depuis le panneau d’administration — reçoit automatiquement les URL canoniques. Lorsqu’une URL propre n’est pas disponible, la surcharge renvoie l’URL native standard, de sorte que l’intégration ne casse rien. Pour les développeurs, une API publique est également disponible pour la récupération unitaire et en lot des URL canoniques.

Oui. Les modèles d’adresses, le registre des routes et la configuration sont gérés séparément pour chaque langue et chaque boutique dans l’installation multiboutique. Le module réagit à l’ajout, à la modification et à la suppression d’une langue ou d’une boutique et, dans les anciennes versions de PrestaShop où le cœur l’exige, veille à ce que toutes les langues actives utilisent des modèles identiques.

Conformément à la politique sélectionnée. Dans le mode d’ignorance recommandé, toutes les variantes partagent une seule adresse canonique du produit, ce qui cumule la force SEO — l’ancre de combinaison ajoutée après le signe # est alors également supprimée. Alternativement, le module peut conserver le paramètre fonctionnel id_product_attribute dans l’adresse, afin que le lien puisse ouvrir une variante spécifique.

Vous définissez cela avec une seule option. La réponse 410 Gone informe clairement les moteurs de recherche que la page a été supprimée intentionnellement, ce qui lui permet de disparaître plus rapidement des résultats. Vous pouvez également choisir le classique 404 Not Found.

Oui, via l’import d’alias depuis un fichier CSV avec un aperçu séparé et une validation avant l’enregistrement ; un fichier peut contenir jusqu’à 500 lignes de données, et l’enregistrement est atomique. La cible de la redirection peut être un objet de la boutique, n’importe quelle URL (contrôlée par la politique de sécurité des hôtes) ou une réponse 410/404. L’export des routes, alias, réservations, collisions, paramètres et diagnostics vers JSON/CSV est également disponible.

Le fonctionnement quotidien est automatique : l’ajout, le renommage ou la suppression d’un produit, d’une catégorie ou d’une page actualise automatiquement l’adresse et met en file d’attente les reconstructions nécessaires, y compris les dépendances entre les types de contenu. Les tâches en arrière-plan sont traitées par lots depuis le panneau ou via cron — il suffit de copier le lien prêt à l’emploi avec le jeton depuis la section Cron et de l’appeler, par exemple, toutes les 5 minutes. Une interface CLI est également disponible.

Le module a été conçu pour un trafic de production : les adresses résolues sont conservées dans un cache de fichiers fragmenté avec une durée de validité et une taille de fragments configurables, de sorte que la boutique n’interroge pas la base de données pour chaque adresse à chaque affichage. Les opérations lourdes, comme la reconstruction de l’ensemble du catalogue, s’exécutent exclusivement en arrière-plan, par lots de taille configurable.

PrestaShop de 1.7.0 à 9.x avec les URL conviviales activées, PHP avec une syntaxe comprise entre 7.0 et 8.5 (dans les limites des exigences du cœur utilisé) ainsi que MySQL 5.6+ ou MariaDB 10.x. Le module fonctionne sur Apache et Nginx, y compris dans les boutiques installées dans un sous-répertoire, et n’utilise ni Composer ni de bibliothèques externes.

Le retrait est tout aussi progressif que le déploiement : du mode actif, vous revenez d’abord au mode parallèle, vous vérifiez la boutique et ce n’est qu’ensuite que vous désactivez le moteur — le module veille au respect de cet ordre. En cas de panne, il existe un mode actif avec fallback natif, dans lequel les URL propres redirigent vers les URL natives et aucun lien n’est perdu. La désinstallation est bloquée tant que le routage est actif, et après la désinstallation, le module supprime ses tables et sa configuration ; il est donc recommandé d’effectuer au préalable une sauvegarde de la base de données.

Oui, le panneau a été conçu en pensant au propriétaire de la boutique, et pas seulement au programmeur. Le tableau de bord contient un guide de mise en œuvre repliable étape par étape, chaque option comporte une description expliquant ce qu’elle fait et quelles valeurs sont sûres, et chaque onglet commence par une description tenant compte de la configuration actuelle, par exemple l’information selon laquelle les conflits se résolvent automatiquement. Les messages de diagnostic indiquent précisément la cause et l’endroit à corriger, souvent avec un bouton qui effectue la correction en un seul clic.