Filters make a large catalogue usable. A customer can move from 2,000 pairs of shoes to the 12 that are black, waterproof and available in their size.
The same interaction can create thousands of URLs. Search engines may spend time crawling combinations that contain the same products, no products, or no search demand. Meanwhile, valuable products and categories can be discovered more slowly.
On a large ecommerce site, this is rarely a small technical tidy-up. It is a decision about which parts of the catalogue should be findable through search.
In brief
- Faceted navigation creates filtered versions of category or search-result pages, often through URL parameters.
- The number of possible URLs grows quickly as filters, values, sorting and pagination combine.
- Some filtered pages can answer useful searches. Most combinations do not need to appear in organic search.
- Canonicals, robots rules and
noindexare controls. They cannot decide which pages have commercial value.- Start by classifying filter states as search landing pages, customer-only states or invalid states. Then choose the right technical treatment for each group.
How one category becomes thousands of URLs
Faceted navigation is the set of filters used to narrow a product list by attributes such as brand, size, colour, material, price or availability.
A single collection might offer eight brands, six sizes, five colours, four materials and four price bands. If a shopper can choose one value from each facet or leave it unselected, that creates 9,449 possible combinations before multi-select filters, sort orders and pagination are added.
That number is illustrative. The real total depends on the catalogue, filter logic and URL implementation. The important point is that the estate grows multiplicatively.
Each facet can be omitted or contribute one value. The combinations multiply.
(9 × 7 × 6 × 5 × 5) − 1 9,449 possible filter states Before multi-select values, sort options, pagination and alternate parameter order.
Google describes faceted navigation as the most common source of overcrawling issues reported to its search team. Its current crawling guidance identifies two main consequences:
- Search engines can spend substantial computing resource downloading duplicate or low-value URLs.
- Discovery of useful pages can slow because crawling is occupied elsewhere.
A narrow crawl-budget label misses several consequences. A poorly governed filter system can also create:
- several URLs competing for the same query;
- weak pages with little inventory or no distinct purpose;
- valuable filtered categories that are hard to discover through internal links;
- inconsistent canonicals and indexation signals;
- monitoring noise that hides more important problems;
- brittle rules that nobody owns after a platform migration or catalogue change.
The commercial cost is usually uneven
The risk depends on scale and change rate. A 500-product catalogue with four simple filters presents a different problem from a marketplace with millions of listings, frequently changing inventory and filter values generated from seller data.
The cost also falls in different places.
New and updated products can wait longer
If crawlers repeatedly visit sort orders, tracking variants and empty combinations, new products or refreshed categories may receive less attention. Google is explicit that excessive faceted URLs can slow the discovery of useful pages.
Useful category opportunities can remain hidden
Some combinations represent real demand. A permanent landing page for “women’s waterproof walking boots” may be more useful than a broad walking-boots category. If every filter is blocked or canonicalised to its parent, that opportunity may be lost.
Teams inherit fragile technical rules
A blanket rule can look efficient until merchandising changes an attribute, a new storefront launches, or a filter app changes its URL format. The resulting behaviour often spans the ecommerce platform, frontend, CDN, robots rules, canonical tags and internal linking. Ownership becomes unclear quickly.
Decide what each filter state is for
The first decision is editorial and commercial. Technical controls should follow it.
Each recurring filter pattern belongs in one of three groups.
| Group | Purpose | Typical evidence | Likely treatment |
|---|---|---|---|
| Search landing page | Satisfies a distinct, durable search need | Search demand, suitable inventory, differentiated intent, commercial relevance | Stable URL, crawlable links, self-canonical, useful title and content, included in navigation or sitemaps where appropriate |
| Customer-only state | Helps a shopper narrow the current list | Useful on site, but no separate search need or too many volatile combinations | Allow the interaction while controlling crawl discovery or indexation according to the implementation |
| Invalid or noise state | Has no useful customer or search purpose | Empty results, contradictory values, duplicate orderings, tracking or sort variants | Return an appropriate error or prevent generation and discovery; avoid soft-404 pages |
This classification avoids two common extremes. Opening every combination creates waste. Closing every combination can remove useful category pages.
Ecommerce specialist Luke Carthy describes the practical answer as “a sweet spot somewhere towards the middle”. That is a useful principle, although the middle will differ by catalogue.
Start with evidence from the site
A sensible investigation combines four views of the same system. A crawl can expose the pattern, but deciding what matters requires validation, commercial context and a cause the team can act on.
1. What URLs can the interface create?
Map the filters available on each important template. Record parameter names, value formats, selection order, multi-select behaviour, sorting and pagination. Test both links in the HTML and interactions added by JavaScript.
Pay attention to duplicate routes. These URLs may show the same products while looking different to a crawler:
/running-shoes?colour=black&size=8
/running-shoes?size=8&colour=black
/running-shoes?colour=black&colour=black&size=8Google recommends a consistent parameter order and one URL form for the same filter state.
2. What do search engines actually crawl?
Use server log files to see which patterns Googlebot requests, how often it returns and which sections receive less attention. A crawler shows what is reachable. Logs show what search engines chose to request.
Look for repeated crawling of:
- alternative parameter orderings;
- sort and display options;
- empty result sets;
- very deep combinations;
- paths that redirect or canonicalise elsewhere;
- filter states created only for on-site behaviour.
3. Which pages are indexed or receiving demand?
Search Console can help identify parameter patterns already appearing in search and the queries attached to them. Combine that with query research, internal-search data where appropriate, and merchandising knowledge.
Do not promote a filter page because a keyword tool reports a number. Check whether the intent is distinct, the inventory is stable enough, and the page can remain useful when stock changes.
4. What can the platform control reliably?
Confirm where URLs, canonical tags, robots directives, status codes and links are generated. Test the rendered HTML as well as the browser interface. A control that exists in an admin screen may not produce the expected output across every template.
Choose controls after the policy is clear
No single directive solves every faceted-navigation problem.
Crawlable, indexable landing pages
For combinations chosen as search landing pages, give each page a stable URL and a clear purpose. It should be reachable through normal <a href> links, return a successful status, use a self-referencing canonical and offer inventory that matches the promise of the page.
The title, heading and supporting copy should reflect the selected category rather than repeat the parent page unchanged. Copy cannot rescue a page with weak inventory or duplicate intent.
Robots.txt
Google recommends robots.txt as one option when faceted content does not need to be crawled. It can reduce crawling of predictable URL patterns efficiently.
Blocking also prevents Google from seeing page-level canonical or noindex directives on those URLs. Check whether the blocked pattern overlaps any landing page you want discovered. Test rules against every important URL format before release.
Canonical tags
A canonical can consolidate signals between duplicate or very similar URLs. Google notes that canonicals may reduce crawling of duplicates over time, but their effect is less immediate than a crawl block. Google treats the canonical as a hint and may choose another URL.
Canonicalising a useful filtered page to a broader parent sends the wrong message. The pages do not serve the same intent simply because they share a template.
noindex
noindex can keep a crawlable page out of search results once the directive is seen. It does not prevent the crawl needed to see that directive, so it is a poor answer when the main problem is a vast crawl space.
URL fragments and interaction-only state
Google suggests URL fragments as an option when filter state does not need to be crawled. Fragments are generally not sent to the server as part of the request. This can keep an interaction useful for customers without creating a new crawlable URL for every state.
The frontend must still work for customers, analytics and sharing. Headless teams should make this an explicit routing decision rather than an accidental side effect of JavaScript state.
Error handling
Empty or nonsensical combinations should return a proper 404 when there is no reason for them to exist. A 200 response with an empty product grid can leave a very large set of soft-404 pages available to crawl.
Platform-specific points to check
Platform defaults only establish the starting condition. A complete search policy still has to account for themes, apps, extensions and headless frontends, all of which can change the behaviour materially.
Shopify
Shopify’s current storefront filtering uses URL parameters. Its documentation shows patterns such as:
/collections/all?filter.p.product_type=shoes&filter.v.option.color=redA merchant can create up to 25 filters, and filter values can be combined. Sorting adds a separate sort_by parameter. That gives a useful, predictable pattern for auditing, but apps and custom themes may introduce others.
Check which filter links appear in rendered HTML, what canonical each filtered response emits, how pagination behaves after a filter is applied, and whether legacy tag-based collection routes remain accessible. Shopify now allows robots.txt customisation through theme code, but a broad rule should only follow a clear URL policy.
Adobe Commerce and Magento Open Source
Adobe Commerce calls the standard feature layered navigation. Attributes can be configured as filterable with results or filterable with no results, and anchor categories expose layered navigation. Adobe Live Search has a separate facets system, so identify which implementation is active before specifying a fix.
Native category and product canonical settings do not, by themselves, answer how every layered-navigation combination should behave. Extensions commonly alter URLs, metadata and linking. Test representative combinations across category, search and price navigation, including zero-result values and multiple attribute selections.
BigCommerce
BigCommerce supports storefront search filters and contextual filters, while themes and custom storefronts determine much of the visible interaction and routing. Confirm whether the store uses Stencil, Catalyst or another headless frontend before documenting patterns.
Treat the generated HTML and URL behaviour as the evidence. Record which filters are linked, whether parameters have stable ordering, what canonical is returned, and whether custom code creates variant or filter URLs that the platform does not manage automatically.
Headless storefronts
In a headless build, the commerce platform may supply filter data while the frontend owns URLs, links, rendering and metadata. Test the first server response. Google advises that pages and products should be reachable through crawlable links because its crawlers do not operate buttons or trigger every JavaScript interaction.
Agree ownership across SEO, product and engineering before implementation. Otherwise one team can change routing while another assumes the old crawl controls still apply.
A practical release checklist
Before changing a live filter system, ask:
- Which filtered combinations have a distinct, evidenced search purpose?
- Which are valuable only within the customer journey?
- Which URL patterns are duplicates, invalid or effectively infinite?
- Can every approved landing page be reached through a crawlable link?
- Do status codes, canonicals and robots directives match the classification?
- Are parameter names and ordering consistent?
- What happens when a combination has no products?
- Will rules still work after a theme, app, extension or catalogue change?
- How will logs, crawling and indexation be checked after release?
- Who owns the policy when new filters are introduced?
The last question is important. Faceted navigation tends to return as a problem because the catalogue keeps changing while the search policy stays undocumented.
Frequently asked questions
What is faceted navigation in ecommerce?
Faceted navigation is a system of filters that lets customers narrow a product list using attributes such as brand, size, colour, material, price or availability. Each selection may create a new URL or update the current page state.
Why can faceted navigation cause SEO problems?
Filters can create a very large number of similar URLs. Search engines may crawl duplicate, empty or low-value combinations, which can consume resources and slow discovery of useful pages. Some combinations may also compete for the same search intent.
Should all filtered URLs be blocked in robots.txt?
No universal rule applies. Google recommends preventing crawling when faceted content does not need to appear in search. Some filtered pages may deserve to be indexable because they answer distinct searches. Classify the URL patterns before blocking them.
Should filtered pages canonicalise to the main category?
Only when the filtered URL is genuinely a duplicate or close equivalent of the category page. A filtered page with distinct search intent and useful inventory usually needs a self-referencing canonical if it is intended to rank.
Does noindex solve a crawl-budget problem?
Not directly. A crawler generally needs to request the page before it can see a noindex directive. It may keep the page out of search results while leaving much of the crawling demand in place.
How do I know which filter pages should be indexable?
Look for distinct search demand, commercially relevant and sufficiently stable inventory, a clear difference from the parent category, and a reliable way to link to and maintain the page. Use query data, crawl data, server logs and merchandising knowledge together.
Do ecommerce platforms handle faceted-navigation SEO automatically?
They provide useful defaults and controls, but themes, apps, extensions and custom frontends can change the outcome. Large sites usually need an explicit policy for which filter patterns are crawlable and indexable.
When a focused investigation is useful
If filters have grown with the catalogue, a focused investigation can establish where crawl demand is going, which landing-page opportunities are being missed and which controls are safe to change.
If the symptoms extend beyond filtering, seven warning signs that a complex ecommerce site needs technical investigation can help define the wider question first.
The output should be a tested URL policy, a prioritised implementation plan and clear tickets for the teams who own the platform. That is usually more useful than another export of every parameter URL a crawler can find.
Sources
- Google: Managing crawling of faceted navigation URLs
- Google: Crawling December, faceted navigation
- Google: Help Google understand your ecommerce site structure
- Google: Pagination and incremental page loading
- Google: Designing a URL structure for ecommerce sites
- Shopify: Storefront filtering
- Shopify: Collection template
- Shopify: Customize robots.txt
- Adobe Commerce: Layered navigation
- Adobe Commerce: URL rewrites and canonicals
- Luke Carthy interview: Winning at ecommerce SEO