Layered Navigation for Magento 2

Shoppers can pick several options in one filter (for example Black or Blue) and combine filters (Black or Blue, in size M). Selected options are shown as "Now shopping by" chips with a remove link, "Clear All" and "Clear <filter>". Each attribute can be shown as checkboxes, swatches, a dropdown or a price slider, long lists get "Show more" and a search box, the list updates without a full page reload, and filtered category pages can have readable addresses.

Yes. Options of one attribute are combined with OR, so the counts of a filter you are already using are calculated without that filter's own selection ("disjunctive" counts). This costs one extra search request per filtered attribute, at most six per page. All counts come from the search engine (OpenSearch or Elasticsearch); nothing is queried per product.

Yes. The module ships Hyvä layout handles and registers itself for Hyvä's Tailwind build, so the styles are merged into your theme CSS when you rebuild it. The behaviour is one small vanilla JavaScript file shared by Luma and Hyvä, with no RequireJS, jQuery or Alpine needed. It was tested with Hyvä 1.5 and the default theme.

/women/tops-women.html?color=49,50&size=168 becomes /women/tops-women/color-black-blue/size-m.html. Each attribute gets one path segment, sorted by attribute code, and the options within a segment are sorted alphabetically, so every combination has exactly one address. Other orders and the old query-string addresses answer with a 301 redirect. The setting is off by default and can be switched on per store view.

Yes. Under CommerceGears > Layered Navigation > Filter URL Slugs you pick an attribute and a store view and enter a slug for each option (letters a to z, digits and single hyphens). Empty fields use the store view's option label. The demo's German store view uses German colour slugs such as color-blau-schwarz.

Dropdown, multiple select and yes/no attributes on category pages. Price and decimal ranges, the category filter, sorting and paging stay in the query string (for example ?price=20-50&p=2). Search results keep query-string filters.

No. The filter router only answers when the full address is not an existing URL rewrite, so products, CMS pages and real subcategories always win. It also checks that the rest of the path is a category of the store view and that every segment is a valid filter.

Links that combine two or more filter values get rel="nofollow", so crawlers are not sent through every combination; pages with a single filter value stay crawlable. If you use an SEO module for robots and canonical tags, it can read the current filters through the module's FilterStateInterface.

No. Every filtered list is a normal GET address, so the full page cache stores it like any other page and the list works without JavaScript. With Ajax filtering on, the product list, the filters and the address bar update without a reload, and Back and Forward work.

The product column is replaced with the same HTML a normal page load returns, Luma widgets are started again and on Hyvä inline scripts run and Alpine components are initialised. After that the event commercegears:layered-navigation:updated fires on document, so analytics, sliders or lazy loaders can run again.

Not in this version. Stock status and ratings are not offered as filters.

The automatic slug follows the option label, so an address with the old name returns 404. Set a custom slug under Filter URL Slugs to keep an address when you rename an option.