PrestaShop navigation, category structure and listings

What we would do

We would follow a customer's route to a real product before changing the tree or buying a menu. The right route depends on your existing shop: its theme, menu and search modules, catalogue data, ERP or import integrations, shop associations, markets, languages and the team maintaining it. Keep a working native menu when it exposes the ranges clearly; fix the point where a shopper loses the route.

For a restructure or replacement, use a staging copy with the same theme, modules and representative data, isolated from customer emails and live integration writes. Rehearse category edits, old URLs and complete shopping journeys, then make the agreed change in a planned window. Save the previous menu configuration and a tested way to reverse category and route changes; disabling a menu module alone cannot undo a catalogue restructure.

If you want an independent review before changing navigation, the PrestaShop UX & Conversion Design Audit provides a prioritised repair plan for the purchase journey; implementation is separate.

Design the category tree around shopping tasks

Start in Catalog > Categories. A category has a parent, position, language values and shop associations. The usual structure has Root above Home, with your public departments beneath the relevant shop's Home category. Use the back office to move categories; do not edit the nested-set nleft and nright values directly.

Name groups with words customers use. “Walk-In Showers” describes a range more clearly than “Shower Solutions” or “SKU Group 4B”. Use search logs, customer questions and actual inventory to decide which distinctions matter.

A bathroom example is Showers > Walk-In Showers > Frameless Panels, alongside Bathtubs, Basins, Toilets and Accessories. Three category levels are an editorial starting point, not an SEO requirement. Homepage > Showers > Walk-In Showers > Frameless Panels > Product takes four clicks. A menu shortcut can reduce that path without changing the tree.

Measure real link depth and product reachability. Merge overlapping groups when customers struggle to distinguish them. Split a broad range when it contains useful, distinct shopping tasks. Judge each category by its purpose, product range and helpful content.

Use categories for durable groups such as Walk-In Showers. Use filters for properties such as 8 mm glass, 900 mm width, material or price. A useful filtered selection can become a curated landing page when it serves a distinct purpose and you can maintain its content and stock. Avoid duplicating the entire filter space as categories.

Work through a bathroom catalogue change

Suppose an import has created separate shower-panel categories for width and glass thickness. Keep Frameless Panels as the durable range, populate width and thickness consistently as filterable data, and let customers combine them. Preserve a size-specific landing page only where it answers a distinct shopping task and has a maintained selection and useful content. Before merging the old categories, map their URLs to the closest relevant destination and agree the category mapping with whoever owns the import, so its next run does not recreate them.

Check what the native menu already does

The native ps_mainmenu module exposes configured links and category branches. Its supported items include categories, CMS content and custom links, with other entity choices depending on the installed version. Theme templates determine the visible dropdown behaviour.

Native Main menu is not text-only. Its official template renders category image URLs. Richer configurable panels with product cards, banners and custom blocks are a separate capability.

1. Identify the active theme and installed menu module.
2. Open the menu module's configuration to inspect selected entries and their order.
3. Check Design > Positions for the navigation hook the theme actually renders, commonly displayTop.
4. Test the deepest category branch on desktop, touch and keyboard before deciding it needs replacement.

Classic describes many older and upgraded stores. Hummingbird became the default for fresh PrestaShop 9.1 installations. An upgrade does not automatically replace your existing theme. Check compatibility with your exact theme rather than assuming every current store uses one template structure.

Build a useful mega menu and keep it current

A mega menu can expose related branches in a wide panel. It can help when narrow cascading fly-outs close during pointer movement, overflow the viewport or hide useful neighbouring categories. A small catalogue may already work well with the native menu.

Keep clear department labels in the top bar. Group children under descriptive column headings. Five to nine top-level entries and three visible levels are possible design starting points, not universal limits. Test translated labels, text zoom and available width.

• Make category links the main content.
• Use a small number of category images where recognition helps.
• Reserve space for a relevant featured product, seasonal offer or New Arrivals link.
• Use only accurate delivery, return and payment reassurance.
• Keep longer-tail branches reachable from category pages instead of putting the entire sitemap in every panel.

Order items using customer tasks and measured navigation patterns. A frequently used category may deserve a direct route. A rarely clicked link may be unclear, hidden or irrelevant; click count alone cannot tell you which.

