Le module Custom CMS Page Names donne des noms courts aux pages d'information PrestaShop sans modifier leurs titres destinés aux moteurs de recherche. La configuration tient sur un écran : toutes les pages, un nom à côté, puis un enregistrement.
PrestaShop utilise le même titre pour les moteurs, les en-têtes et la navigation. Une formulation détaillée encombre donc les liens de pied de page et les menus.
Vous définissez les noms par langue et boutique, avec le titre d'origine visible à côté de chaque champ. Ils apparaissent dans les en-têtes, liens de pied de page et menus ; un champ vide conserve le titre natif. Aucun fichier du thème ni service externe n'intervient. Effacer un nom rétablit l'affichage initial.
Votre pied de page reste lisible sans raccourcir les titres de référencement déjà rédigés.
Aperçu des possibilités du module
Custom CMS Page Names met fin à l'arbitrage entre titres optimisés pour la recherche et navigation lisible.
- Le conflit réglé : un seul champ pour le titre de recherche et les libellés visibles
- Ce qui reste intact pour les moteurs : le titre de la page, à la lettre
- Où apparaît le nom court : en-tête de page, liens du pied de page, entrées de menu
- Langues et boutiques : un nom par langue et par boutique
- L'écran de travail : toutes les pages dans un tableau, le titre de recherche à côté de chaque champ
- Sécurité : champ vide égale comportement natif, et le module ne charge aucune ressource supplémentaire

Pourquoi une page a-t-elle besoin d'un second nom ?
La plateforme stocke un titre par page d'information et l'emploie partout : dans les résultats de recherche, dans l'en-tête, dans le pied de page, dans les menus. Un titre écrit pour se positionner porte des lieux, des services et des précisions, et cette chaîne exacte occupe ensuite trois lignes dans une colonne du pied de page.
Quiconque optimise ses titres rencontre la même bifurcation : raccourcir le titre et abandonner les expressions sur lesquelles il se positionne, ou le garder et vivre avec une navigation cassée. Le module supprime la bifurcation en stockant un second nom réservé à l'affichage.

Qu'est-ce qui reste exactement pareil pour les moteurs ?
Le titre lu par les moteurs de recherche n'est pas touché du tout. Le module modifie les en-têtes visibles et les liens tout en préservant la balise title d'origine ; les positions dans les résultats de recherche ne sont pas garanties.
Cette frontière est structurelle, pas un réglage à réussir : le nom court n'entre que dans l'en-tête visible et les liens, et le titre de recherche est produit chaque fois à partir de l'original intact.

Où le nom court apparaît-il ?
Aux trois endroits que le client regarde vraiment : l'en-tête en haut de la page, les listes de liens du pied de page et les entrées de menu qui mènent à la page. Les trois affichent le même nom court, la navigation reste cohérente.
Les pages laissées vides gardent leur titre natif aux trois endroits. Vous renommez les cinq pages aux titres encombrants et laissez les vingt autres tranquilles.

Et avec plusieurs langues, plusieurs boutiques ?
Chaque nom est enregistré par langue et par boutique. La vitrine française affiche Livraison, l'allemande Versand et l'anglaise Delivery, chaque nom étant rédigé par vous et non traduit par une machine.
Dans un multistore, chaque boutique garde son propre jeu de noms : une marque à deux vitrines nomme la même page différemment dans chacune sans le moindre chevauchement.

Comment le travail est-il organisé ?
Un écran liste toutes les pages d'information de la boutique : le numéro, le titre de recherche en lecture seule et le champ du nom court. Vous voyez l'ensemble d'un coup au lieu d'ouvrir les pages une à une.
La colonne en lecture seule sert de garde-fou : en saisissant le nom court, vous avez sous les yeux le titre qu'il remplace, les noms ne dérivent donc jamais du contenu de la page.

