Updated June 2026, the CMS field list and ps_linklist behaviour below reflect PrestaShop 9.x (and apply back through 1.7.5+, where head_seo_title was added).

You write a CMS page in PrestaShop and call it "Terms and Conditions of Sale, Delivery, Returns, and Privacy Policy." For search engines and for the page itself, that long, descriptive title is exactly right. Then you drop the page into your footer link block, and PrestaShop prints that entire sentence as the link label. Your footer now has one tidy column and one column wrapping onto three lines. The fix every merchant reaches for is to shorten the title; the problem is that shortening the title throws away the SEO value you wrote it for. This post is about the actual PrestaShop mechanic behind that conflict, and the native back-office way to give a CMS page a short menu label without touching its title at all.

Why PrestaShop forces the choice, the real mechanic

A PrestaShop CMS page is represented by one CMS object backed by base and language tables, and that object has a small, fixed set of text fields. In 9.x the CMS class (classes/CMS.php) defines a fixed set of language-aware fields: meta_title (required), meta_description, meta_keywords, head_seo_title, link_rewrite (required) and content. Notice what is not there: a separate "menu label" or "navigation name" field. There is no such column.

That single gap is the whole story. In the standard Classic/native ps_linklist flow, the CMS page's meta_title does triple duty. It is the page heading, it seeds the breadcrumb, and it is the text any link to that page displays by default (themes and modules can override any of these). So when the footer renders a link to your page, it reads meta_title and prints it verbatim. There is no second field for it to fall back to. Shorten the title and the menu gets cleaner, but the page heading and breadcrumb get shorter too; lengthen it for SEO and the footer label balloons. You are editing one value that four different surfaces all read from.

You can prove this to yourself. The footer and "Information"-style columns on a stock PrestaShop store are rendered by the ps_linklist module, and its presenter (src/Presenter/LinkBlockPresenter.php) builds each CMS link like this:

What the footer showsWhere ps_linklist gets it
Link label (the clickable text)$cms->meta_title, taken directly, no override
Link tooltip (hover title attribute)$cms->meta_description
Link URL$cms->link_rewrite via getCMSLink()

So the long footer label isn't a theme bug or something you misconfigured. It is PrestaShop behaving exactly as designed: a CMS-type link is hard-wired to display the page's meta title. So what does that mean for you? Any approach that "fixes" the menu by editing the page title is solving the wrong field, and quietly degrading your SEO and breadcrumbs as a side effect.

CMS Display Names back office listing CMS pages with a short display-name field next to each meta title

Set a short display name for each CMS page; it shows in headings, menus and footer links while the meta title stays intact for SEO.

There is a way to get a short menu label out of stock PrestaShop today, and almost no one notices it because it lives one tab over from where they're looking. The ps_linklist module builds a link block from two different kinds of entries:

  • CMS / category / product links, you pick the page from a dropdown. The label is locked to that object's meta title (the behaviour above). Convenient, but no control over the wording.
  • Custom links, you type a label and a URL by hand. Here the label is whatever you write; PrestaShop stores it in the block's custom_content field and prints it as-is.

That second kind is the native escape hatch. Instead of adding your CMS page through the CMS dropdown (which inherits the long title), you add it as a custom link: type the short label you actually want, "Terms," "Shipping," "Returns", and paste the page's front-office URL into the URL field. The page is unchanged. Its meta title stays long and keyword-rich for search engines and the H1; only the footer now reads "Terms."

Where to do it: in the back office, open the Link List/Link Widget module (ps_linklist), commonly reached under Design → Link List or via Modules → Module Manager, depending on your PrestaShop version and back-office menu setup. Open or create the link block for the footer column you want, Information, Products, Your Account, or a new one. Scroll past the CMS-page checkboxes to the Custom content section, add a row, and fill in the Title field (your short label) and the URL field (the page URL), then save. On a multi-language store you set the label per language, so "Returns" / "Retours" / "Zwroty" each render natively. Then untick that page in the CMS-pages list above so it doesn't appear twice.

