Magento Layered Navigation: 6 Setup Steps, Jewelry Filter Fixes

Layered navigation is Magento’s faceted filter system, the sidebar or top-bar controls that let shoppers narrow a category by attribute and price. If filters aren’t showing or aren’t working, check three things first: confirm the attribute has “Use in Layered Navigation” turned on, set the category’s “Is Anchor” property to Yes, and verify your search index and OpenSearch or Elasticsearch service are healthy.

TL;DR:

• Use equal price ranges for narrow, even catalogs; choose equal product counts for wide spreads, and align tax display settings across catalog pricing.
• For catalogs above a few thousand products, schedule indexers instead of updating on every save; MySQL navigation strains near 20,000 products.
• Block parameterized filter URLs in robots.txt, canonicalize filtered pages to their base category, and omit them from sitemaps; robots.txt alone does not remove indexed URLs.
• Use Multiple Select for facets shoppers may combine, such as metal types; Magento applies OR matching within a facet and AND matching across facets.

Table of Contents

• How to set up layered navigation step by step
• Price navigation: picking the right calculation method
• Fixing search backend and indexing failures
• Performance and scaling for large catalogs
• SEO for faceted navigation: avoiding crawl waste and duplicate URLs
• How JewelCloud helps jewelry stores avoid layered-navigation pitfalls
• Customizing the look and layout of your filter panel
• Adding multi-select filters for a better shopping experience
• Extensions and modules that extend layered navigation
• Managing complex jewelry attributes in layered navigation
• Filtering by inventory status and stock availability
• Making layered navigation work on mobile
• When layered navigation should be intentionally limited
• JewelCloud: a practical fit for Magento jewelry catalogs
• FAQ
• Sources

How to set up layered navigation step by step

Getting layered navigation working correctly comes down to three settings working together: the attribute, the category, and the global configuration. Miss one, and filters either won’t appear or won’t return results.

Start with the attribute itself. Magento only supports layered navigation on specific input types: Dropdown, Multiple Select, Yes/No, and Price. Text fields and text areas never show up as filters, which trips up a lot of admins who assume any attribute can be filterable. For each attribute you want shoppers to filter by, you’ll set “Use in Layered Navigation” to one of two values: “Filterable (with results)” hides options that would return zero products, while “Filterable (no results)” shows every option even when some lead to empty pages. Most catalogs do better with “with results,” since it keeps the filter list honest and avoids frustrating dead ends, according to Adobe Commerce’s documentation.

Here’s the sequence we recommend running through, in order:

1. Go to Stores → Attributes → Product, open the attribute you want to filter by, and confirm the input type is Dropdown, Multiple Select, Yes/No, or Price.
2. On the same attribute, open the Storefront Properties section and set “Use in Layered Navigation” to Filterable (with results).
3. Save the attribute, then navigate to Catalog → Categories, select the category where the filter should appear, and open Display Settings.
4. Set “Is Anchor” to Yes. This single setting tells Magento to pull in products from subcategories and display layered navigation at all, and it’s the single most common reason filters go missing even when the attribute is configured correctly, according to MageWorx’s layered navigation guide.
5. Visit Stores → Configuration → Catalog → Catalog → Layered Navigation to set global behavior, including Display Product Count and Price Navigation Step Calculation.
6. Reindex and clear cache, then load the category page on the storefront to confirm the filter appears.

A few global settings worth knowing about while you’re in that configuration screen:

• Display Product Count: shows how many products match each filter option, which helps shoppers avoid picking a filter that leads nowhere.
• Price Navigation Step Calculation: controls how price ranges are built, covered in detail in the next section.
• One Price Interval Automatic Calculation: sets the number of items used to build automatic price steps when traffic is low.
• Interval Division Limit: controls how many times Magento will try to split a price range before giving up on finer granularity.

Once you’ve made changes, don’t just refresh the page and call it done. Run through a short testing checklist:

• Open the category page in an incognito window to rule out cached admin sessions.
• Click each filter option and confirm the product count matches what’s shown.
• Combine two or more filters and verify the result set narrows correctly rather than resetting.
• Check the URL structure to confirm filter parameters are appended as expected.
• Test on a subcategory to confirm “Is Anchor” inheritance is working the way you expect.