A tree-driven column is not a promise that every new category becomes a new top-level tab on the next request. Normal back-office category changes can trigger supported invalidation hooks; raw database imports or external caches may need an explicit rebuild. Test renaming, reordering, hiding, moving and deleting categories in the intended shop and language.

Assign an owner to review seasonal blocks and expired offers. If a renamed category stays old in the menu, compare its entry type, configured root and cache before rebuilding the tree. In multistore, test the intended shop, language and customer group separately; a correct public menu does not prove that restricted ranges stay out of another audience's view.

Mega Menu provides configured tabs, category-tree columns, merchandising blocks and mobile drill-down navigation. Test compatibility with your exact PrestaShop release and theme.

Make navigation accessible and keep it light

Use a stable desktop panel with clear opening and closing behaviour. A short open/close delay can reduce accidental pointer activation, but tune it with users. Keep focus visible, support keyboard activation and closing, and return focus sensibly after dismissing an overlay.

On touch screens, use tap controls, an accordion or drill-down view. Keep a direct parent-category link such as “View all Showers” alongside the expand action. Provide a clear back control in a sliding child view.

Give controls generous touch targets and spacing. Check long labels, landscape view, zoom, background scrolling and whether a fixed panel traps or hides content. Keep search available for known-item tasks, and hand attribute narrowing to category filters.

A menu adds HTML, CSS, scripts, images and possibly fragment requests to every page. Caching reduces recomputation; it does not make the menu weightless. Inspect transfer size, DOM size and main-thread work. Delay offscreen panel images where appropriate while preserving discoverable category links.

On a real phone, open the menu, expand Showers and then Walk-In Showers, and follow its "View all" link to the Walk-In Showers listing. Use the browser Back control, reopen the menu if needed and select Frameless Panels. A parent that only expands, a back control that closes the whole menu or a link hidden beneath a sticky header gives you a specific defect to retest. Check keyboard focus after each open and close as well as the final destination.

An overlay can avoid pushing the page down. Not every menu-induced layout shift counts toward CLS: qualifying recent user input can affect the measurement, while hover behaves differently. Test the actual interaction rather than declaring every opening a Core Web Vitals failure.

Manage category URLs, canonical redirects and breadcrumbs

Review Friendly URLs and the active route configuration under Shop Parameters > Traffic & SEO. The ID-and-rewrite example below assumes Friendly URLs are enabled; otherwise category links use query parameters. If you enable Friendly URLs on an existing shop, test previously published addresses before switching. With the default category route in PrestaShop 1.7.8 and 9.1, a category URL uses its ID and rewrite, for example /12-frameless-panels. Reparenting does not automatically produce /showers/walk-in-showers/frameless-panels. A hierarchy in the URL requires an appropriate custom route or URL implementation.

1. Record current URLs and important external/internal links before a restructure.
2. Check the Friendly URL field when renaming a category. Keep stable slugs where possible.
3. Test old URLs with their actual HTTP responses. ID-based routes can still resolve the category and redirect to the current canonical URL.
4. Review canonical redirection settings. The core supports configured 301 or 302 behaviour; do not assume every rename returns 404.
5. Add suitable redirects for removed IDs, merged pages or custom route changes that the native behaviour does not cover.
6. Update menu links, sitemaps and language variants, then check for chains and loops.

Use readable, consistent rewrites. Hyphenated lowercase wording is easy to maintain. Localise it deliberately rather than changing established URLs merely to remove a stop word or diacritic.

A product can belong to several categories and has a default category. Choose a relevant default and inspect its breadcrumb and canonical URL. Older default product routes can include a category segment. PrestaShop 9's new default product route omits it, but existing PS_ROUTE_* overrides or URL modules can retain different behaviour.

Breadcrumbs help customers move upward and explain relationships. Validate the rendered BreadcrumbList markup in your theme. Search appearance is conditional; Google removed visible breadcrumbs from mobile results in January 2025 while retaining desktop support. See Google's announcement.

Separate the category label, H1 and search metadata

“Knives” may fit the menu, while “Professional Kitchen Knives for Home Cooks and Chefs” better explains the page. Use a custom heading when the short category name does not explain the actual range clearly. Search engines can generate title links from several sources.

Check whether your theme already supplies a separate heading field. In Classic, catalog/listing/category.tpl includes catalog/_partials/category-header.tpl inside product_list_header. That partial renders the H1 from category.name.