Le module touche-t-il au thème ou ralentit-il quelque chose ?
Aucun fichier de thème n'est modifié et le navigateur du client ne charge rien de nouveau : les noms sont écrits dans la page à l'intérieur de la boutique, avant l'envoi. Ce module ne fait appel à aucun service extérieur.
Le retour en arrière est total. Videz un champ et la page redevient native ; désinstallez le module et chaque page, en-tête et lien retrouve le comportement d'origine.

-
Référencemprcmsnames
-
Version1.2.21
-
Améliorations101
-
Publié
-
Mis à jour
-
Compatibilité PrestaShopPS 1.6 – 9.x
-
Modèle tarifaireAchat unique
-
Type de moduleFront & Back-office
-
Concerne le RGPDNon
-
Objectif commercialAugmenter le trafic
-
Compte externe requisNon
-
Complexité du moduleWidget léger
-
Étape du parcours clientAttirer les visiteurs
-
Compatible avec la plateformeAucune plateforme externe
Soyez la première personne à partager votre expérience avec ce produit.
CMS Display Names vous permet d’attribuer à chaque page CMS un libellé court pour la boutique sans modifier son méta-titre CMS d’origine. Le module aide à garder les menus, les liens de pied de page et les titres CMS lisibles, tout en conservant vos données de titre SEO existantes.
Qu'advient-il de mes noms d'affichage si je désinstalle CMS Display Names ?
La désinstallation supprime la table propre au module mprcmsnames, de sorte que chaque nom d'affichage personnalisé que vous aviez enregistré est effacé. Vos pages CMS PrestaShop natives restent intactes : leurs noms d'origine et leurs meta titres n'ont jamais été modifiés, si bien que le front office revient simplement à afficher les titres CMS standard. Rien dans les tables ps_cms ou ps_cms_lang n'est modifié à aucun moment.
CMS Display Names stocke-t-il ou traite-t-il des données clients ou personnelles ?
Non. La seule table du module (mprcmsnames) stocke quatre colonnes : id_cms, id_lang, id_shop et le texte display_name que vous saisissez, et rien concernant les clients, les commandes ou les visiteurs. Il ne lit ni n'écrit aucune donnée personnelle, il n'a donc aucune incidence sur vos obligations RGPD ni sur votre politique de confidentialité. C'est purement un outil éditorial d'étiquetage pour vos pages CMS.
CMS Display Names change-t-il la balise HTML title dans PrestaShop ?
Non, il ne réécrit pas la balise HTML title. Le module est volontairement limité au contenu CMS visible et au texte de liens CMS rendu, afin que PrestaShop continue d’utiliser le meta title CMS original pour le head de page et les extraits de recherche.
Le commentaire source indique que la balise <title> est construite par le chemin Meta::getMetaTags() de PrestaShop et n’est pas affectée. Le module ne met pas à jour la table CMS native, ne se branche pas dans la génération des meta tags et n’écrit pas de nouveau titre SEO dans PrestaShop.
Ce qu’il peut changer est l’objet CMS passé via filterCmsContent. Si le template de page utilise le meta_title de cet objet CMS filtré comme titre visible, les acheteurs voient le nom d’affichage plus court sur la page. Séparément, actionOutputHTMLBefore peut remplacer le texte des liens CMS correspondants dans le HTML final. Ce sont des changements de contenu visible, pas des changements de balises head.
Pour le travail SEO, continuez à modifier le vrai meta title CMS dans la page CMS native de PrestaShop. Utilisez ce module quand le titre SEO est trop long pour les menus, footers, breadcrumbs ou titres visibles sur page.
Comment raccourcir les noms de pages CMS dans les menus PrestaShop sans changer les titres SEO ?
Utilisez ce module pour définir des noms d’affichage séparés pour les pages CMS PrestaShop. Il stocke un nom d’affichage par id_cms, langue et boutique dans sa propre table mprcmsnames, donc l’enregistrement CMS natif et son meta_title SEO ne sont pas réécrits dans la table CMS.
- Exemple : gardez le meta title de la page CMS comme
Terms and Conditions | My Shoppour le SEO. - Ouvrez l’écran CMS Display Names du module et trouvez cette ligne de page CMS par ID et meta title existant.
- Saisissez un nom d’affichage plus court comme
Termsdans le champ Display Name et enregistrez. - Sur le front-office, le titre visible de la page CMS reçoit le nom d’affichage via
filterCmsContent, et les liens CMS correspondant au motifcms-page-linkde PrestaShop sont remplacés dans le HTML final. - Si vous videz le champ de nom d’affichage, le module supprime sa ligne personnalisée pour cette page CMS et la boutique retombe sur le
meta_titleCMS original.
La séparation pratique est donc : utilisez le titre CMS natif pour les extraits de recherche et le comportement du titre navigateur, et utilisez ce module pour des titres de page, liens footer et libellés de menu plus courts que les acheteurs scannent réellement.
Le module possède deux chemins front-office. D’abord, filterCmsContent modifie l’objet CMS passé au template de page en remplaçant meta_title par le nom d’affichage stocké pour la langue et la boutique courantes. Ensuite, actionOutputHTMLBefore édite le HTML final pour les liens CMS correspondants avant l’envoi de la réponse.
Le commentaire source est explicite : la vraie balise HTML <title> n’est pas affectée, car PrestaShop la construit via Meta::getMetaTags() en utilisant son propre chemin SQL. C’est pourquoi ce module peut raccourcir les noms visibles sans écraser le titre SEO CMS stocké par PrestaShop.
Le markup du thème compte toujours. Le relabeling des liens ne s’exécute que sur les ancres qui correspondent au motif CMS link attendu par le module, avec l’ID de page CMS dans link-cms-page-{id}-... et l’attribut de classe exact cms-page-link dans l’ordre attendu par la regex. Si un thème construit les menus CMS avec un markup différent ou du HTML imbriqué dans le texte d’ancre, le titre peut encore être changé mais le texte du lien peut ne pas être remplacé.
Les noms d’affichage CMS peuvent-ils être différents par boutique et par langue dans PrestaShop ?
Oui, les noms d’affichage sont stockés par page CMS, langue et boutique. La table du module utilise id_cms, id_lang et id_shop comme clé, et enregistrer une valeur vide supprime ce libellé stocké afin que PrestaShop retombe sur le titre CMS natif.
La recherche front-office est aussi spécifique à la langue et à la boutique. Elle charge les lignes de mprcmsnames où id_lang égale la langue du contexte courant et id_shop égale la boutique du contexte courant. Il n’y a pas de fallback large id_shop=0 dans cette recherche, donc un nom d’affichage enregistré pour une boutique n’est pas automatiquement réutilisé par une autre.
À l’enregistrement, le module boucle sur les pages CMS et les langues, remplaçant les lignes lorsqu’une valeur est postée et supprimant les lignes lorsque la valeur soumise est vide. C’est pourquoi vider un champ est une vraie réinitialisation, pas seulement un libellé personnalisé vide.
Détail d’implémentation à vérifier dans cette version source : la table de configuration rendue affiche l’input de langue par défaut pour chaque page CMS. La base de données et la logique de sauvegarde prennent en charge id_lang, mais le formulaire visible dans ce checkout ne rend pas de colonnes d’input séparées pour chaque langue. Si vous avez besoin de noms d’affichage non langue par défaut, confirmez que la build installée expose ces inputs ou ajoutez-les avant de vous fier à l’édition multilingue via le formulaire standard.
Dois-je modifier les templates du thème ou créer des overrides pour utiliser CMS Display Names ?
Non. Le module fonctionne entièrement via deux hooks PrestaShop : filterCmsContent pour les titres des pages CMS et actionOutputHTMLBefore pour le texte des liens affiché dans les pieds de page et les menus. Les deux sont enregistrés à l'installation et aucun override de template .tpl ni aucun override de classe du cœur n'est créé, si bien qu'il reste compatible avec votre thème et survit aux mises à jour du thème. Comme actionOutputHTMLBefore réécrit le HTML final, les libellés de vos liens CMS sont remplacés partout où apparaissent les ancres cms-page-link standard de PrestaShop, sans toucher au moindre fichier de template.
Quels liens CMS PrestaShop peuvent être renommés par ce module ?
Il renomme les liens CMS qui correspondent au markup CMS link attendu par PrestaShop. Le hook de sortie cherche une ancre dont id commence par link-cms-page-{id}- et dont la classe est cms-page-link, puis remplace le texte de lien simple par le nom d’affichage stocké pour la langue et la boutique courantes.
<a id="link-cms-page-3-1" class="cms-page-link" href="/content/3-terms-and-conditions">Terms and conditions</a>Ce motif compte pour les thèmes personnalisés : si le lien CMS a une autre classe, pas d’id link-cms-page-..., si la classe apparaît avant l’id dans le markup ciblé par le module, ou si le libellé est construit avec du HTML imbriqué plutôt qu’un texte simple, le remplacement de sortie peut ne pas matcher.
La regex est volontairement étroite. Elle attend l’attribut id avant class="cms-page-link", et capture du texte simple entre les balises ouvrante et fermante de l’ancre. Un lien avec plusieurs classes comme class="footer-link cms-page-link", un span dans l’ancre, ou un composant de menu entièrement personnalisé peut sortir de ce motif.
Le remplacement ne fait rien non plus dans le back-office et retourne tôt s’il n’y a pas de noms d’affichage pour la langue et la boutique courantes. Si le footer ou menu CMS de votre thème n’est pas renommé, inspectez d’abord le markup d’ancre généré ; souvent, la correction consiste à faire sortir au template le motif natif PrestaShop d’ID et de classe CMS link.
- Addedcomplete FR/DE/ES/IT/PL translations
Fonctionne bien avec Noms de pages CMS personnalisés
Les modules que notre équipe associe réellement à celui-ci, et pourquoi chacun a sa place dans la même configuration.
Avec CMS Display Names, votre boutique conserve des libellés courts et clairs pour les clients dans les menus, les liens de pied de page et les titres CMS, tout en préservant la balise meta title CMS native et descriptive que PrestaShop peut toujours utiliser dans l'en-tête de la page. Cela met de l'ordre dans la façon dont les pages CMS sont présentées sur le site, mais la présentation n'est que la moitié du travail : elle ne fait rien pour contrôler la manière dont ces mêmes pages sont découvertes et explorées par les moteurs de recherche.
Advanced SEO Sitemap Builder est un module distinct qui crée des sitemaps XML et peut aussi fournir un sitemap HTML, offrant aux robots et aux clients un chemin plus clair à travers les produits, catégories, pages CMS, marques, fournisseurs et pages principales, à partir de sources d'URL sélectionnables. Il gère la découverte et garantit que vos pages CMS disposent d'un accès clair vers les sitemaps que lisent les moteurs de recherche.
Utilisés ensemble, ils vous permettent de présenter proprement les pages CMS sur le site tout en veillant à ce que ces mêmes pages soient correctement représentées dans vos sitemaps, deux outils complémentaires couvrant présentation et explorabilité. Le bénéfice est un contenu à la fois lisible pour les clients dans votre navigation et repérable par les moteurs de recherche via votre sitemap, si bien que des libellés soignés et une découverte fiable se renforcent mutuellement au lieu d'être traités isolément.
Avec CMS Display Names, votre boutique sépare les libellés courts destinés aux clients des balises meta title CMS descriptives, gardant les menus et les titres soignés sans affaiblir les titres sur lesquels s'appuie la recherche. Cela règle proprement la présentation des pages CMS, mais vos pages de catégories posent un autre défi : elles ont besoin d'espace pour la profondeur SEO sans repousser les produits vers le bas de la page, ce à quoi les noms d'affichage ne répondent en rien.
Second Category Description est un module distinct qui ajoute un bloc de contenu multilingue supplémentaire sous la grille de produits des pages de catégories, en stockant une seconde description par catégorie, boutique et langue. Il offre à votre boutique de la place pour un contenu SEO plus riche tout en gardant le haut de la catégorie axé sur l'achat.
Utilisés ensemble, ils gardent les deux types de pages nets en haut et solides pour la recherche en dessous : les noms d'affichage rangent vos libellés CMS tandis que la seconde description ajoute de la profondeur sous les listes de catégories, deux outils complémentaires opérant sur des types de pages différents. Le bénéfice est que vous améliorez la formulation SEO sur les pages CMS et de catégories sans encombrer ce que les clients voient en premier, si bien que la lisibilité et la profondeur pour la recherche progressent toutes deux sans que l'une soit sacrifiée à l'autre.
Avec CMS Display Names, votre boutique présente des libellés courts et clairs dans les menus et les titres tout en préservant des balises meta title CMS plus complètes pour la recherche. Des libellés clairs améliorent réellement la lisibilité, mais ils n'affectent que le texte que lisent les clients ; les adresses de page sous-jacentes peuvent rester techniques ou encombrées, sapant l'impression professionnelle que vos libellés soignés sont censés créer.
Smart SEO Friendly URL Manager est un module distinct qui remplace les adresses techniques et encombrées par des liens plus propres et lisibles pour les produits, catégories, pages CMS, fabricants et fournisseurs, à l'aide de modèles d'URL configurables intégrant les données des entités, et réduit la perte de trafic lorsque les adresses changent. Il range la barre d'adresse comme les noms d'affichage rangent vos libellés sur la page.
Utilisés ensemble, ils vous permettent de présenter proprement le contenu CMS à la fois dans le texte que lisent les clients et dans les URL qu'ils partagent, deux outils complémentaires qui alignent libellés et liens. Le bénéfice est une cohérence sur toute la présentation d'une page CMS : elle paraît professionnelle dans le menu, dans le titre et dans l'adresse de la même façon, si bien que le soin apporté aux libellés se retrouve dans les liens que les gens copient, mettent en favori et transmettent.
Avec CMS Display Names, votre boutique conserve des libellés concis pour les pages CMS tout en préservant des titres descriptifs pour la recherche, ce qui convient aux boutiques qui utilisent les pages CMS pour du contenu d'information stable. Mais les pages CMS sont un foyer limité pour un contenu qui grandit et évolue : elles ne sont pas conçues pour un flux régulier d'articles datés et catégorisés, et y forcer du contenu éditorial devient vite ingérable.
Blog Revolution est un module distinct qui offre à votre boutique un espace natif pour les guides d'achat, les annonces et les conseils, gardant articles, catégories, étiquettes, auteurs, commentaires, notes, RSS et pages de blog soignées à l'intérieur de la boutique, avec des statuts brouillon, publié et programmé. Il gère le contenu éditorial continu pour lequel les pages CMS n'ont jamais été conçues.
Utilisés ensemble, ils vous permettent de garder les pages CMS statiques soignées avec des libellés clairs tout en faisant vivre un contenu plus riche et évolutif dans un vrai blog, deux outils complémentaires couvrant des besoins de contenu différents. Le bénéfice est que chaque type de contenu reçoit la structure qui lui convient : vos pages d'information restent nettes et bien libellées, vos articles vivent dans un blog conçu à cet effet, et aucun des deux n'est compromis en étant forcé au mauvais endroit.
Les noms de pages CMS personnalisés ne sont pas visibles dans le menu admin sur PS 9.0
Retour simple - sans questions
Installer, configurer et profiter
Aide et satisfaction avant tout
Vous aimerez aussi
Qui développe et maintient ce module
Développé et maintenu par David Miller et mypresta.rocks. David Miller travaille avec PrestaShop depuis 2013, et l’entreprise derrière cette boutique est immatriculée depuis le 3 décembre 2018. Chaque module de ce catalogue est notre propre travail : vos questions au support arrivent chez les personnes qui ont écrit le code. Le journal des modifications de cette page indique chaque mise à jour avec sa date.