Ecommerce Website Development in Pune: Handling Filters and Faceted Navigation Without Creating Duplicate Pages

Ecommerce Website Development in Pune: Handling Filters and Faceted Navigation So They Help Shoppers Without Creating Duplicate Pages

When you build an online store, every filter a shopper can apply, such as size, colour, price band or brand, can generate a new web address. Left uncontrolled, a catalogue of a few hundred products can produce tens of thousands of near-identical URLs, which wastes search engine crawling, splits ranking signals and can bury the category pages you actually want to rank. The fix is to decide, before development, which filtered pages deserve to exist as real, indexable pages, and to make every other combination usable by shoppers but invisible to search engines. This is a core part of good ecommerce website development in Pune or anywhere else, and it is far cheaper to design at the start than to repair after the store has been indexed.

This article is for store owners, ecommerce managers and anyone briefing an agency on a new store or a migration. It explains how faceted navigation creates the problem, how to decide which filter pages to keep, which technical controls exist and what each one can and cannot do, how the main platforms behave, and how to test the result. It builds on our guide to fixing site search and category navigation, which deals with the shopper's side; this one deals with the search engine's side of the same feature.

What faceted navigation is, and why it multiplies URLs

Faceted navigation is the set of filters on a category page. On a fashion store: size, colour, fabric, price, brand, occasion. On an electronics store: brand, screen size, memory, rating, price range. Shoppers love it because it narrows a long list quickly.

For a search engine, each filter combination is typically a different URL, for example /shirts/?colour=blue&size=m&sort=price-asc. The page shows a different slice of products, but it uses the same template, the same heading and often the same descriptive text. And because filters can be combined in any order, the arithmetic is unforgiving. Eight filter groups with a handful of options each can produce a number of combinations that dwarfs the number of products in the store. Sorting options, pagination, session identifiers and tracking parameters multiply the total again.

Search engines do not know in advance which of those URLs matter. A crawler that finds a link to each of them will try to visit many. This causes three kinds of trouble:

1. Wasted crawling. Time spent fetching thousands of near-duplicates is time not spent on new products, updated prices and fresh category content. On a large catalogue this can delay important changes being picked up.
2. Diluted signals. Links and relevance that should concentrate on one good category page are spread across variations.
3. Wrong page ranking. Search engines may choose a strange filtered variation, with a thin product list, as the representative page for a query, instead of the category page you designed.

None of this is a penalty. It is the natural result of letting a system generate unlimited pages, and it is predictable.

The decision that comes first: which filter pages deserve to exist?

Before choosing any technical control, decide which filtered pages have genuine search demand and enough products to be a useful page. This is a business decision, not a coding one.

Consider a store selling sarees. Shoppers search for "cotton sarees", "silk sarees under 5000" and "kanjivaram saree online". A page for "cotton sarees" is a legitimate landing page; so, perhaps, is a page for a specific fabric and price band. A page for "cotton sarees, red, sorted by newest, page 3" is not. It is useful to a shopper already browsing, but nobody searches for it.

A practical way to decide:

• List the combinations people actually search for. Use search query data from Google Search Console if the store already exists, keyword research tools, and your own site search logs. Look for category-plus-attribute patterns: product type with colour, material, brand, size, price band or occasion.
• Check you have enough products. A filtered page with two items is a weak page. Set a minimum, such as a handful of products, below which the page is not offered to search engines.
• Check you can say something unique. A good filtered landing page has its own title, heading and a short introductory paragraph, not only a different product grid.
• Limit the depth. Typically one or two attributes combined, such as category plus brand or category plus material, is as far as indexable pages go.

The output is a short, written rule set, something like: "Category pages and category-plus-brand pages are indexable; category-plus-material is indexable for these five materials; everything else is not." Developers can build to a rule set; they cannot build to "make it SEO friendly".

Two kinds of filtered page, handled differently

Once you have rules, every filtered URL falls into one of two groups.

