Filter Revolution: helping customers find products in large catalogs

A store with 50 products doesn't need filters. A store with 5,000 is unusable without them. Somewhere between those two numbers (usually around the point where a category page runs past three or four pages of pagination), browsing stops being "scroll until you spot it" and becomes "narrow it down or give up." That narrowing is what faceted filtering does: it lets a customer who knows what they want ("black leather boots, size 42, under €120") express it by clicking, not typing. This guide is specifically about getting that working well in PrestaShop, which module the platform actually ships, where its settings live, why large catalogs make it slow, and the decisions that separate filters that convert from filters that frustrate.

It is not about search (the typed-query box is a different problem, see when PrestaShop's default search isn't good enough), and it's not about the broader anatomy of a category page; for layout, sorting and above-the-fold structure see category pages that convert. Here we stay on the filters themselves.

Last reviewed June 2026, verified against ps_facetedsearch on PrestaShop 1.7, 8 and 9.

What PrestaShop actually ships: ps_facetedsearch

PrestaShop doesn't make you buy faceted navigation, it bundles it. The module is ps_facetedsearch ("Faceted search" in the back office), and on a default 1.7, 8 or 9 install it's already there, usually just not configured for your catalog yet. You'll find it under Modules → Module Manager (search "faceted", then Configure), and everything is driven from that one configuration screen. Its filter templates are tied to categories, but you manage them from the module, not from a Catalog menu entry. That single detail (that the filtering engine is a module hooked into category pages, not a core setting buried in Preferences) is the thing most merchants miss. There's no global "turn on filters" checkbox; you build filter templates and attach them to categories.

[screenshot: the ps_facetedsearch configuration screen with its filter-template list and the category-association controls]

So what does that mean for you? You're not stuck. Out of the box, on the version you're already running, you have a faceted-filter system that handles price, brand (manufacturer), categories, product attributes and product features. The work isn't installing something. It's configuring it for the way your catalog is structured.

Filter templates: the setting that actually controls everything

Open ps_facetedsearch and the central concept is the filter template. A template is a named set of filters ("Footwear filters", "Electronics filters") plus the rule for which categories it applies to. For each filter in the template you choose:

• Which facet, price, weight, condition (new/used/refurbished), availability (in stock), manufacturer, category, or any product attribute (size, colour) or feature (screen size, material).
• Display style, checkboxes, radio buttons, a dropdown, a price/weight slider, or colour swatches for attributes you've set as the "colour" type.
• Limit & order, how many values to show before "show more", and whether to sort them by name or by result count.

The non-obvious lever is the global toggle "Show products from subcategories" and the per-filter "Show the number of matching products" count. Turn the count on, "Black (24)" tells a customer the path isn't a dead end before they click it, and that single number heads off the frustration of zero-result filter combinations.

Attributes vs features: the distinction that decides your filters

This is where PrestaShop catalogs go wrong, so it's worth being precise. PrestaShop has two different systems for "extra properties on a product," and which one you use determines whether a property can become a useful filter, and whether it's even filterable the way you expect.

The practical rule: model anything a customer buys a specific version of (size, colour) as an attribute; model anything that's just a fact about the product (material, dietary flag, origin) as a feature. Get this backwards, features that should have been attributes, and you end up unable to track stock per size, no module can fix that retroactively without a data rebuild. Both are filterable, but only attributes carry stock and price.