For a small custom change, maintain the actual header partial or its supported block in a child theme. Preserve its other content. This illustrates the heading expression inside that partial, not a complete replacement file:

{if $category.id == 12}
  <h1>Professional Kitchen Knives for Home Cooks and Chefs</h1>
{else}
  <h1>{$category.name|escape:'htmlall':'UTF-8'}</h1>
{/if}

A hardcoded category ID needs developer maintenance and language handling. A field-based solution can keep headings editable and localised. Custom Category H1 provides server-side category heading overrides. Enter a heading in the category form for one category, or assign a reusable pattern across a branch; patterns can include the category name, product count or page number.

For a multilingual range, keep the short translated navigation name and write the heading for that language's actual selection. Preview both an explicit heading and a cleared field: a shared rule may still apply after clearing it. Confirm the rendered heading, breadcrumb and canonical URL together, so a heading-only change does not accidentally rename the category or alter its address.

Write clear, distinct headings for sibling ranges. Avoid keyword lists and unsupported product claims. Test wrapping on phones. If a heading uses a generic product count, say “42 products”, not “42 products in stock” unless that count is explicitly filtered by stock. Empty-only and inherited heading rules need a tested fallback to the category name.

Tune product cards, sorting and pagination

The category controller uses the listing system, and the theme supplies category and product-list templates. Classic product cards commonly come from catalog/_partials/miniatures/product.tpl. Inspect your installed theme before changing paths or selectors.

Classic's modern layout is a grid; a true list view requires theme or module support. Choose layout by the information customers compare. Photographs may suit a grid for fashion and décor; specifications may need more room for components and B2B parts. Column count comes from theme layout/CSS, not a universal back-office dropdown.

• Use consistent image proportions without hiding important product detail.
• Keep product names readable and linked.
• Show accurate price, tax context and applicable reductions.
• Show ratings and reviews only when you can substantiate them.
• Make quick view and add-to-cart behaviour handle required combinations.
• Base availability labels on fulfilment data. Avoid decorative scarcity.

Shop Parameters > Product Settings provides the native default ordering, order direction and products-per-page setting: Default order by, Default order method and Products per page (PS_PRODUCTS_PER_PAGE). Front-office sorting commonly uses ?order=product.price.asc and pagination uses ?page=2. A search provider can change the options and the result order, especially after filters.

To curate product positions, open the Products listing, filter to the category and enable Position ordering/reordering as supported by your version. Dragging rows in the Categories listing orders categories, not products. Confirm the storefront uses position sorting.

Position, price ascending/descending, newest and sales-based ordering can serve different tasks. Offer the choices your provider supports and customers use. Treat a four-to-six-choice dropdown, three-to-four desktop columns, two mobile columns, or 24 versus 48 products per page as test candidates rather than fixed best practices.

If New Arrivals should open newest first while Accessories needs a different page size, the global settings alone do not express both choices. Category Listing Rules supplies category-specific sorting and page-size rules, with inheritance and shop/customer-group conditions. Test an exact rule against an inherited one and confirm that a shopper's later sorting choice stays in force, including with your active search provider.

For specification-led ranges, show the deciding details on the card rather than forcing customers to open every product. Change the card only after checking the underlying data: a missing dimension, an incorrectly cropped image or a quick-view combination that cannot be bought is a reproducible problem. Compare the same products before and after the change, including an unavailable item and one with required options.

Numbered pagination gives linkable routes to deeper inventory. Load more and infinite scroll need equivalent crawlable page links, reliable back-navigation and position restoration. Keep the footer reachable and check actual indexability rather than assuming every pagination URL is indexed.

On phones, test a usable filter/sort control, removable active filters and readable product cards. A drawer can save space, but choose the layout from the actual range and screen. Useful measurements include category-to-product visits, add-to-cart, purchases, loading cost and failed interactions.

Write useful descriptions and control filtered URLs

Give an indexable category a useful explanation of its range, selection criteria and relevant differences. Put a concise introduction near the grid. Use longer buying advice and relevant sibling links below it when they help customers. Unique meta titles and descriptions should accurately describe each page.

PrestaShop 8.0 introduced the additional category description field. Verify that your theme renders it, usually below the product list. Older shops or different layouts may need a supported extension such as Second Category Description.

Check an empty category and later listing pages as well as the opening page; repeated boilerplate or a large block above every grid can obstruct the decision it should support.