If a brand-new attribute still isn’t showing up after all of this, the usual culprit is index staleness rather than a configuration mistake. Magento only picks up layered navigation changes after the catalog_product_attribute and catalogsearch_fulltext indexers run, which we cover in the troubleshooting section below. For jewelry catalogs specifically, this step matters even more: a single necklace style might carry a dozen filterable attributes (metal, stone type, chain length, clasp style), and each one needs to be deliberately mapped rather than enabled by default. Our guide on cleaning up facet filters for jewelry walks through a practical checklist for exactly this scenario.

Price navigation: picking the right calculation method

Price filters cause more support tickets than any other part of layered navigation, mostly because the three calculation methods behave very differently and the wrong pick creates lopsided, unhelpful ranges.

Magento offers three ways to build price buckets, all configurable from the same Layered Navigation settings screen Adobe Commerce documents:

• Automatic (equal ranges): divides the price spectrum into even dollar increments, like $0 to $100, $100 to $200, and so on. This works well when your price distribution is fairly even, but it can produce an empty-looking bucket at the high end if a handful of expensive items skew the range.
• Automatic (equalize product counts): builds ranges so each bucket contains roughly the same number of products, which tends to produce more useful, evenly populated filters for catalogs with wide price spreads, like jewelry stores selling both $50 earrings and $15,000 engagement rings.
• Manual: lets you define exact price breakpoints yourself, which gives the most control but requires updating the ranges by hand as your catalog and pricing shift over time.

The Interval Division Limit setting controls how aggressively Magento splits ranges further when a single bucket still contains too many products. It iterates until each range falls under the limit or the division limit is reached, according to Adobe Commerce’s documentation.

Price filters only behave correctly when tax and pricing display settings agree with each other. Sales Tax configuration, Catalog Prices, and Display Product Prices in Catalog all need to match, either all set to display prices excluding tax or all set to include tax. A mismatch here is a simple administrative error, but it’s one of the more common reasons price filters return the wrong products or display ranges that don’t line up with what shoppers see on the product page, according to Magezon’s troubleshooting guide.

For small to medium catalogs with a narrow price range, automatic equal ranges usually works fine. For stores with customer-group pricing or a wide spread between entry-level and premium pieces, equalize product counts tends to produce filters shoppers actually use.

Pro Tip: Check your Catalog Price scope settings before touching price navigation. If prices vary by website or customer group, verify which scope the layered navigation price calculation reads from, or ranges may not reflect what a logged-in customer actually sees.

Fixing search backend and indexing failures

Since Magento 2.4, layered navigation runs entirely on OpenSearch or Elasticsearch rather than MySQL, which means a search service problem shows up as a storefront problem even though nothing changed in the catalog itself, according to MGT Commerce’s Elasticsearch guide.

Watch for these symptoms, since they usually point to the same root cause:

• Category pages load but show no filters at all, even on categories that worked yesterday.
• Filters appear but clicking one returns an empty product grid.
• Storefront search returns zero results for terms that clearly exist in the catalog.
• The admin grid works fine, but the storefront is broken, a sign the problem is isolated to search rather than the database.

When any of these show up, work through this sequence rather than guessing:

1. Confirm the search service is running. If you’re self-hosting OpenSearch or Elasticsearch, check that the service is reachable on port 9200. A connection refused error here means layered navigation has no index to query against, regardless of how your attributes are configured.
2. Check indexer status with bin/magento indexer:status. Look specifically at catalogsearch_fulltext and catalog_product_attribute. If either shows “invalid” or “reindex required,” that’s your answer.
3. Reindex the search index with bin/magento indexer:reindex catalogsearch_fulltext. This rebuilds the search index inside OpenSearch or Elasticsearch and is the single most common fix for filters that vanish after a product or attribute update, according to Magetop’s indexer guide.
4. Flush the full page cache with bin/magento cache:flush. Magento can cache a pre-reindex version of a category page, so a successful reindex sometimes still shows stale results until cache is cleared.
5. Check cron. If indexers are set to “Update on Schedule” rather than “Update on Save,” a stalled cron job means changes never make it into the index at all. Run bin/magento cron:run manually to confirm cron is executing, and check the cron_schedule table for repeated failures.
6. Verify the Elasticsearch connection settings in Stores → Configuration → Catalog → Catalog → Catalog Search match the actual host, port, and index prefix your service is using. A mismatch here after a server migration is a common and easy-to-miss cause.