Group one: curated landing pages. These are filter combinations you have chosen to rank. They deserve a clean, readable address (for example /sarees/cotton/ rather than /sarees/?material=cotton&page=1&sort=popular), a unique title tag and heading, a short intro text, internal links from the menu or related categories, and inclusion in the XML sitemap. Many platforms let you create these as ordinary collection or category pages with a saved filter, which is often the cleanest route.

Group two: everything else. These are interactive filters that help a shopper but should not compete in search results. The aim is to keep them out of the index and, ideally, out of the crawl.

The technical controls and what each one actually does

There are several tools for managing Group two, and they are not interchangeable. Misusing them is the commonest source of problems.

Canonical tags

A canonical tag tells search engines which URL is the preferred version of a page. On a filtered page it would usually point to the unfiltered category page or to the curated landing page it is closest to. Search engines treat the canonical as a strong hint, not a command, and may ignore it if the filtered page differs substantially from the target. It does not stop crawling: the crawler still has to fetch the filtered page to see the tag. It is good for consolidating signals, but weak at saving crawl effort.

Noindex

A noindex directive tells search engines not to include the page in results. It is reliable for keeping pages out of the index, but, again, the page must be crawled for the directive to be seen. Pages left noindexed for a long time may also be crawled less often, but this is not a guarantee. Do not combine noindex with a canonical pointing elsewhere on the same page; the two signals conflict and the result is unpredictable.

Robots.txt disallow

A robots.txt rule can stop compliant crawlers from fetching URLs that match a pattern, for example anything containing a particular parameter. This saves crawl effort, which is why it is the tool of choice for very large catalogues. Its trade-off is that a blocked page cannot be crawled, so a canonical or noindex on it will never be seen, and a blocked URL can still appear in results without a description if other sites link to it. Use it for low-value parameter combinations, such as sort order or session identifiers, which should never be indexed. If you are updating this file for other reasons, such as controlling AI crawlers, read our guide on robots.txt and AI crawlers first, so that one change does not undo another.

Nofollow on filter links, or loading filters without links

Marking filter links as nofollow, or building filters so that they update the product list without exposing a crawlable link, reduces how many filtered URLs search engines discover in the first place. Search engines treat nofollow as a hint, and it does not clean up URLs that are already known, but it addresses the cause rather than the symptom. Google's own guidance on managing crawling of faceted navigation, published in its Search Central documentation, describes these options and their trade-offs; ask your developer to read the current version, because recommendations are refined over time.

URL fragments

Using a # in the address for filter state (for example /shirts/#colour=blue) means the fragment is generally not sent to the server and search engines typically do not treat it as a separate page. This is a clean technique for pure interface state, but it means you cannot also offer that combination as an indexable landing page.

Parameter handling tools

Google retired the URL Parameters tool in Search Console in 2022, so parameter behaviour can no longer be managed there. Control now has to come from your own site: the techniques above.

A sensible combination for most Indian stores

There is no single correct setting, but this pattern works for many small and mid-sized catalogues:

• Curated landing pages: clean URLs, indexable, self-referencing canonical, in the sitemap, linked from the menu.
• Single-filter and multi-filter interactive pages: noindex, follow with a canonical pointing to the nearest curated page or to the base category, so that signals consolidate.
• Sort order, view mode and tracking parameters: canonical to the base URL, and disallowed in robots.txt if they generate large numbers of URLs.
• Pagination: each page of a category in a self-referencing canonical, with products reachable by normal links, not only by "load more" scripts that a crawler cannot trigger.
• Internal links: link to curated pages from menus and related-category blocks; do not link every filter combination in the page's HTML.

For a very large catalogue, add stronger crawl controls and review server logs to see what crawlers are actually fetching. For a store with a few hundred products, over-engineering is a bigger risk than under-engineering.

How the common platforms behave

Behaviour depends on version, theme and apps, so treat these as things to check, not guarantees.

