Online shop filters can create many URLs showing similar products without offering a useful page for Google search. Before blocking them, distinguish collections worth appearing in search from combinations needed for shopping, inspect how their links are generated and test changes without breaking the catalogue. A useful buying filter does not always need its own search landing page.
Why can filters multiply the pages in your shop?
Choose a product family, add a colour and sort by price. The screen still looks like an ordinary catalogue, but the browser address has changed several times. If every combination is linked as a separate page, a search engine can discover many routes to almost identical selections of products.
This is faceted navigation: people narrow a collection using attributes. It helps customers find products and may be essential in a shop. Problems arise when URL construction generates duplicate combinations, equivalent orderings or empty results that continue to look like new pages. The filter itself is not automatically the problem.
Imagine a lighting shop with filters for room, finish, power and installation type. This is a hypothetical example, not a meiika customer. A buyer needs those controls to choose a suitable product. Every mix of attributes does not necessarily deserve a page designed to attract searches.
Google explains that filter combinations can consume crawling resources and make useful pages harder to discover. Its recommendations depend on whether you need those URLs to be indexable. This is a reason to review the architecture, not proof your shop suffers from the problem. Source: Google faceted navigation guidance, accessed 13 October 2026.
Start by browsing the catalogue and saving several addresses showing practically the same thing. Note what actually changes in products, headings and text. If only the ordering differs, you have a candidate for investigation, rather than sufficient grounds for a general block. Establish the pattern before proposing a rule.
Which combinations deserve their own search page?
A useful commercial collection answers a recognisable need and presents an understandable selection. Base the decision on the catalogue, observed queries and what you can explain on the page. A different address for every filter does not automatically create different or valuable content for a search visitor.
In the lighting example, an outdoor wall-light collection may make sense if there is a real range, relevant guidance and a defined commercial purpose. A mix of ordering, temporary availability and one finish with a single result may only need to function as navigation for someone already shopping.
Classify combinations before changing settings:
- Priority collections: a stable selection, clear purpose and original content helping people decide.
- Shopping filters: combinations for finding items inside the catalogue without a separate acquisition strategy.
- Equivalent variants: addresses presenting the same selection with a different order or repeated parameters.
- Impossible combinations: incompatible attributes or result pages that do not exist.
Product count alone is insufficient. A small collection can answer a specific query well; a large one can be indistinguishable from several others. Consider maintenance too. A page empty for part of the year needs a policy consistent with its purpose and catalogue behaviour, rather than an improvised reaction each time.
Before adding pages, look for an existing category covering the same need. For very similar destinations, decide which serves the user better and how its links should be organised. Commercial architecture comes before technical tags. Changing a canonical cannot fix a confusing classification or explain why two collections should exist.
How do canonical, noindex and robots.txt differ?
These controls answer different questions. A canonical identifies a preferred version among similar pages. A noindex instruction asks that a page not appear in search results. Robots.txt limits a crawler's access to particular routes or patterns. Treating them as interchangeable can produce an unexpected result.
Google must be able to crawl a page to read its noindex instruction. Blocking it in robots.txt may prevent the crawler from reaching that instruction. Limiting crawling and requesting exclusion from the index are different changes. Source: Google guidance on noindex, accessed 13 October 2026.
A canonical is not an instruction to delete alternative pages or a guarantee that their crawling stops immediately. In the facets guide, Google describes it as a signal that may reduce visits to non-canonical versions over time. Avoid using it to combine pages answering genuinely different commercial needs.
Begin with the desired outcome. Do you want a collection to remain in Google? To avoid discovery of unnecessary combinations? To remove an existing page from results? The answer guides both the mechanism and the sequence. Copying another shop's rules without those distinctions may hide important destinations.
Ask for a proposal identifying patterns to change, the reason and how the effect will be checked. Include permitted and excluded examples. An overly broad rule may catch parameters used for genuine navigation, pagination or functions outside the catalogue. Reviewing examples makes that risk more visible before deployment.
How can you inspect URLs without breaking shopping?
Start with a representative sample: a main collection, a useful filter, an equivalent combination, an empty result and a later page of the listing. Examine the visible experience and server response. A screen displaying an error may still return a successful HTTP status, so appearance alone is insufficient.
For impossible or empty facet combinations, Google recommends returning HTTP 404 at that URL. Do not turn that into a blanket rule for every out-of-stock product. An unavailable product and a non-existent filter combination are different situations, each needing a policy appropriate to the catalogue.
Test parameter order as well. Choosing a finish before a room should not create an inconsistent journey compared with selecting the room first. Represent the combination consistently rather than generating additional versions for every route to the same selection. Record examples of both orders during the review.
Keep the buying journey functional. Check that people can apply and remove filters, open a product, return to the list and move between pages. A shared filtered address should make its selection understandable to the recipient. Reducing crawling is not a justification for removing navigation customers need.
Retain the earlier rules and trial changes in a separate environment where possible. Then inspect a small set in production. Avoid simultaneously changing routes, templates, categories and crawling rules: if something fails, separating the changes makes the cause easier to identify and the earlier behaviour easier to restore.
What should you measure after changing filters?
Before intervening, record affected URLs and important collections. Review their presence in Search Console and, with authorised access, server logs. Note comparison periods and the changes made. A short-lived drop in visits is not sufficient to attribute a cause, especially when several things changed together.
Afterwards, check whether unwanted combinations are still discovered and priority collections retain working access and links. A technical change may not appear immediately in every tool. Reports and crawling operate on their own timescales. Keep expectations tied to observed behaviour rather than an assumed immediate update.
Assess the business journey too: internal searches with no results, enquiries about hard-to-find products and failures when removing a filter. A technically tidy catalogue can still use labels customers do not understand. Architecture and navigation should serve the same purpose, not succeed in separate checklists.
Document decisions for the next person maintaining the shop. When a new attribute is introduced, its effect on URLs and which combinations may become collections should be clear. Otherwise an ordinary catalogue update can recreate the same proliferation a few months later. Maintenance is part of the architecture.
How do we approach this at meiika?
At meiika, we can examine the relationship between catalogue, navigation and a business website. Scope starts with URL examples, buying journeys and content decisions before technical changes are proposed.
Measurement and Growth & MarTech help define what to observe and which uncertainties remain. We do not promise rankings or guaranteed results. Each shop needs evidence of its particular situation and the effects of the proposed changes.