Category-specific filters (do this, don't show every facet everywhere)

Generic facets, price, brand, availability, belong on nearly every category. The high-value ones are category-specific, and showing the wrong facets is itself a conversion leak: a customer in "Laptops" doesn't want a "Shoe size" filter cluttering the sidebar. Because templates attach to categories, you can give each branch its own relevant set:

• Electronics: screen size, storage capacity, connectivity, operating system (all features).
• Clothing & footwear: size and colour (attributes), plus material and season (features).
• Furniture: material, room type, assembly required (features), dimensions.
• Food: dietary flags (vegan, gluten-free, organic), origin, allergens (features).

Set the relevant features per product first, then build one filter template per major catalog branch and attach it. A laptop category and a footwear category should not share a template.

Filter UX: the small decisions that decide whether anyone uses them

Having the facets is necessary; presenting them well is what makes customers narrow instead of leave.

• Sidebar on desktop, drawer on mobile. ps_facetedsearch renders into the left column (the displayLeftColumn hook) by default, where shoppers expect filters. On a phone that left column collapses; a clean theme turns it into a "Filter" button that opens a full-height panel. A large share of catalog browsing now happens on a phone, so the mobile drawer isn't an afterthought (see mobile commerce).
• Show per-value match counts. Per-value counts like "Black (24)" tell the customer whether a path is a dead end before they click. That's the ps_facetedsearch option to turn on. The list-level total ("Showing 12 of 487") is your category listing/theme behaviour rather than a module toggle, but together they tell the customer whether to broaden or narrow.
• Active-filter chips. A visible row of applied filters with click-to-remove ("Colour: Black × Size: 42 ×") lets customers adjust without starting over. The default template renders these above the grid; keep them there.
• Multi-select logic. ps_facetedsearch already does the natural thing: multiple values within one facet are OR (size 41 OR 42. Useful for between-sizes shoe buyers), while different facets are AND (size 42 AND black). You don't configure this; just know it's the behaviour, and don't fight it.
• Colour as swatches. Set your colour attribute's type to "Colour or texture" in the attribute screen so the filter shows swatches, not a list of words. Visual products filter visually.

The filter sidebar is one piece of a category page that has to work as a whole. For how it sits alongside sorting, the product grid and the H2/H3 structure, see category pages that convert, and for why the heading above that grid shouldn't just echo the category name, custom category H1.

Performance: where large-catalog filtering actually hurts

This is the part nobody warns merchants about until the site is slow. Faceted filtering on a big catalog is database-heavy, and ps_facetedsearch's answer is an index. Inside the module's configuration screen there's an "Indexes and caches" section with buttons to rebuild the price index, the attribute/URL index, and to add the necessary database indexes. There's also a cron URL the module gives you so the index rebuilds on a schedule rather than on a page load.

[screenshot: the "Indexes and caches" panel inside ps_facetedsearch, with the rebuild buttons and the cron URL the module exposes]

Take the cron URL the module shows you and run it on a schedule from your server's crontab, rather than rebuilding by hand. A nightly rebuild keeps the facet counts honest as stock and prices move:

# crontab -e – rebuild the ps_facetedsearch index nightly at 03:15
# use the exact URL the module's "Indexes and caches" section gives you
15 3 * * * curl -s "https://your-store.example/modules/ps_facetedsearch/ps_facetedsearch-cron.php?token=YOUR_TOKEN&full=1" >/dev/null 2>&1

Swap in the literal URL and token from your own back office. The path and token are generated per store, so don't copy them from elsewhere.

• Build (and re-build) the index. After a bulk product import, a price change across a category, or adding new attributes, the facet index goes stale. Counts go wrong and filters can miss products. Rebuild it (manually after big changes, via the module's cron routinely). On a 5,000-SKU catalog this is the difference between filters that respond instantly and filter clicks that take seconds.
• Let it add the database indexes. The module can create MySQL indexes that turn each filter query from a full-table scan into a fast lookup. If you skipped that step, every filter click on a large category is doing far more work than it should.
• Cap products per page. Show 24–48 products per filtered page with pagination, not 500 at once. Set this under Shop Parameters → Product Settings ("Products per page"). Combine with lazy-loaded thumbnails so a filtered mobile result doesn't pull hundreds of images at once.

So what? A correctly indexed, cron-refreshed ps_facetedsearch will carry a several-thousand-product catalog without the customer ever feeling it. An un-indexed one will make your busiest category, the one you most want converting, feel broken on exactly the devices where patience is thinnest.

Filtered URLs: keep the speed, don't wreck your crawl budget

Every applied filter creates a URL variation, and on a large catalog that's where crawl budget quietly drains. ps_facetedsearch generates filter-specific URLs for each combination, typically built around a q filter parameter (e.g. ?q=Colour-Black/Size-42) rather than fully separate path segments, so the URLs stay consistent, but the sheer number of them is exactly what you have to manage. Crawl and indexation are not solved by the module itself: deciding which filtered views Google should see is an SEO decision you enforce through your theme, robots rules and canonical tags. The judgement call is which filtered views deserve indexing: a handful ("black leather shoes") are genuine search demand worth a dedicated, indexable landing page; the thousands of long-tail combinations are not, and should be kept out of the index, via canonicals and robots directives, so Google spends its crawl on your real category and product pages. This is squarely an information-architecture question, how your category tree, URLs and indexation rules fit together, and it's covered in PrestaShop category structure and SEO-optimized navigation rather than rushed here.

The blunt-instrument first line of defence is a robots.txt rule that keeps crawlers off the filter-parameter URLs while leaving your clean category and pagination paths reachable:

# robots.txt – stop crawl budget draining into filter permutations
# ps_facetedsearch encodes active filters in the q parameter
Disallow: /*?q=
Disallow: /*&q=
# clean category paths and ?page= pagination stay crawlable

Two caveats worth stating so you don't lean on this alone. A Disallow stops crawling but not indexing of a URL Google already knows. The indexable-versus-not decision is enforced with canonical tags and meta robots, not robots.txt. And on PrestaShop 9 the platform already excludes filtered/faceted listing pages from indexing by default, so on 9 this rule mostly conserves crawl budget rather than fixing an indexation problem. The handful of filter combinations that are real search demand ("black leather shoes") should be promoted to their own indexable landing page instead of being blocked.

When the built-in filters aren't enough

For most stores, a well-configured ps_facetedsearch with a clean theme is genuinely all you need, and it's free. The honest boundary is worth stating plainly: don't buy a filter module to do something the bundled one already does. You start looking beyond it only when you hit a specific wall, filter behaviour the core module's templates can't express, a sidebar your theme renders awkwardly, or a search-plus-filter experience that needs the two to work as one. At that point a module from our search and navigation range earns its place; below it, you're paying for capability you already own.

The principle underneath all of this is simple: on a large PrestaShop catalog, the customer's job is to get from thousands of products to the handful they'd actually buy, in seconds, without typing. The platform already gives you the engine to do that. The work is configuring it for your catalog's shape, the right facets per category, the attribute/feature distinction modelled correctly, and the index built and kept fresh so it stays fast as you grow. Filters that get those three right don't just look tidy; they keep the customer in the flow long enough to reach a product page that converts.

Frequently asked questions

Does PrestaShop come with faceted search built in?

Yes. The ps_facetedsearch module ("Faceted search") ships with a default 1.7, 8 or 9 install and is usually already present under Modules → Module Manager, just not yet configured for your catalog. There's no global "turn on filters" checkbox; you build filter templates and attach them to categories. For most stores it's all you need, and it's free.

What's the difference between an attribute and a feature for filtering?

An attribute is a buyable variation, Size 42, Colour Black, each a real combination with its own stock and price. A feature is a fixed spec that just describes the product, Material: Leather, Screen: 6.1". Both are filterable in ps_facetedsearch, but only attributes carry stock and price. Model anything a customer buys a specific version of as an attribute; model facts about the product as features. Getting it backwards can't be fixed retroactively without a data rebuild.

Why is my faceted search slow on a large catalog?

Almost always a stale or missing index. Inside the module's "Indexes and caches" section, rebuild the price and attribute/URL indexes and let it add the MySQL database indexes. That turns each filter query from a full-table scan into a fast lookup. Then run the module's cron URL on a schedule so the index stays fresh after imports and price changes. On a 5,000-SKU catalog this is the difference between instant filters and clicks that take seconds.

Should filtered URLs be indexed by Google?

Only a handful. The filter combinations that are genuine search demand ("black leather shoes") deserve a dedicated indexable landing page. The thousands of long-tail combinations should be kept out of the index via canonical tags and meta robots, with robots.txt conserving crawl budget on the ?q= parameter. PrestaShop 9 already excludes filtered listing pages from indexing by default.

How do multi-select filters behave in ps_facetedsearch?

Multiple values within one facet are OR (size 41 OR 42. Useful for between-sizes shoe buyers), while different facets are AND (size 42 AND black). You don't configure this, it's the built-in behaviour, and it's the natural thing customers expect, so don't try to fight it.

Keep reading

• Category pages that convert: layout, filters and sorting. How the filter sidebar sits alongside the grid and sorting.
• PrestaShop category structure: SEO-optimized navigation, the tree, URLs and indexation rules behind filtered views.
• PrestaShop mega menu: building navigation that converts, browsing that lands shoppers on the right category to filter.