Shopify. Collections can be filtered with storefront filtering, and filtered views are generally accessed through parameters on the collection URL. Shopify generates canonical tags for collection pages, and it lets you edit the robots.txt template through a theme file when you need to add rules. Curated landing pages are typically created as dedicated collections with their own titles and descriptions. Check how your theme and any filtering app build the URLs, because apps can differ from native filtering.

WooCommerce. Layered navigation and filter plugins commonly add query parameters such as filter_colour, and SEO plugins can control canonical and noindex settings for these. Check that your plugin's settings treat filter URLs as you intend, and that the setting survives theme and plugin updates. Our article on why WooCommerce's HPOS default matters shows how platform changes can affect other parts of a store, which is a good reason to retest after updates.

Custom builds and headless stores. You have full control, which means you must write the rules yourself. Decide canonical, robots and sitemap behaviour in the specification, because nobody else will supply a default. Server-rendered category pages are safer for search than pages built entirely by client-side scripts. If you are weighing this architecture, see our article on headless commerce for Indian stores.

Marketplaces and ONDC. The product feeds you send to marketplaces and shopping channels are separate from your site's URLs, but the quality of your product data affects both. See our article on preparing product catalogue data for what a clean attribute structure looks like, which is also what makes sensible filters possible.

Structured data and filter pages

Structured data helps search engines understand a page, but it should describe what is actually there. Product pages need product markup with accurate price and availability. Category pages generally do not need product markup for every item in the list, and filter pages should not carry markup that implies a distinct product or a distinct offer. Breadcrumb markup is useful on category and curated landing pages because it expresses the hierarchy. Our article on which structured data your website actually needs explains which types apply where.

The shopper experience still comes first

It is easy to get so absorbed in search engine control that the filters themselves become awkward. Keep these principles:

• Filters should be fast and obvious. On mobile, a filter drawer with clear apply and reset controls works better than a long sidebar.
• Show what is applied and let shoppers remove it, with chips or labels above the product list.
• Never show a combination that returns no products, or if it happens, say so and offer the nearest alternative.
• Keep the back button working. A filter change that breaks the browser's back behaviour frustrates shoppers.
• Show counts next to options so shoppers know what they will get.
• Keep product data consistent. Filters depend on attributes; if one product says "Navy" and another "Navy Blue", the filter shows two options. Standardise attributes in the catalogue, not the interface.

A well-designed filter system serves both audiences: shoppers get a quick way to narrow, and search engines get a small number of strong pages.

A worked example

Imagine a Pune store selling kitchen appliances with about four hundred products: mixers, air fryers, kettles, and so on, in six brands and several capacity bands.

Decision. The owner reviews search data and finds that people search for "air fryer", "air fryer 4 litre" and "[brand] air fryer". The store decides that category pages, category-plus-brand pages and category-plus-capacity pages (for air fryers and mixers only) will be indexable, provided there are at least five products.

Build. Developers create those as curated landing pages with clean URLs, titles and short introductions written by the team. They configure other filter combinations as noindex, follow with canonical to the base category. Sort and view parameters are canonicalised and blocked in robots.txt.

Check. After launch, the team inspects a sample of curated pages and filtered URLs in Google Search Console's URL Inspection tool, confirms that the canonical Google selects matches the one declared, and reviews the Pages report for large numbers of "duplicate" or "crawled, not indexed" statuses. Each month for the first quarter, they compare the number of indexed pages to the number the sitemap contains.

Outcome. We do not promise a ranking improvement: that depends on competition, content and many other factors. What the work reliably does is remove avoidable obstacles and make it clear to search engines which pages matter.

How to test your setup

You do not need specialist tools to run a basic audit.

1. Check the sitemap. It should list only canonical, indexable pages: categories, curated landing pages and products. If it contains filter URLs or parameters, fix that first.
2. Search for the store on Google using site:yourstore.com plus a typical filter word, and look at what appears. A large number of near-identical filtered pages is a warning.
3. Use URL Inspection in Search Console on three or four filter URLs: see the user-declared canonical, the Google-selected canonical and whether the page is indexed.
4. Click through the filters yourself and watch the address bar. Note which parameters change and whether the order of parameters can vary for the same selection.
5. View the page source of a filtered page and check the canonical and robots meta tags are as specified.
6. Crawl the site with a crawler such as a desktop SEO tool, and look at how many URLs it finds versus how many products and categories you have. A very large gap means filters are exposing too many links.
7. Retest after any theme, plugin or platform update. Updates can reset SEO settings or change how filters generate links.

