Separate filter combinations that deserve durable search landing pages from filters that exist only for users, then control URL generation, internal links, normalization, crawling, canonicals, pagination, and invalid states for each class.
- Faceted navigation can expose far more URLs than the underlying product or record inventory.
- Not every useful user filter deserves a crawlable and indexable landing page.
- Canonical annotations do not prevent the initial discovery and crawling of uncontrolled filter URLs.
- Empty, duplicate, impossible, and nonexistent paginated states should return honest responses.
01
Definition
Faceted navigation lets users narrow an inventory by selecting attributes such as category, brand, size, color, material, price, availability, location, rating, or date.
The interface can be useful while the URL system beneath it is disastrous.
A category containing 800 products might expose:
- Eight brands
- Six colors
- Five sizes
- Four materials
- Three availability states
- Four sort modes
- Twenty page numbers
Each additional control can multiply the number of reachable states. Crawlers cannot know whether a new combination is useful until they identify or request it. Google warns that faceted navigation can produce very large URL spaces, consume server resources, and slow discovery of useful URLs. Managing crawling of faceted navigation URLs[1]
The solution is not “block all filters” or “index every combination.” It is to divide facets into:
- Durable combinations that deserve public search landing pages
- User-interface states that should not become uncontrolled crawlable inventory
- Invalid states that should return an honest error response
02
Mechanism
Measure the theoretical state space
Suppose facet i has v_i possible values.
If every facet permits either no selection or exactly one selected value, the theoretical number of states is:
N_single = product from i = 1 to k of (v_i + 1)The added one represents choosing no value from that facet.
For the fictional inventory:
- Brand: 8
- Color: 6
- Size: 5
- Material: 4
- Availability: 3
The result is:
N_single
= (8 + 1)(6 + 1)(5 + 1)(4 + 1)(3 + 1)
= 9 × 7 × 6 × 5 × 4
= 7,560Add four sorting states and twenty page numbers:
7,560 × 4 × 20 = 604,800That is already hundreds of thousands of theoretical states for 800 products.
If values can be selected independently within each facet, each value can be either selected or not selected. The theoretical count becomes:
N_multi
= product from i = 1 to k of 2^(v_i)
= 2^(sum from i = 1 to k of v_i)For 26 total selectable values:
2^26 = 67,108,864Multiply that by sorting and pagination and the arithmetic becomes absurd quickly, which is exactly what computers excel at when nobody tells them to stop.
These counts are upper bounds. Business rules, incompatible filters, unavailable inventory, and application constraints reduce the real state space. Parameter-order permutations, duplicate values, tracking parameters, case differences, and unstable pagination can increase the URL space again.
Classify each facet
Use these categories:
Search-demand facet
A stable combination with evidence of independent user demand.
Examples:
- Product category
- Major brand
- Durable location
- Material with meaningful inventory
Inventory facet
A stable attribute that changes included records but may or may not deserve a search page.
Examples:
- Color
- Size
- Compatibility
- Feature
Usability facet
A control useful during browsing but not an independent public resource.
Examples:
- Sort order
- Grid or list view
- Items per page
Temporary facet
A state that changes too quickly or exists only for a session.
Examples:
- Current promotion
- Recently viewed
- Session-specific eligibility
User-relative facet
A state whose meaning depends on the current user.
Examples:
- Near me
- Available to my account
- Recommended for you
Only the first two classes are normal candidates for indexable landing pages.
Prevent unwanted URL creation
When filtered states do not need to appear in search, avoid generating crawlable links to them.
Possible designs include:
- Applying client-side filters without creating a new indexable path
- Using fragments for user-only filter states
- Preventing links to prohibited parameter families
- Applying robots.txt rules to known low-value parameter patterns
- Allowing crawlers to reach only the unfiltered listing and individual records
Google says sites that do not need faceted URLs indexed can prevent their crawling, including through robots.txt or fragment-based filter states. It also says canonical and nofollow signals are generally less effective as long-term crawl controls than preventing the unwanted crawl space directly. Managing crawling of faceted navigation URLs[1]
A robots.txt block manages crawling. It does not guarantee that a discovered URL disappears from search, and it prevents the crawler from reading page-level directives. Introduction to robots.txt[4]
Build approved landing pages deliberately
An indexable filtered page needs more than a URL.
Require:
- Stable normalized URL
- Meaningful inventory
- Distinct public purpose
- Crawlable internal links
- Useful title and heading
- Accurate canonical
- Honest pagination
- Durable availability
- Sufficient distinction from broader and narrower pages
Use an allowlist rather than permitting every combination and trying to remove bad ones later.
For example:
/category/shoes/
Approved:
/category/shoes/womens/
/category/shoes/womens/running/
/category/shoes/brand-example/
Not automatically approved:
/category/shoes/womens/running/green/size-8/in-stock/sort-price/The narrower page may be useful to a shopper. That does not make it a durable search landing page.
03
Examples
URL normalization
These URLs might describe one state:
/shoes?color=green&size=8
/shoes?size=8&color=green
/shoes?color=green&size=8&view=grid
/shoes?color=Green&size=8Define one normalized order and one representation.
If filters are encoded in the path, keep their logical order stable:
/shoes/womens/green/Do not also generate:
/shoes/green/womens/unless the application treats it as a genuinely different route.
Google recommends standard & separators for query parameters, consistent logical order for path-encoded filters, and prevention of duplicate filter values. Managing crawling of faceted navigation URLs[1]
Empty and impossible states
If no green size-8 shoe exists, the requested filter state should not return a generic 200 page pretending useful inventory exists.
Google recommends returning 404 for empty, duplicate, nonsensical, or nonexistent paginated combinations and serving the error at the requested URL rather than redirecting every failure to one common error address. Managing crawling of faceted navigation URLs[1]
Distinguish:
- Temporarily empty inventory that remains a useful category
- Impossible combinations
- Malformed filters
- Unsupported values
- Page numbers beyond the available sequence
A durable category can remain 200 with an honest empty-state message if the category itself remains valid. An impossible generated combination should normally be treated as not found.
Canonicals
A canonical can consolidate duplicate filtered variants over time. It does not stop the site from creating links, does not prevent the first crawl request, and does not make an unlimited parameter space cheap.
Google identifies rel="canonical" as a strong canonicalization signal while warning that it is not absolute. How to specify a canonical URL with rel=canonical and other methods[3]
Use:
- Self-canonicals on approved indexable filter pages
- Canonicals to a broader page when the filtered state is a genuine duplicate that must remain accessible
- No canonical as a substitute for controlling nonsense URLs
Ecommerce URL consistency
Google recommends persistent URLs, discourages internally linked temporary values, and advises sites to use their preferred URLs consistently across internal links, sitemaps, and canonicals. Designing a URL structure for ecommerce websites[2]
That means the link generator, sitemap generator, canonical generator, and request router need one shared normalization policy.
04
Boundaries
A robust faceted system can be represented as:
Filter selection
↓
Normalize values and order
↓
Validate combination
↓
Classify state
┌───────────────┬────────────────┬──────────────┐
│ Approved page │ User-only state│ Invalid state│
↓ ↓ ↓
Stable URL No indexable 404 at the
and link URL inventory requested URLAudit these failure modes:
- Every filter is an ordinary crawlable link
- The same state appears under several parameter orders
- Sort orders self-canonicalize and enter the sitemap
- Invalid page numbers return page one
- Empty states redirect to a shared error URL
- Canonicals point to unrelated broad categories
- Robots.txt blocks pages that rely on
noindex - The site links to noncanonical variants
- Product counts change the canonical URL
- User-relative states become public links
- Tracking parameters stack on filters
- The site generates unlimited dates, prices, or ranges
- JavaScript hides all approved landing-page links from crawlers
Monitor the result with the Crawl Stats guide and SEO log-file analysis. Use URL Parameters and SEO for the general classification system, Crawl Budget to determine whether the scale is operationally material, and the soft-404 guide when empty combinations return misleading success responses.
The objective is not to make every filter invisible. It is to expose a finite, intentional public URL inventory while leaving the rest as interface behavior.
References
Sources behind this record
- Designing a URL structure for ecommerce websites — Google (accessed July 29, 2026)
- How to specify a canonical URL with rel=canonical and other methods — Google (accessed July 29, 2026)
- Introduction to robots.txt — Google (accessed July 29, 2026)
Corrections
Correction history
No corrections recorded.
To report an error, use the public corrections path.
Theoretical combination counts describe possible application states rather than the number of URLs a crawler will necessarily discover, request, render, index, or rank.