Product Tabs: Adding Specifications, Guides and Custom Content to Product Pages

Updated June 2026 — the displayProductExtraContent tab hook and Features behaviour described here apply to PrestaShop 1.7, 8 and 9.

A product page has to satisfy two people who never overlap: the buyer who has already decided and just wants the Add to cart button, and the researcher who won't commit until they've checked the dimensions, the compatibility, the size chart, and the warranty terms. Cram everything the researcher needs into the visible description and you bury the buyer in a wall of text. Cut it to keep the page clean and the researcher leaves to find the answer elsewhere. Tabs are how PrestaShop resolves that tension — they let the page carry deep reference content (specifications, guides, downloads, FAQ) without forcing it onto everyone who lands there. This guide is specifically about getting that content into the tabs on a PrestaShop store: what the platform builds for you, what it won't, and the cleanest way to add custom tabbed sections per product, per category, or store-wide.

If you're earlier in the process — deciding what belongs on the page at all and in what order — start with product page anatomy and the wider product page design best practices. This post picks up after that decision, at the mechanics of the tab strip itself.

What PrestaShop's default tabs actually give you

On a stock PrestaShop 1.7, 8 or 9 store, the tab strip is rendered by the theme's product templates — chiefly themes/your-theme/templates/catalog/product.tpl and the related catalog partials it includes — and the default tabs are populated from fixed sources:

• Description — the long description field from the product editor's Description tab. The short description (summary) usually renders above the price, not in a tab.
• Product details — pulls from the structured data on the product: the Features you attach on the product's Details tab plus the product's Reference/EAN/UPC. This is the tab most merchants underestimate.
• Download — a separate tab that appears only when you've uploaded attachments (manuals, data sheets) to the product. In the classic theme this is its own tab, not folded into Product details.
• Reviews — only appears if a reviews module is installed and hooked into the product page. On 1.7/8/9 the official Product Comments module renders through the displayProductExtraContent hook (the legacy displayProductTab/displayProductTabContent hooks it used in 1.6 were removed in 1.7).

So what? Most of the default tabs are not free-text. The Product details tab is assembled from structured data, which is exactly why it's worth more than it looks — and why "just type it into the description" is the wrong instinct for anything measurable.

Features are the tab most stores ignore — and the one that pays twice

For anything with measurable attributes (electronics, tools, furniture, anything with a spec sheet), the right home is Catalog → Attributes & Features → Features, not a paragraph in the description. You create a feature once (e.g. "Weight", "Material", "Power output"), give it pre-defined values, then attach values to each product on its Details tab.

This pays off in two places at once, which is what makes it the highest-leverage tab decision you'll make:

• The spec tab renders itself. Features display automatically in the Product Details tab as a clean name/value list — no HTML to hand-format, no table to maintain per product. Change a value once and every surface updates.
• They power faceted filtering. The same features feed the layered navigation (ps_facetedsearch) on category pages, so "Material: leather" or "Power: 2000W" becomes a filter customers can click. Free-text description content can never do this.

The discipline here is the same one that keeps descriptions clean: structured data goes in features, prose goes in the description. If you're writing the prose half, how to write product descriptions that rank and convert covers it, and the spec table itself is part of the buy-or-back decision laid out in product page anatomy.

The four kinds of tab content — and where each one belongs

Not every piece of reference content wants the same home. Matching the content type to the right mechanism is what keeps a product catalogue maintainable at 50 products and at 5,000.

The mistake we see most often is using a per-product custom field for content that's identical across a whole category — a single shoe-sizing chart copy-pasted onto 300 products. When the chart changes, that's 300 edits and a near-certain inconsistency. Category-wide tab content solves it: the same block renders on every product in the category, edited in one place. That category-wide, write-once mechanism is exactly what a tab module like Product Extra Info Tabs adds on top of core.

Adding genuinely custom tabs: the clean approaches

Once you go beyond features and attachments, you need a tab that holds arbitrary content. There are three ways to do it on PrestaShop, in ascending order of how much it costs you later.