Mistakes we see repeatedly

• Blocking in robots.txt and also expecting noindex to work. The crawler cannot see the noindex on a blocked page.
• Canonicalising every filtered page to the home page. The canonical should point to a relevant equivalent, not to something unrelated.
• Creating thin landing pages in bulk. Hundreds of "[colour] [product]" pages with no unique text and two products each look like scaled low-value content, which is what search quality guidelines warn against.
• Leaving search result pages indexable. Internal site search pages usually should not be indexed.
• Letting parameter order vary, so that ?colour=blue&size=m and ?size=m&colour=blue are different URLs.
• Ignoring out-of-stock products. Decide whether to keep, redirect or mark them unavailable, rather than letting them vanish into error pages.
• Treating this as a one-time task. New attributes and new filters create new URLs; review the rules whenever the catalogue structure changes.

What to put in your brief to a developer

If you are commissioning a store, add these lines to the specification:

• Which category and filter pages are indexable, and the rule for minimum product count.
• URL format for category and curated landing pages.
• Canonical and robots behaviour for each type of URL (curated, filtered, sorted, paginated, search results).
• Sitemap contents: only canonical, indexable URLs.
• Filter behaviour on mobile, and how filters affect the browser's back button.
• A post-launch check using Search Console and a crawler, with a named person responsible.
• Who updates the rules when new filters are added.

Putting these in writing turns an invisible technical problem into a testable deliverable. If you are comparing agencies, our guide to ecommerce website development in Pune and the article on what a product page needs show what a well-structured store contains.

Working with Govindani Infotech

Govindani Infotech Pvt. Ltd. is an ecommerce website development company in Pune. Our website creation service includes planning the category and filter structure with the technical SEO rules above, and our SEO service can audit an existing store's crawl and index status. You can see examples of stores we have built in our ecommerce portfolio. To discuss your own catalogue, message us on WhatsApp or use the contact page; we will review the actual structure before suggesting changes.

Listing pages also need a paging pattern that crawlers can follow; see our guide to pagination, load more and infinite scroll.

Frequently Asked Questions

Do filter pages hurt SEO on an online store?

They can, if every filter combination becomes a separately crawlable and indexable URL. That wastes crawl effort and spreads ranking signals across near-duplicates. Filters themselves are not harmful: the solution is to keep a small number of valuable filtered pages indexable and prevent the rest from competing in search.

Should I use noindex or robots.txt for filter URLs?

They do different jobs. Noindex keeps a page out of search results but requires the page to be crawled. Robots.txt saves crawling but stops search engines seeing a noindex or canonical on the blocked page. Many stores use noindex on moderate-value filters and robots.txt only for parameters that generate huge numbers of useless URLs, such as sorting.

Which filter pages should be indexable?

Those that match what people actually search for, have enough products to be useful and can carry their own title, heading and introductory text. Usually that means categories and one or two attribute combinations, such as category plus brand or material. Check Search Console and keyword data to choose, instead of guessing.

Does Shopify or WooCommerce handle this automatically?

Both provide some defaults, such as canonical tags, but the result depends on your theme, filtering app or plugin and settings. Neither guarantees the structure your catalogue needs, so check how filter URLs are generated, test a sample in Search Console and re-check after updates.

How do I know if my store has a faceted navigation problem?

Compare the number of URLs a crawler finds, or the number Google reports as indexed, with the number of products and categories you actually have. A big gap, or many pages listed as duplicates or "crawled but not indexed", suggests filters are generating too many URLs. Search site: with a filter word to see examples.

Related reading: Building product filters and sorting that work on a phone.