The trade-off is honest: a custom link is a manual entry, so if you later change the page's link_rewrite (its URL slug), the custom link won't follow automatically the way a CMS-type link would, you'd update the URL once. For the handful of legal and info pages that sit in a footer for years, that's a non-issue. For a store with dozens of CMS pages flowing through several menus, hand-maintaining custom links stops scaling, which is the gap a dedicated tool closes.

Don't confuse this with head_seo_title, they solve different fields

While we're in the CMS object: PrestaShop 1.7.5+ added the head_seo_title field, and it's easy to assume it's the "menu label" you were looking for. It isn't. head_seo_title lets the browser-tab <title> tag differ from the on-page meta_title, so you can have an H1 that reads naturally to a human while the <title> packs the exact-match keyword for the SERP. Useful, but it touches the title/SERP layer, not navigation. To recap the three independent fields and what each one feeds:

CMS fieldControlsEdit it when…
meta_titlePage H1 + breadcrumb + default link labelYou want the human-readable page heading
head_seo_titleThe <title> tag in the SERP / browser tabThe SEO title should differ from the visible H1
Custom link label (ps_linklist)The text shown in a footer / menu columnYou want a short navigation word, title untouched

Three fields, three surfaces. The reason the "long footer link" problem feels unsolvable is that merchants try to fix a navigation symptom by editing the title field, the one field that shouldn't change.

Choosing good navigation labels once you can set them

Having the ability to set a short label is only half the win; the label itself has to earn its place. A few rules that hold up on PrestaShop stores specifically:

  • One or two words, customer's vocabulary. "Returns," not "RMA Policy." "Delivery," not "Logistics." The footer is scanned, not read. Anything that needs a second glance is too long.
  • Match the label to the slug's intent, not its exact words. The label and the URL don't have to be identical, but they should point at the same idea. A "Shipping" label over a /delivery-and-returns URL is fine; a "Shipping" label over /privacy erodes trust.
  • Keep it consistent across every menu the page appears in. If the header says "Contact," the footer custom link should also say "Contact". Not "Get in Touch." Because custom links are hand-typed per block, drift is the easy mistake to make; pick the word once and reuse it.
  • Group instead of listing. Four legal pages don't need four footer lines. One "Legal" or "Policies" block in ps_linklist, with the four pages under it, keeps the footer scannable, and each of those four can still carry a long, distinct meta title for search.

The payoff is what UX people call information scent: a visitor should be able to predict where a link goes before clicking it. Clean, predictable labels mean fewer wrong clicks, fewer back-button bounces, and a footer that looks deliberately built rather than auto-generated.

When the native route stops being enough

The custom-link method is the right answer for a store with a handful of stable info pages. It strains in three situations, all common on larger PrestaShop catalogues:

  • Many CMS pages across several menus. Each custom link is a manual entry per block per language. With twenty CMS pages appearing in a header menu, a footer, and a sidebar, you're maintaining sixty hand-typed labels, and they fall out of sync the moment a URL changes.
  • You want the breadcrumb short too. A custom link only changes the menu text. The breadcrumb on the page still reads meta_title, so a long legal title still produces a long breadcrumb. Stock PrestaShop has no field to separate those.
  • You want the label to live with the page. Custom links live in the link block, not on the CMS page. If you delete and recreate a page, or move it between menus, the label doesn't travel with it.

That's the gap our CMS Display Names module fills: it adds a genuine display-name field to the CMS page itself, so each page carries both its long SEO meta title and a short navigation label in one place. So what does that change? You set the short label once, on the page, and every surface that should be short, menu, footer, breadcrumb, uses it automatically, while the meta title stays long and keyword-rich for search engines. No per-block custom links to maintain, no breadcrumb left behind, and nothing to re-type when a page moves between menus. For one or two footer pages, the native custom-link trick above is perfectly fine; for a catalogue full of CMS pages, having the label travel with the page is what keeps it maintainable.

The wider consistency picture

A navigation label is one piece of a chain that the customer reads as a single signal: the URL, the menu label, the page title, and the H1 should all tell the same story even when the exact words differ. A "Shipping" link, a /shipping-information URL, a "Shipping & Delivery Information" H1, and a SERP title that reads "Shipping Costs & Delivery Times | Store" are different strings pointing at one promise, and that coherence is what tells a first-time visitor they've landed in the right place.