If the search service itself is healthy but a specific attribute still won’t filter, double check that the attribute was actually included in the reindex. Adding “Use in Layered Navigation” to an attribute after the last full reindex means it won’t show up until catalog_product_attribute and catalogsearch_fulltext both run again.

Pro Tip: Keep a saved shell script with your core reindex and cache-flush commands. When a filter issue comes in, running the full sequence takes under a minute and rules out the most common causes before you start digging into attribute configuration.

Performance and scaling for large catalogs

Layered navigation that works fine on a 2,000 SKU catalog can slow to a crawl once you cross a few thousand more products, and the fix usually isn’t more server resources, it’s a smarter indexing and attribute strategy.

Start with an attribute audit. Every filterable attribute adds a facet that your search engine has to calculate on every category page load, and most catalogs accumulate filterable attributes nobody uses. Go through your attribute list and disable “Use in Layered Navigation” on anything that isn’t driving actual filter clicks, things like internal SKU codes, legacy season tags, or attributes created for a one-off import that never got cleaned up.

Indexer configuration matters just as much. For catalogs beyond a few thousand products, set indexers to “Update on Schedule” rather than “Update on Save,” which batches updates through cron instead of reindexing on every single product save. This keeps admin product edits fast and prevents the kind of indexing pileup that leaves filters stale during busy catalog updates.

MySQL-backed layered navigation starts to show real strain around 20,000 products, with category pages slowing well past acceptable load times as the counting queries get heavier, according to Magevanta’s performance guide. Past that point, treat OpenSearch or Elasticsearch as a requirement rather than an option. Its in-memory aggregations handle faceted counting in parallel, dramatically improving category page load performance.

Caching deserves its own look. Full page cache needs to serve different versions of a filtered page depending on customer group and price scope, which means your cache key has to account for that context. Confirm the X-Magento-Vary header is present in response headers, since Varnish or nginx configurations that strip this header will break correct caching and force Magento to rebuild pages that should have been served instantly, according to Inviqa’s explanation of Magento’s full page cache. On high-traffic stores, custom cache keys that include customer-group IDs prevent the storefront from serving one shopper’s filtered price range to another shopper in a different pricing tier.

On the Elasticsearch or OpenSearch side, a few tuning details matter once your catalog grows:

• Limit aggregation bucket sizes for attributes with hundreds of distinct values, like vendor or manufacturer names, to avoid memory spikes and slow responses.
• Run a separate index per store view rather than one shared index, which keeps store-specific attribute sets and pricing clean.
• Use index aliases to swap a freshly built index into production with minimal downtime during full reindexes.
• Tag caches with CATALOG_PRODUCT so that individual product updates invalidate only the relevant cached pages instead of the entire cache.

Here’s a quick view of common fixes and what they typically address:

Pro Tip: Before assuming you need more server resources, check whether your slowness is coming from too many filterable attributes rather than too few resources. Trimming unused facets is often the faster, cheaper fix.

SEO for faceted navigation: avoiding crawl waste and duplicate URLs

Every filter combination on a category page can generate its own URL, and that combinatorial growth is where faceted navigation quietly turns into an SEO liability. A category with multiple filterable attributes, each offering several options, can produce a very large number of unique filtered URL combinations, most of which show nearly identical product sets to each other.

Search engines have limited time and resources to spend crawling any one site, and when that budget gets spent on thousands of near-duplicate filtered pages, the pages that should rank, your core category and product pages, get crawled less often. The standard guidance here is to use robots.txt to prevent search engines from crawling parameterized filter URLs in the first place, which preserves crawl budget far more effectively than trying to clean things up after indexing, according to Magedelight’s layered navigation SEO guide.

It’s worth being precise about the difference between two tools that get confused constantly: robots.txt blocks crawling, while noindex removes a page from search results after it has already been crawled. Blocking a URL in robots.txt does not guarantee it won’t appear in search results if other pages link to it, and applying noindex to a URL that’s also blocked in robots.txt means search engines may never see the noindex tag at all, since they can’t crawl the page to find it.

A practical setup for most Magento catalogs looks like this:

• Block multi-parameter filtered URLs in robots.txt using a wildcard pattern that matches your filter query string structure.
• Add canonical tags on filtered category pages that point back to the clean, unfiltered category URL, so link equity consolidates rather than splitting across every filter combination.
• Exclude filtered URLs from your XML sitemap entirely. Sitemaps should only list the pages you actually want indexed.
• Consider allowing a small number of single-filter pages to be indexed when they target real search demand, like a “gold necklaces” filter page that gets meaningful search volume on its own.

Magento’s native canonical and noindex controls are binary, a page is either indexed or it isn’t, with no built-in way to say “index this attribute’s filter pages but not that one.” Stores that need finer control, like indexing single-attribute filters but blocking every multi-attribute combination, typically need a dedicated SEO extension that supports per-attribute robots settings, according to Magedelight’s guide.

Here’s a quick summary of what to do and why:

How JewelCloud helps jewelry stores avoid layered-navigation pitfalls

Jewelry catalogs push layered navigation harder than almost any other product category. A single ring might need filterable attributes for metal type, stone shape, carat weight, ring size, and setting style, and if that data arrives from five different vendors in five different formats, every one of those attributes becomes a cleanup project before it can even be turned into a usable filter.

We built our Product Feed to solve this at the source rather than after the fact. Vendor data arrives standardized against GIA-aligned attribute values, which means a “round brilliant” diamond from one supplier and a “round” diamond from another map to the same filterable value instead of creating two separate, broken filter options. Our guide on GIA-aligned Magento jewelry attributes walks through why this remapping work piles up so quickly without standardization.

A few specific ways this plays out for layered navigation:

• Standardized attribute sets mean fewer custom attributes need to be created and maintained per vendor, reducing the ongoing audit work covered in the performance section above.
• Consistent value formatting across vendors prevents the malformed or duplicate filter options that confuse shoppers and bloat your attribute list.
• Structured feeds reduce the manual mapping that otherwise falls on a merchandiser every time a new vendor’s catalog is onboarded.

For retailers building out assortments from multiple suppliers, that consistency is what keeps layered navigation useful instead of becoming another maintenance burden.

Customizing the look and layout of your filter panel

The default Magento layered navigation layout puts filters in a left sidebar with a basic accordion style, and while it’s functional, most stores benefit from adjusting position and styling to match their broader storefront design.

Positioning is the first decision. Sidebar placement works well for desktop-first catalogs with a long attribute list, while a horizontal filter bar above the product grid often performs better for stores that lean on fewer, high-value filters like price and category. Luxury and jewelry storefronts in particular tend to favor a cleaner, collapsed filter bar that doesn’t compete visually with product photography.

Styling adjustments typically involve theme-level template overrides rather than core code changes, which keeps the customization upgrade-safe. Common adjustments include converting default checkboxes into swatch-style visual filters for attributes like metal color or gemstone, since a small color swatch communicates faster than a text label. Collapsed-by-default filter groups with an expand toggle also help long attribute lists feel less overwhelming on first load.

Whatever layout you choose, test it against the admin paths covered earlier. A visual redesign doesn’t change the underlying attribute or anchor settings, so styling work should always happen after the functional configuration is confirmed working, not before.

Adding multi-select filters for a better shopping experience

Single-select filters force a shopper to pick one option, see the results, then start over to try a different combination. Multi-select filters let shoppers pick several options within the same attribute, like selecting both “14k gold” and “18k gold” at once, and see combined results immediately.

For jewelry shopping in particular, multi-select behavior matters because buyers often have a range in mind rather than one fixed choice. Someone shopping for an anniversary gift might be open to multiple metal types or a span of price points, and a filter that forces a single selection pushes them toward starting over rather than refining.

Magento supports multi-select behavior natively for attributes using the Multiple Select input type, which is why choosing the right input type back at the attribute-setup stage matters beyond just enabling the filter. Dropdown attributes limit shoppers to one selection at a time within that attribute, while Multiple Select attributes allow several selections to combine with OR logic within the same facet and AND logic across different facets.

When reviewing your attribute list, flag any filter where customers would realistically want more than one option selected at once, metal type, stone type, and ring size are common candidates, and confirm those are set up as Multiple Select rather than Dropdown. It’s a small configuration detail that has an outsized effect on how usable the filter panel feels in practice.

