What Is Faceted Navigation?

Faceted navigation is the filter system that narrows a listing by several properties at once: brand, size, colour, price, availability. Each property is a facet, and the visitor may combine them freely until only what they want is left.

For whoever is buying it is one of the best things a shop can have. Finding black leather ankle boots in size 42 under a hundred euros without filters means going through whole pages; with filters it takes three clicks.

The problem lies not in the function but in what it leaves behind. If every combination produces an address of its own, the number of URLs grows multiplicatively — and that is where the road to index bloat starts.

It deserves separating from ordinary navigation, because they look alike on screen and have nothing in common underneath. The category menu describes a hierarchy somebody decided: footwear contains ankle boots, ankle boots contain leather ankle boots. Facets describe no hierarchy at all, only properties that can be switched on and off in any order.

That difference explains why one can be walked in full and the other cannot. The menu has a number of routes you can count on your fingers; the set of filters has so many that no crawler will exhaust them. Treating the two alike is the origin of nearly every problem that follows.

Intuition fails here, and it fails in the same direction every time: you count the filters and think adding one more adds a few pages. It does not add them, it multiplies them by the number of values it has.

Order compounds it. If brand+colour and colour+brand produce different addresses, every combination gets counted several times, and what was large turns absurd. The same happens when sort order and items per page also travel in the URL.

And almost none of those addresses has demand. Somebody searches for "black leather ankle boots"; nobody searches for "black leather ankle boots size 41 between 80 and 100 euros with 24-hour delivery". The combination exists, is useful as a filter, and makes no sense as an indexable page.

One case multiplies even harder and hardly anyone looks at it: filters that accept several values at once. If three colours can be ticked in the same query, the facet no longer contributes the number of its values but the number of its subsets — and that grows far faster than the multiplication itself.

And a quiet side effect: the combinations that return nothing. Filtering by a brand that makes no sandals produces an empty page answering 200, that is, an automatically generated soft 404. In a large catalog those empty combinations are the majority, because hardly any property crosses with all the others.

The first cost is crawling. A catalog with open facets can offer the crawler more addresses than it will ever walk, and every visit to one of them is crawl budget that never reaches the product pages that change.

The second is scattered signals. Ten addresses with the same content competing against each other behave like duplicate content: none accumulates enough strength, and the canonical exists precisely to gather them.

And the third is paid on the server. Every request to a rare combination is a heavy database query, and during hours of intense crawling that worsens the TTFB real visitors feel.

A fourth cost is the one the team notices first: the report stops being useful. A coverage listing with tens of thousands of combinations makes it impossible to see whether the product pages have a real problem, and decisions get made on averages that no longer describe anything. The same effect as in web analytics when noise exceeds signal.

And an overlooked consequence for structure: every link to a combination is an internal link. When the filter bar links to dozens of URLs from every catalog page, internal linking spreads weight across destinations that contribute nothing, and what should sit close gets diluted.

The underlying decision is not technical: you choose which combinations deserve to be a page and which are only a view. A workable criterion is demand: if somebody searches for "black leather ankle boots", that combination deserves its own URL, its own title and its own text. If nobody searches for it, it is a filter and nothing more.

The ones that deserve a page get treated as real categories and linked from the navigation so their click depth does not grow. The rest are gathered with a canonical onto the base category, or kept out of the index with noindex when they should keep existing for users.

And robots.txt plays a different role here than the one usually assigned to it: it is no good for deindexing, but it is good for stopping the crawler spending time on patterns you already know contribute nothing. It applies while those URLs are not yet indexed; if they already are, you must let them be crawled first so the instruction gets read.

How the filter links are built decides everything else: whether they are real links or controls that respond to a click through code. With real links the crawler walks everything left open — for better and worse; with controls it walks nothing, and then even the combinations you do want indexed need another route.

And an order of work that saves grief: before touching rules, measure. Four weeks of log file analysis shows which patterns the crawler is actually requesting, and there are usually surprises: combinations nobody had in mind consuming most of it, while others thought to be trouble receive not a single visit.

The first is leaving everything open and trusting Google to choose well. It does choose — but by its own standard and at its own pace, and meanwhile crawling goes where it should not.

The second is closing everything at once. Among the combinations are a few with real demand that were bringing visits; blocking them along with the rest shows up in traffic within weeks. Before applying a rule in bulk, check in Search Console which patterns receive clicks.

And the third is treating it as a one-off problem. While the system keeps generating a URL per combination, the index fills again. The fix that lasts lies in deciding which addresses should exist, not in cleaning up the ones that already do.

A fourth mistake is indexing a combination with demand and giving it nothing of its own. If "black leather ankle boots" deserves a page, it also deserves a title, a description and a paragraph that explains something; an empty template with products inside looks too much like thin content to hold a position.

And the last, the one that recurs most in migrations: changing the parameter scheme with no plan for the old addresses. The indexed combinations of the previous version keep appearing in results and in external links for months; without a 301 redirect to the equivalent, they all land in 404 errors at once.