Two related levers sit right next to this one. If a footer column needs more than links, a short blurb, a payment-icon strip, a promo line, that's content rather than navigation, and you place it with custom HTML blocks rather than the CMS title. And because what your menus look like at all is partly a function of the theme, how prominently CMS pages surface in navigation can vary between themes, worth weighing when you choose a PrestaShop theme.

Start with an audit. Open each footer and header menu, and any place a CMS page is linked, and read the labels as a stranger would. If a label takes more than a glance to understand, or wraps onto a second line, it has the wrong text, not the wrong page. Fix it with a short custom-link label where you have a few pages, or with a page-level display name where you have many. Either way, the rule is the same: never shorten a title to fix a menu. The title and the menu label are two different jobs, and PrestaShop only pretends they're one.

Frequently asked questions

Because PrestaShop has no separate "menu label" field for a CMS page. In the native ps_linklist flow a CMS-type link reads meta_title directly and prints it verbatim, the same field that feeds the page H1 and the breadcrumb. There's no second field to fall back to, so a long, SEO-friendly title produces a long footer label. It's designed behaviour, not a bug.

Yes, use a ps_linklist custom link instead of a CMS-type link. In the Link Widget block, scroll to the Custom content section, type the short label you want ("Terms," "Shipping") and paste the page's front-office URL, then untick that page in the CMS list above so it doesn't appear twice. PrestaShop prints your label as-is, and the page's meta title stays long and keyword-rich.

Doesn't head_seo_title already solve this?

No, it's a common mix-up. head_seo_title lets the browser-tab <title> differ from the on-page meta_title, so you can pack the exact-match keyword into the SERP title while the H1 reads naturally. That's the title/SERP layer, not navigation. It does nothing to the footer or menu label, which still read meta_title unless you use a custom link or a display-name field.

It breaks unless you update it. A custom link is a hand-typed URL, so it doesn't follow a link_rewrite change the way a CMS-type link does, you'd edit the URL once. For a few legal and info pages that sit in a footer for years that's a non-issue; for a catalogue full of CMS pages flowing through several menus, hand-maintaining URLs stops scaling, which is where a page-level display-name field is worth it.

No. A custom link only changes the menu text. The breadcrumb on the page itself still reads meta_title, so a long legal title still produces a long breadcrumb. Stock PrestaShop has no field to separate those two surfaces, that's one of the gaps a dedicated display-name module closes by letting the short label feed the breadcrumb too.

Pick the word once and reuse it everywhere the page appears. Because custom links are hand-typed per block, drift is the easy mistake. The header says "Contact" while the footer says "Get in Touch." Keep one or two words in the customer's vocabulary ("Returns," not "RMA Policy"), match the label to the URL's intent, and group related legal pages under one "Legal" block rather than listing four separate footer lines.

When the manual approach stops scaling: many CMS pages across several menus and languages (sixty hand-typed labels for twenty pages in three menus), a need for short breadcrumbs as well as short menu labels, or a wish for the label to travel with the page when it's moved or recreated. A module like CMS Display Names adds the label to the page itself so every short surface uses it automatically while the meta title stays long.

Tags: PrestaShop SEO UX
Share this post:
David Miller

David Miller

Founder, mypresta.rocks

David Miller is a PrestaShop specialist with over a decade of hands-on experience and the founder of mypresta.rocks, a software studio in Tychy, Poland. He builds and maintains a catalogue of 152 PrestaShop modules, including 21 "Revolution" suites spanning SEO, checkout, security, performance, marketing, search, support, and warehouse operations, that improve real stores every day, all tested against PrestaShop 1.7.8, 8.x, and 9.x. He also acts as caretaker for production stores turning over millions in annual sales, so his work is judged on live revenue, not demos. His experience runs the full breadth of ecommerce, performance, security, SEO, and marketing, and reaches beyond PrestaShop to WooCommerce, Shopify, and custom-built systems. On the blog he writes about the code-aware side of PrestaShop: what the platform really does under the hood, what breaks in production, and which fixes hold up.

Comments

No comments yet. Be the first!
Enjoyed this article?

Get our latest tips, guides and module updates delivered to your inbox.

You may unsubscribe at any moment. For that purpose, please find our contact info in the legal notice.

Loading...
Back to top