Start with ps_facetedsearch if its available controls meet your need. Assign filters by range and check the source attributes/features first: missing or inconsistent values produce misleading shortlists. If you need curated filter landing pages and different controls, Filter Revolution provides configurable filter groups and selected landing pages with their own text and readable addresses. Test the resulting URLs and directives on your installation rather than treating the module choice as proof of indexability; the product search and faceted navigation guide covers that layer.

Filtered URLs can generate large crawl spaces. Decide which selections deserve maintained landing pages and which should remain utility views. Inspect the actual filter parameters, robots directives and canonical links emitted by your version and search module.

Robots.txt controls crawling, noindex requests index exclusion, and canonical links suggest consolidation. They are not interchangeable. Blocking a URL can prevent Google from seeing its noindex or canonical directive, and a blocked URL can remain indexed.

If you decide not to crawl native q filter permutations, these are example rules to assess against your own URLs:

User-agent: *
Disallow: /*?q=
Disallow: /*&q=

Do not block clean categories or ordinary pagination inadvertently. For already indexed filter URLs, plan removal or consolidation while the needed directives are still crawlable before applying a block. Follow Google's faceted-navigation guidance.

For an independent review of crawl and indexation problems, the PrestaShop SEO Audit & Action Plan provides a ranked plan of fixes; implementation is separate.

Keep key category links as meaningful <a href> elements. Test the rendered HTML, mobile behaviour and crawl paths after menu changes. Compare equivalent traffic and shopping tasks. More pages per session or less search usage is not automatically better: successful discovery may use fewer pages or rely on useful search.

Rehearse the change and hand it over

1. Record the current category IDs, parents, shop associations, product memberships/default categories, Friendly URLs and menu configuration. Keep examples of important landing pages and the journey that currently fails.
2. Apply the smallest proposed change on staging. Agree how catalogue imports and integrations will preserve it, and keep unrelated theme or search changes out of the comparison.
3. Run the same tasks from the homepage and directly into a category: browse, narrow, sort, open a product and return. Confirm active filters, selected sorting and listing position survive as intended.
4. Check old URLs, redirects, canonical links, breadcrumbs and crawlable pagination. Include a moved category, a merged destination and a product listed in several categories, in the relevant shops and languages.
5. Test the configured cache invalidation after a category edit and an import. Check warm and cold views so a cached old menu does not mask a failed update.
6. Record acceptance results, the person responsible for the switch and the exact rollback steps. Apply the rehearsed changes during the agreed window, check live destinations and watch discovery failures, purchases and support reports.

For measurement, keep navigation-driven category visits separate from direct search landings and compare equivalent devices, markets and shopping tasks. Repeated wrong-category visits followed by backtracking can expose a label problem. Change one decision at a time where possible, and judge the result against the original failure rather than a promised uplift or fixed observation period.

What to ask your developer or agency

• Which part of the current journey fails, and can you show it on our theme and module versions?
• Which category IDs, default categories, routes or integration mappings will change, and where is the old-to-new URL map?
• What already works natively, and who will maintain any new menu entries, translations, heading rules or category-specific settings?
• Where are the phone, keyboard, filtering, sorting and return-navigation test results, and how will we reverse the change without overwriting new orders?

Questions owners ask

Can I simplify the menu without moving categories?

Yes. Expose selected branches or shortcuts in the menu while keeping the underlying catalogue where it is. First check whether the menu can present the desired route; changing product associations and integration mappings may be unnecessary.

What if a category has only a small specialist range?

Keep it when customers need that distinct range and the page explains it usefully. Product count alone does not justify merging it. Check the selection, current demand and whether another destination would serve the same task before removing the page.

Why did products move when I changed a filter?

The active search provider can supply its own result order. Compare the selected sort and request before and after filtering, then check that provider's supported behaviour; changing category positions repeatedly will not fix a provider that does not use them.

Do I need a different H1 for every category?

Only where the short category name leaves the range unclear. Check the actual range, page heading and template first. For rule-based headings, test an untranslated or unmatched category and the fallback as well as the categories you customised.

Can I restore the staging database if the live switch fails?

A wholesale restore can overwrite orders and catalogue changes made since the copy. Agree a targeted reversal of the navigation, route and category edits, with a developer-managed recovery plan for any wider restore.