Filters and Faceted Navigation: How Online Stores Create Thousands of Duplicate Pages

A customer sees a handy panel of filters. A search engine sees every combination of those filters as a separate address. Whether that becomes a source of traffic or thousands of duplicate pages depends on decisions made in the code, long before anyone looks at rankings.

SHORT ANSWER

Not Every Filter Is a Page

An online store should index only the filter combinations that have their own search value, and keep every other combination out of the way of its main categories. The filter panel and the set of SEO pages are two different things. Filtering is a tool for the customer who is already in the store; an indexable page is an answer to a query someone types into a search engine. When a store treats them as the same thing, it either creates thousands of near-identical pages competing with each other or hides combinations that could have brought real traffic.

For an owner, the practical point is simple: the fact that a combination can be generated does not mean it should exist in Google. That decision belongs in the architecture of the store, and it has to be made deliberately, one type of combination at a time.

This article continues our guide to e-commerce SEO built into the store, where filters are one of the layers that decide a store's visibility.

THE ARITHMETIC

Why Filters Multiply

The arithmetic is unforgiving. Take one category of shoes with ten colors, twelve sizes, thirty brands and five price ranges. If every combination of those filters gets its own address, the category alone can produce 18,000 variations. Add three sorting options and the number triples. Add pagination and it grows again. Most of these pages show almost the same products in a slightly different order.

Google described the result in its own guidance on faceted navigation in December 2024: crawlers spend their time on a near-infinite number of filter variations, the server spends resources answering them, and new products are discovered more slowly. For a store with tens of thousands of products, that is not a theoretical risk. It is a store where Google keeps revisiting "black sneakers, size 42, sorted by price" while a new collection waits to be found.

The second cost is less visible. Near-identical pages compete with each other and with the category they came from. Instead of one strong page for "men's sneakers", the store offers Google dozens of weaker versions of it, and none of them ranks as well as the category could on its own.

Scale changes which of the two costs matters more. Google says crawl budget is mainly a concern for very large sites, so a store with a few thousand products is rarely limited by how much Google can crawl. For that store the real damage is the second cost: duplicates that compete with the category and dilute its signals. The fix is the same in both cases, but it helps to know which problem you are actually solving.

Every filter combination is a page to Google, whether you planned it or not.

THE PET STORE

What It Looks Like in a Real Store

One of our clearest cases was a large pet supply store. Its catalogue generated a huge number of addresses through combinations of filters and sorting options, and the result was exactly what Google's guidance describes: duplicate pages and excessive crawling, with filter variations competing against the categories they were supposed to support.

We did not start by closing everything. We started by sorting the store's addresses into four groups:

• product pages, which must always be indexed and reachable;
• categories, the main source of search traffic;
• approved SEO landing pages, the filter combinations that deserve their own place in search;
• technical filter combinations, which exist for the customer's convenience and should not compete with anything.

Then we set the rules for how each group's addresses are formed, which canonical address each one points to and which of them can be indexed. The analysis showed which pages actually had value for search and which should never have competed with the main categories. To find the problem in the first place, we looked at the structure of the addresses, the filter parameters, the canonical tags, the data in Google Search Console and the results of a full crawl of the site. We told the rest of this store's story in the main article of this series.

WHICH COMBINATIONS

Which Combinations Deserve a Page

There is no universal threshold, and we would be suspicious of anyone who offers one. No fixed number of products or searches automatically makes a filter page worth indexing. The decision depends on the niche, the demand, the competition and the quality of the specific page. What there is, instead, is a set of questions we ask about every type of combination:

1. Does it match a query people actually search for on its own? "Men's Nike sneakers" or "red sneakers" may well be such queries. A combination of color, size, price range and three more parameters rarely is.

2. Does it hold enough relevant products to be a real selection rather than a page with two items?

3. Is the assortment stable, or will the page be empty next month?

4. Does it answer a different intent from the category it belongs to, or would it only duplicate it?