Extensions and modules that extend layered navigation

Magento’s built-in layered navigation covers the fundamentals well, but a lot of stores eventually hit a feature gap that core functionality doesn’t address, things like swatch-based visual filters, per-attribute SEO controls, or advanced filter layouts with sliders and range inputs.

Third-party extensions typically fill a few recurring gaps:

• Visual swatch filters that turn color, metal, or stone attributes into clickable swatches instead of text checkboxes.
• Ajax-based filtering that updates the product grid without a full page reload, which improves perceived speed.
• Advanced price sliders as an alternative to fixed price-range buckets.
• Per-attribute SEO controls for indexing and canonical behavior, addressing the binary limitation covered in the SEO section above.

Before adding any extension, confirm it’s actively maintained and compatible with your current Magento version, since layered navigation touches indexing, caching, and search in ways that make poorly maintained extensions a common source of the exact performance and reindex problems covered earlier in this guide. A reasonable rule of thumb: if a module hasn’t been updated to match your Magento version’s release cycle, treat that as a warning sign rather than a minor detail.

For stores managing complex vendor feeds alongside extension-based filter customization, keeping attribute data clean before it reaches the extension layer avoids compounding problems. Our guide to mapping supplier catalog data into shoppable sets covers this kind of upstream data hygiene in more detail.

Managing complex jewelry attributes in layered navigation

Jewelry attribute sets are unusually deep compared to most retail categories. A single engagement ring might carry filterable values for metal type, metal color, center stone shape, carat weight range, clarity grade, setting style, and band width, and that’s before accounting for customizable options like ring size.

A few practices help keep this complexity from turning into a cluttered, slow filter panel:

• Standardize value formatting across every vendor before attributes go live, so “round” and “round brilliant” don’t create two separate filter options for the same thing.
• Group related attributes logically in the storefront layout rather than listing a dozen filters in one undifferentiated column, separating “stone details” from “metal details” for example.
• Reserve carat weight and price as range-based filters rather than exact-match dropdowns, since few shoppers search for an exact carat figure.
• Periodically audit attribute usage data to catch filters that technically work but rarely get clicked, which are candidates for removal under the performance guidance covered earlier.

Our broader catalog management guide for retailers covers the data preparation work that makes this kind of attribute discipline sustainable across a growing vendor list, rather than something that has to be redone every time a new supplier comes on board.

Filtering by inventory status and stock availability

Shoppers get frustrated fast when a filter leads them to a product that’s out of stock, which makes inventory-aware filtering one of the more underused layered navigation features.

Magento supports filtering by stock status through the standard Salable Quantity and stock status attributes, letting you add an “In Stock” filter alongside your standard attribute facets. For jewelry retailers managing made-to-order pieces or limited vendor allocations, this matters more than it might for a catalog of mass-produced goods, since stock status can shift based on vendor-reported availability rather than a simple warehouse count.

A couple of practical decisions to make:

• Decide whether out-of-stock items should disappear from layered navigation results entirely or remain visible with a clear “out of stock” label, a merchandising choice rather than a technical limitation.
• If you’re working with a multi-vendor feed, confirm stock status syncs on a schedule tight enough that filters don’t show availability that changed hours earlier.

Getting this right depends heavily on how current your vendor stock data actually is, which circles back to the same data-standardization theme that runs through attribute management generally: a filter is only as reliable as the data feeding it.

Making layered navigation work on mobile

Layered navigation has to work differently on a phone screen than it does on desktop, simply because there’s no room for a persistent sidebar next to a product grid.

The standard mobile pattern replaces the sidebar with a “Filter” button that opens a full-screen or slide-in panel, letting shoppers browse the full filter list without it competing for screen space with products. Applied filters typically show as a summary bar, often with removable chips, so shoppers can see and adjust their selections without reopening the full panel.

A few mobile-specific details matter for jewelry catalogs in particular:

• Swatch-style filters for metal and stone color need to stay large enough to tap accurately on a small screen, smaller than desktop swatches often fail basic usability.
• Price range sliders should default to reasonable increments rather than requiring pixel-precise dragging on a touchscreen.
• Multi-select filters need a clear “Apply” action on mobile, since instant-update behavior that works fine on desktop can feel jarring with every tap on a phone.

