Faceted navigation lets users filter a catalogue by attributes; each generated combination can need its own crawl and indexation policy.
Why facets need an SEO policy
Faceted navigation lets a visitor narrow a catalogue by attributes such as size, material, colour, availability or price. A single list of products can therefore produce many URL combinations. That is useful interaction design, but it creates a crawl and indexation problem: search engines may discover filter paths through links, form controls, pagination and parameter URLs even when the store did not intend each combination to become a landing page.
The question is not whether filters are ‘good for SEO’. It is which combinations deserve a stable public destination. Google’s faceted-navigation guidance focuses on avoiding excessive or infinite URL spaces and making crawl paths intentional. A filter combination may be a valuable landing page when it represents a recurring task, has enough matching inventory and offers a useful unique explanation. The rest can remain navigational tools.
Classify filter URLs
| Class | Typical example | Indexation treatment |
|---|---|---|
| Shopper-only state | Sort order, price slider, several temporary choices | Keep usable for visitors; avoid presenting it as a canonical landing page |
| Candidate landing page | Stable attribute combination with demand and sufficient inventory | Give it one canonical URL, unique title/H1 and crawl path |
| Duplicate route | Same selection in a different parameter order | Normalise or canonicalise to the chosen route |
| Empty result | Combination with no eligible items | Return a useful UI state but do not place it in sitemap or internal landing-page links |
Classification belongs to the data model as well as the URL policy. ‘Colour’ is usable only if products use controlled values; ‘price’ needs explicit buckets and a rule for overlapping ranges. Decide whether a multi-select creates a distinct task or only a temporary filter state. A canonical tag cannot turn thousands of thin parameter pages into useful content.
Implement the controls
First define a URL pattern for each class. Keep links to indexable landing pages crawlable and consistent. For navigation-only combinations, reduce unnecessary crawl paths through the site’s link generation and use the indexing controls appropriate to the platform; do not rely on robots.txt to make a page disappear from search after it has been indexed. Canonicals, noindex directives, pagination and sitemap inclusion must describe the same policy.
- Export attributes, units, allowed values and current result counts.
- Choose a small set of candidate combinations using demand, inventory depth and a distinct user task.
- Create one preferred URL form; normalise parameter order, casing and duplicate filters.
- Add unique visible content only to combinations promoted as landing pages.
- Keep navigation states out of XML sitemaps and remove internal links that accidentally generate endless combinations.
- Crawl representative single-select, multi-select, sorted, paginated and empty states to compare status, canonical and robots directives.
Example: a store may promote a stable ‘stainless steel desk lamps’ category because it has many items and a clear buying task. A URL that combines a slider value, a sort order and an out-of-stock toggle is a shopper state, not a page to publish in a sitemap.
Test real combinations
Test what the server and browser actually expose. Check the initial HTML, canonical target, robots directive, pagination links, internal inlinks and result count. Test parameter order swaps and direct visits to empty combinations. A valid policy can still fail if JavaScript links generate different URLs than the canonical convention or if a filter button returns a 200 page with no meaningful results.