5. What does the search results page look like for that query: are competitors ranking with similar pages, and can ours be better?

Sorting is the easiest case: a list sorted by price shows the same products as the list sorted by popularity, so sorting variations should never be indexed. Size filters are usually technical too, because people rarely search for a size without a product. Brand and product type, on the other hand, often match real queries, which is why they are the first candidates for landing pages.

Opening a page for indexing is only half the job, because Google also has to find it. An approved landing page needs links from places that customers and crawlers already visit: the parent category, a block of popular selections, related categories or a guide on the blog, plus an entry in the sitemap. A landing page that appears only when someone happens to click the right filters is, for Google, almost the same as a page that does not exist.

THREE TOOLS

Canonical, Noindex and Robots.txt Are Not Interchangeable

Stores often treat three different mechanisms as if they were interchangeable, and the result is a configuration that contradicts itself. Each one does a different job:

The most common mistake is combining them carelessly: blocking filter pages in robots.txt and expecting their noindex tags to work, or putting a canonical on pages that are too different from the target for Google to accept it. The right tool depends on what you want to happen to a page: crawled and consolidated, crawled and excluded, or not crawled at all. Google's guidance adds a few rules that help in every case: keep the order of filter parameters consistent, use the standard separator between them, and make sure combinations that have no products and are not meant to exist do not return an empty page with a 200 status.

Two cases need a decision of their own. Filters with multiple selection, such as two brands at once, multiply addresses faster than any other kind, and those combinations are almost never search destinations, so they usually stay out of the index while each single brand can have its own landing page. Filters built entirely in JavaScript, which change the products without changing the address, create the opposite problem: no duplicates, but also no page for Google to index. Even a combination with real demand cannot rank until it gets its own address.

IN THE CODE

How We Build It in Laravel

Our position at Peretz Agency is about order: first we define the data model, the URL architecture and the criteria for SEO pages, and only then build the filters, never the other way round. Otherwise the catalogue is finished, the filters work, and the management of thousands of addresses has to be designed all over again on a live store.

In the stores we build on Laravel, we separate the mechanics of filtering from the logic that creates SEO pages. The filter panel can offer the customer every combination that is useful for choosing, without being restricted by SEO rules. A separate layer decides which of those combinations become pages in search.

That separation usually comes down to four responsibilities, each handled in its own place:

• Filter processing applies the selected attributes to the catalogue and returns the products.
• URL normalization keeps the order of parameters consistent and stops equivalent selections from creating different addresses.
• Landing page resolution checks whether a selected combination matches an approved, published SEO landing page with a stable, descriptive address.
• Metadata and indexing rules set the title, description, canonical address, robots directives and sitemap inclusion according to the type of page.

A filter helps a customer choose. A page answers a search.

Keeping these responsibilities apart means SEO decisions are not scattered across controllers and templates, and the catalogue and its indexing strategy can change without rewriting the store for every new combination. It is also why a plugin rarely solves the problem: a plugin applies one rule to every filter, while the decision about which combinations matter to a particular store's customers has to be made by people who know the catalogue and the market, and then encoded so that it holds as the assortment changes.

A LUXURY CATALOGUE

Planning Filters for Schoeffel

For Schoeffel, the heritage pearl brand whose store we are building, filters are part of the e-commerce architecture from the start rather than an interface feature added at the end. Customers can combine material, gemstone, colour, style, price and availability freely. What becomes indexable is decided separately.

We split the store's addresses into three classes: ordinary filtered views of the catalogue, made for browsing; SEO landing pages, selected by search demand, relevance to the catalogue and commercial value; and sorting and other technical variations that are never search destinations. We did not fix a list of indexable combinations in advance. A combination of jewellery type and material may well be a useful search destination, while one that adds colour, price and availability probably is not, but both are hypotheses to test against the real catalogue and the target markets, not rules decided before the analysis.