The reason the module route exists is the third row: editing product.tpl in a child theme works until the next theme update reshuffles those partials, and then your tabs vanish on a Tuesday with no warning. A module that registers its content through the displayProductExtraContent hook (the modern 1.7/8/9 tab hook) adds tabs without touching a single theme file, so it survives theme and core upgrades — which is the whole point of doing it the PrestaShop way instead of the quick way.

How a tab module hooks in

If you ever look under the hood, modern PrestaShop (1.7, 8 and 9) builds custom tabs through a single hook: displayProductExtraContent. A module hooks into it and returns one or more ProductExtraContent objects — each carries a title (the clickable tab label) and content (the panel body), set via setTitle() and setContent() — and PrestaShop's ProductExtraContentFinder collects them and renders them as Bootstrap tabs. The skeleton of such a hook looks like this:

public function hookDisplayProductExtraContent($params)
{
    $tab = (new PrestaShop\PrestaShop\Core\Product\ProductExtraContent())
        ->setTitle($this->l('Care & Sizing'))
        ->setContent($this->fetch('module:mymodule/views/templates/hook/tab.tpl'));

    return [$tab];
}

(This replaced the old two-hook 1.6 model of displayProductTab for the label and displayProductTabContent for the body, both removed in 1.7.) A module that's built right lets you define multiple tabs, target them by product or category, and (importantly) outputs the content into the page's initial HTML rather than fetching it by AJAX on click. That last detail is not cosmetic — it's the difference between content Google indexes and content it never sees, which is the next section.

Will Google read what's inside a hidden tab?

This is the question that actually matters for the SEO half of the decision, and the honest answer has two halves:

• Content hidden with CSS (display:none) is generally indexed. When the full tab content sits in the page's initial HTML and a tab is merely visually collapsed, Google can read it. So your specifications, FAQ answers and guide text contribute to the page's keyword relevance even though a visitor only sees one tab at a time. That's the upside: you carry depth without a cluttered visible page.
• Content loaded by AJAX on click may not be. If a tab fetches its body only when the customer clicks it, that text isn't in the HTML the crawler first receives, and you can't rely on it being indexed.

So what? Prefer tabs whose content is server-rendered into the initial HTML. It's a single technical choice with an outsized payoff: the same words work for the researcher and for search. Whether hidden tab content ranks as strongly as visible content is genuinely debated and Google's own guidance has shifted over the years — so for the content you most want to rank on, the safest play is to keep your strongest copy in the always-visible description and treat tab content as supporting depth, not your only home for important keywords. For the product copy that does the ranking heavy lifting, see how to write product descriptions that rank and convert.

