Why a product attribute is missing from Magento 2 layered navigation

You add a product attribute, fill in values on a few hundred products and tick what looks like the right box. The category page sidebar still shows Price and Color and nothing else. You get no error, and nothing in var/log mentions it. The filter just isn't there.

In Magento 2.4.7, a layered navigation filter depends on a chain of settings: how the attribute is configured, which attribute set it belongs to, the product data, the category settings, which products are eligible to show, the search index and the theme. If any one of these is wrong, the filter disappears without an error. So go through the chain in order and read each setting before you change anything. Changing settings at random on a live catalog creates a second problem while you're still chasing the first.

'Used in Product Listing' is not the filter setting

This is the most common mistake. On the attribute edit page (Stores > Attributes > Product), the Storefront Properties tab has several flags with similar names. 'Used in Product Listing' only loads the attribute's value into the product collection on listing pages. That's useful if a template prints the value on a product tile, but it has no effect on layered navigation.

The setting that matters is 'Use in Layered Navigation', which has three values:

• No: the attribute is never shown as a filter.
• Filterable (with results): only options that match products in the current listing are shown.
• Filterable (no results): all options are shown, including ones with zero matches.

Search results pages have their own flag, 'Use in Search Results Layered Navigation'. If the filter shows on search but not on categories, or the other way round, check this pair.

Also check the input type. The layered navigation option is only offered for select-style inputs (Dropdown, Multiple Select and the swatch types) and for Price. A Text Field attribute can't be a filter, whatever else you set. Turning a text attribute into a dropdown means moving its values into options, and that is a data migration, not a checkbox.

To read the current state without opening the admin form:

SELECT ea.attribute_code, ea.frontend_input,
       cea.is_filterable, cea.is_filterable_in_search, cea.position
FROM eav_attribute ea
JOIN catalog_eav_attribute cea ON cea.attribute_id = ea.attribute_id
WHERE ea.attribute_code = 'your_attribute';

is_filterable is 0 for No, 1 for 'with results' and 2 for 'no results'.

The attribute has to reach the products

A 'with results' filter only shows options that products in the current listing actually have. Two things commonly break that.

The first is the attribute set. If the attribute isn't in the attribute set those products use, it doesn't appear on their edit form and they have no value for it. Check every attribute set used in the category under Stores > Attributes > Attribute Set, not just Default.

The second is scope. If the attribute's scope is Store View, values may have been saved at the default level or on a different store view, so the storefront you're testing can show something different from the admin grid. On the product edit page, switch the scope to the store view you're testing and confirm the value is there.

One behavior catches people out. With 'Filterable (with results)', Magento leaves out any option whose product count equals the total number of products in the listing, because selecting it wouldn't narrow anything. If every product in the category has the same value, there are no options left and the whole filter disappears. That is intended. Test in a category where the values actually differ.

The category decides which products are counted

Open the category and go to Catalog > Categories > Display Settings.

• If Display Mode is 'Static block only', the product list is removed, and layered navigation goes with it.
• Anchor controls whether products assigned only to subcategories are included in the parent category's listing. If your products sit in child categories and the parent isn't an anchor, the parent's product collection may not include the products that have the attribute at all.

On a large catalog, changing a category to an anchor makes the category product index bigger and changes what customers see on the parent page. Make that change on purpose, not as a debugging step.

Product eligibility shrinks the collection further

Layered navigation counts the same products the listing shows. A product is only included if it is:

• Enabled
• Assigned to the website for the current store
• Set to a visibility of 'Catalog' or 'Catalog, Search' (for category pages)
• In stock, when Display Out of Stock Products (Stores > Configuration > Catalog > Inventory > Stock Options) is set to No

If most of the products with the attribute value are disabled, out of stock or 'Not Visible Individually', the counts can drop to zero and the filter disappears. For configurable products, check whether the value is set on the parent or only on the simple children, then confirm what actually ended up in the index (next section).

The storefront reads the index, not the admin

In 2.4.7, layered navigation filters aren't built from MySQL on each request. The option counts come from the search engine, which in a current install is OpenSearch, and the catalogsearch_fulltext indexer is what fills it. The admin can show everything correctly while the index is out of date.

bin/magento indexer:status
bin/magento indexer:show-mode

If catalogsearch_fulltext shows 'Reindex required', or it runs on 'Update by Schedule' with a backlog, the index is older than your changes. In schedule mode, also confirm that cron is actually running. A dead cron is a common root cause on stores where nobody looks at cron_schedule. Then run:

bin/magento indexer:reindex catalogsearch_fulltext
bin/magento cache:flush

Changing an attribute's filterable setting changes what gets indexed, so you have to reindex after editing the attribute. The cache flush stops cached pages from showing the old sidebar.

If the filter is still missing, look at the search engine directly. Check which engine and host Magento uses under Stores > Configuration > Catalog > Catalog > Catalog Search. Then confirm the product index exists:

curl -s 'localhost:9200/_cat/indices?v' | grep product

Next, pull a document for a product you know has the attribute value. If the index has an unexpected prefix, Magento is writing to a different index than the one the storefront reads. If the document doesn't contain the field, the indexer isn't writing the attribute at all.

Themes and extensions can hide a working filter

If the index has the data and the filter still doesn't render, the problem is in the presentation layer. Custom themes sometimes remove or replace the catalog.leftnav block. Third-party layered navigation modules replace the filter list with their own configuration, which often has a separate on/off setting for each attribute. On staging, switch the store to Luma. If the filter appears, the bug is in your theme or module, not in the catalog data.

What to do next

Work through the chain from the top and stop at the first broken link:

1. Input type and 'Use in Layered Navigation'
2. Attribute set and store-view values
3. Category anchor and display mode
4. Product eligibility
5. Index state
6. Theme and extensions

Write down what you find before changing anything. Make the changes on staging first, especially anchor changes and full reindexes on large catalogs.

If you've checked every step and the filter is still missing, or the fix keeps reverting after deploys, the cause is usually custom indexer code, a module conflict or a broken cron setup. That is the kind of operational work covered in our Magento 2 practice. Send us the attribute code, your indexer:status output and a category URL, and we'll tell you where we'd look first.