The plan also covers what happens as the range changes, which matters more in a luxury catalogue than anywhere else. A piece that is temporarily unavailable should not destroy a landing page that has value. Discontinued pieces and obsolete landing pages are handled according to their actual status and whether a relevant alternative exists. And a filter combination with no results is not automatically redirected to the main category: its response depends on whether that page is expected to exist at all.

Before launch, the filters are tested against realistic catalogue scenarios: the combinations themselves, address normalization and duplicates, canonical and robots directives, empty results, pagination and sorting, internal links and the sitemap, localized routes and metadata, and query performance as the catalogue grows. After launch, Search Console, server logs and analytics show which landing pages to add, keep or remove. The goal is not the largest number of indexed pages, but a catalogue where customers filter freely and search engines find the pages that matter.

THE SHOE CATEGORY

When a Filter Page Starts Bringing Traffic

The opposite case matters just as much: a filter combination that deserves to rank. In a clothing store we worked with, the category of men's shoes had filters by brand, color, size and other attributes. The task was to use the combinations people actually search for to bring in additional organic traffic, without creating thousands of low-value pages.

We chose combinations of category, brand and product type that matched independent search demand, such as "men's Nike sneakers". Each candidate was checked against search demand, the competing results, the number of available products and the stability of the assortment. The promising ones received their own indexable addresses, proper metadata and canonical tags. Narrower combinations, such as a specific color in a specific size, were considered separately and mostly left out of the index: the existence of a filter did not mean the page deserved to be indexed.

Within a few weeks the new pages began to receive impressions in Google. Over the following months, organic clicks to the selected landing pages grew from 263 to 670 a month, about two and a half times, and Search Console showed them ranking for queries that had brought the store no noticeable visibility before. Just as important, we checked that this was new traffic rather than traffic taken away from the main category.

MEASURING

How to Tell It Worked

A filter landing page should be judged by what it adds to the store, not only by its own numbers. We track the moment it is discovered and indexed, then impressions, clicks, queries and average position in Search Console, and conversions where the store's analytics can connect visits to orders.

The first impressions often come before stable traffic, so a page needs weeks, sometimes months, before a fair judgment. And every result has to be checked against two questions: has the page started competing with its own category for the same queries, and does it bring the business value beyond clicks? Seasonality, new collections and other changes on the site can make a page look better or worse than it is, which is why we compare periods rather than single weeks.

A good filter page adds new traffic. A bad one moves existing traffic around.

WHAT TO ASK

What to Ask Your Developer

If your store has filters, these questions show quickly whether they were built with search in mind:

1. Which filter combinations can be indexed, and who decided that?

2. How are the addresses of approved combinations formed, and are they stable when the assortment changes?

3. What happens to sorting and pagination parameters?

4. How do canonical, noindex and robots.txt work together on filter pages, and do they contradict each other anywhere?

5. What does an empty combination return, and what happens to a valuable landing page when its products are temporarily out of stock?

6. Are approved filter pages in the sitemap, and are technical ones kept out of it?

7. Does each approved page have its own title, description and heading?

8. How will we know whether a filter page brings new traffic or takes it from the category?

If the answer to the first question is "all of them" or "the plugin handles it", the store is probably producing pages nobody planned.

HOW WE WORK

How We Work on Filters

When a store comes to us with filter problems, we start with a crawl and the data in Search Console, sort the addresses into the four groups described above, and only then change rules. Sometimes the fix is a configuration and a few templates in the existing store, as with the pet store; sometimes the filter logic is so tangled in the platform that a rebuild of the catalogue is cheaper in the long run. For a store planning a move, this is one of the first things to settle before launch, as our website migration checklist explains, and for stores selling in several markets the same decisions multiply across every language and country.

Filters are part of our e-commerce SEO work, and for stores that are still being designed, part of e-commerce development from the first day.

FAQ

Sources

• Google Search Central: Crawling December, faceted navigation
• Google Search Central: How to specify a canonical URL
• Google Search Central: Block search indexing with noindex
• Google Search Central: Introduction to robots.txt
• Google Search Central: Crawl budget management for large sites