[SCREENSHOT: front-office product page with the tab strip open on a custom "Care & Sizing" tab, plus the page source view showing that tab's text present in the initial HTML — make the point that the content is server-rendered, not AJAX-loaded.]

Designing the tab strip so it gets used

A tab nobody opens is dead weight. A few decisions separate a strip that helps from one that overwhelms:

• Keep it to 3–5 tabs. Past seven, the strip reads as clutter and the labels start wrapping. Merge naturally related content — "Shipping & Returns" as one tab beats two thin ones.
• Order by demand, not by your org chart. Description first, specifications second (it's the most-opened tab after the main copy on technical products), and low-traffic tabs like Downloads or Warranty at the end.
• Hide empty tabs. A product with no attachments should not show an empty Downloads tab — empty tabs read as a half-finished store. Good tab modules suppress a tab automatically when its content is blank; if you're overriding templates by hand, you have to code that check yourself (another reason the module route ages better).
• Format inside the tab. Tables for specs, bullets for features, short blocks for FAQ. A dense paragraph in a tab goes unread by exactly the researcher you opened the tab for.

On mobile, consider turning tabs into an accordion

Stock PrestaShop doesn't guarantee a mobile accordion for the product tabs — depending on the theme's CSS, the Bootstrap tabs may simply wrap or stay as a horizontal strip — so check how your own theme actually behaves on a phone first. Where it doesn't already do so, it's worth implementing the tab strip as a stacked accordion below a breakpoint, tapping a heading to expand its section. That's generally the right behaviour and worth designing for deliberately:

• Accordion beats horizontal scroll. A row of tabs that needs sideways swiping on a phone hides labels off-screen; an accordion shows every section title at once and expands only what's tapped.
• Never nest tabs inside tabs. The cognitive load of two-level navigation on a 6-inch screen is too high — flatten it.
• Test the collapsed order. An accordion typically reuses the same source order, so the tab you decided was "first" is the one a phone customer expands first — verify it on your theme. Order once, and it should be right on both layouts.

Tabs that aren't really specs: reviews, Q&A and video

Several things that often live in the tab strip aren't reference content at all — they're separate features that happen to render through the same hooks, and each has its own home in this cluster:

• The Reviews tab is driven by a reviews module, not by anything in the product editor. Which one to use is its own decision — PrestaShop reviews: built-in vs third-party.
• A product Q&A / "ask about this product" tab turns pre-purchase questions into answered objections; that's covered in ask about product, and the broader FAQ play in FAQ pages for e-commerce.
• A product video often sits in its own tab or panel — see YouTube integration for PrestaShop.

Keeping these as their own features (rather than pasting their content into a generic custom tab) is what lets each one do its job — a review tab needs star aggregation and structured data, not a text box.

Measure which tabs earn their place

You don't have to guess which tabs matter. Tag each tab's heading with a click event in your analytics and let a month of real traffic tell you:

• What customers actually look for — the most-opened tab is the content to promote toward the top of the page, maybe even out of a tab and into the visible body.
• Which tabs are dead — a tab that's almost never opened across thousands of views is a candidate to merge or remove, trimming the strip back toward that 3–5 sweet spot.
• Whether tab depth correlates with buying — if customers who open the specifications tab convert noticeably better, that's a signal to surface specs more prominently rather than hiding them one click away.

Frequently asked questions

What's the difference between Features and a custom tab — when do I use which?

Features are structured name/value pairs (Weight: 2.4 kg) that render automatically in the Product Details tab and feed faceted search. A custom tab holds free-form content — a care guide, an FAQ, compatibility notes — that doesn't fit a name/value list and isn't something a customer would ever filter by. Rule of thumb: if it's a measurable spec a shopper might filter on, it's a Feature; if it's prose or a guide, it's a custom tab.

Can I show the same tab on every product in a category without editing each one?

Not with core alone — core gives you per-product Features and Attachments, but no native "category-wide tab." A tab module that targets content by category does this: you write the size chart once and it renders on every product in that category, so a change is one edit, not 300. That's the main reason stores reach for a tabs module instead of pasting shared content per product.

Does hidden tab content count for SEO, or is it wasted?

If the content is server-rendered into the page's initial HTML and merely collapsed with CSS, Google generally reads it — so it contributes to relevance even though a visitor sees one tab at a time. The trap is AJAX tabs that fetch their body only on click; that text isn't in the first response and can't be relied on to index. Keep your most important keywords in the always-visible description and use tabs for supporting depth.

Will custom tabs survive a theme or PrestaShop update?

If they're added through the displayProductExtraContent hook (a module), yes — they touch no theme files, so a theme update can't break them. If you added them by editing product.tpl or tabs.tpl directly, no — the next theme update can reshuffle those partials and your tabs disappear silently. That upgrade-safety is the whole argument for the hook route over template surgery.

How many tabs is too many?

Keep it to 3–5. Past about seven the strip wraps, labels get cut off, and customers stop scanning it. Merge thin tabs (one "Shipping & Returns" beats two), order by demand rather than your internal logic, and auto-hide any tab whose content is empty so the strip never looks half-finished.

The principle underneath all of it is the same one the whole product page runs on: serve the quick buyer and the deep researcher on one page without making either feel the other's content. Tabs are PrestaShop's tool for exactly that — put structured data in features, shared content in category-wide tabs, per-product detail in clean custom tabs, keep the strongest copy server-rendered and visible, and let the click data tell you what to promote next. Get that right and the page stays uncluttered for the person who's ready to buy while still answering everyone who isn't yet.