Responsive theme templates handle most of this automatically in current Magento versions, but it’s worth testing your specific filter configuration on an actual device rather than just a resized browser window, since touch interaction reveals usability problems that a desktop simulation misses.

When layered navigation should be intentionally limited

The instinct to filter by every attribute a product has is understandable, but it’s usually the wrong call. Every filterable attribute adds a facet that your search engine has to calculate on every page load, adds another dimension to the combinatorial URL problem covered earlier, and adds one more option a shopper has to parse before finding what they want.

A better approach starts from actual shopper behavior rather than catalog completeness. If analytics show nobody clicks a filter, it’s not a neutral addition sitting quietly in the sidebar, it’s a performance and crawl-budget cost with no offsetting benefit. We’d rather see a store filter by the four or five attributes that genuinely drive decisions and handle the rest through curated landing pages, a hand-built “Gifts Under $500” page outperforms an auto-generated price-filtered URL almost every time, both for shoppers and for search visibility.

The rule of thumb we keep coming back to: index single-filter combinations where real search demand exists, block the rest, and treat every new filterable attribute as a decision with a cost, not a free addition.

— Anthony

JewelCloud: a practical fit for Magento jewelry catalogs

If attribute cleanup and filter troubleshooting sound like more work than your team has time for, that’s exactly the gap we built our platform to close. Our Product Feed delivers standardized, GIA-aligned attributes straight into your Magento catalog, so the mapping work covered throughout this guide happens before the data ever reaches your store rather than after a frustrated support ticket.

Beyond the feed itself, DiamondLink handles diamond-specific data integration, and RingBuilder gives shoppers a configurable path to a finished piece without requiring a separate filterable attribute for every possible combination. For retailers sourcing from multiple vendors, our Jewelry Vendor Membership - Silver plan gives access to standardized vendor data feeds built for exactly the kind of catalog complexity jewelry stores deal with every day.

The outcome retailers see most often: fewer misconfigured filters, a shorter path from vendor data to a live, filterable catalog, and attribute values that stay consistent as new suppliers get added. If you’re ready to see what a standardized feed looks like for your own catalog, check out our vendor membership options and get your product data flowing with the structure layered navigation depends on.

FAQ

Why is layered navigation not showing on my category page?

The most common cause is the category’s “Is Anchor” setting being set to No, which prevents layered navigation from displaying at all regardless of attribute configuration. Check Catalog → Categories → Display Settings and confirm Is Anchor is set to Yes, then reindex and clear cache.

Why are my filters showing but returning no products?

This usually means the search index is stale or your OpenSearch or Elasticsearch service isn’t responding correctly. Run bin/magento indexer:reindex catalogsearch_fulltext and confirm your search service is reachable, then flush the full page cache.

Does layered navigation require Elasticsearch or OpenSearch?

Yes, since Magento 2.4, layered navigation and catalog search both run through OpenSearch or Elasticsearch rather than MySQL, according to MGT Commerce’s Elasticsearch guide. If that service is down or misconfigured, filters will fail to load even when attribute settings are correct.

How do I stop faceted filter URLs from hurting my SEO?

Block parameterized filter URLs in robots.txt to preserve crawl budget, add canonical tags pointing filtered pages back to the base category, and exclude filtered URLs from your sitemap. Native Magento controls are binary, so stores needing per-attribute robots settings typically rely on a dedicated SEO extension.

What’s the difference between automatic and manual price navigation?

Automatic methods calculate price ranges for you, either in equal dollar increments or in ranges sized to hold similar product counts, while manual lets you define the exact breakpoints yourself. Manual offers more control but needs to be updated by hand as your pricing changes over time.

Sources

• Layered navigation | Adobe Commerce
• Magento 2 AWS Elasticsearch guide — MGT Commerce
• Magento 2 layered navigation SEO settings — Magedelight
• Magento 2 layered navigation performance — Magevanta / DEV
• Magento layered navigation pitfalls — Magezon

Recommended

• Fix Facets and Faceted Filters for Jewelry: 6 Steps for Jewelers
• 6 Step Jewelry Attribute Mapping Playbook for Retailer PIMs
• Optimize Jewelry Catalog Data for Higher Conversions
• Avoid Jewelry E-Commerce Platform Errors Retailers Make