Ecommerce site search, navigation and filtering: help customers find the right product

An ecommerce catalogue can contain exactly the right product and still make it nearly impossible to find.

The customer enters an industry term that the website does not recognise. A category reflects the supplier’s internal structure rather than the task the buyer is trying to complete. Filters contain dozens of attributes, but not the three that actually determine suitability. A mobile filter drawer hides the result count and forgets the selections when it closes.

These are not three separate interface problems. Search, navigation and filtering are different routes through the same product model.

Strong product discovery starts with customer language and dependable product data, then gives people several clear ways to reach a suitable result.

A new search application can be valuable. It cannot repair an incoherent taxonomy, incomplete attributes or an operating process that lets product data decay.

The short answer

Navigation helps customers explore the range through recognisable categories, tasks and relationships.
Site search lets customers express a need, product name, code or question directly.
Filtering narrows a meaningful result set by attributes that affect choice.

They should work together. A shopper may enter through Google on a category page, apply two filters, open a product, search a code and return through a breadcrumb. Treat the journey as one system.

Three discovery routes depend on the same language, catalogue and operational foundations.

Begin with how customers choose

Product discovery design often starts with the existing ERP categories or a proposed mega-menu. Start earlier: understand the decisions customers make.

Research can draw from:

Customer and sales interviews
Site-search queries
Searches with no results or no clicks
Search Console query and landing-page data
Customer-service questions
Product returns and compatibility issues
Sales and merchandising expertise
Competitor and market terminology
Catalogue attributes and data quality

Identify several modes of shopping.

Known-item search

The customer knows a product name, SKU, part number or brand. Precision, code formatting and typo handling matter.

Category exploration

The customer understands the product type but wants to compare options. Logical hierarchy, useful category content and product-list clarity matter.

Problem-led discovery

The customer knows the job, material, symptom or desired outcome but not the product type. Task-based navigation, educational content or guided selection may be more useful than a conventional category tree.

Compatibility-led selection

The customer needs a product that works with a model, environment, size or existing component. Structured compatibility data and deterministic rules can be critical.

One catalogue can require all four modes. Do not force every shopper into the organisation’s preferred route.

The product model is the real interface

A filter cannot be more reliable than its source attribute. Search cannot understand a concept that is represented inconsistently across titles, descriptions, tags and metafields.

For each decision-critical attribute, define:

Customer-facing name and description
Authoritative source system
Allowed values, units and formatting
Whether it applies to every relevant product
Variant or product-level ownership
Translation and regional variation
Update process and accountable owner
Behaviour when the value is missing

Normalise synonyms and units. “Stainless”, “stainless steel” and an internal material code may refer to the same concept. Dimensions cannot be sorted or filtered reliably when some are text, some are numbers and some mix millimetres with centimetres.

Product data work is not glamorous, but it is often the highest-leverage discovery improvement.

Navigation: design a map people can predict

Navigation should answer three questions quickly:

Where am I?
What choices exist from here?
How do I move back or sideways without starting again?

Use category names customers recognise. Limit the top level to meaningful distinctions rather than exposing the entire database. Where relevant, offer alternative entry routes such as “shop by application”, “shop by room”, “shop by vehicle” or “shop by industry”, but do not duplicate products into an unmanaged tangle of pages.

Breadcrumbs, related categories and clear page headings preserve orientation. Product-list pages need enough context for users to understand what belongs in the category and which attribute should guide the next decision.

Navigation also affects external search. Google’s official ecommerce site-structure guidance explains that Google analyses links among pages to understand relative structure and importance. Products available only through an internal search box may not be discovered by crawling. Link from menus to categories, from categories to subcategories and from those pages to indexable products where the model permits.

Site search: understand intent, not only character matches

Useful onsite search handles the vocabulary and error patterns of real customers.

Query understanding

Consider:

Singular and plural forms
Spelling errors and spacing variations
Product codes with punctuation or leading zeros
Synonyms and regional terminology
Brands, categories, attributes and applications
Natural-language questions
Compatibility phrases
Negative or excluded terms where supported

Shopify’s current storefront search documentation, for example, describes natural-language search, synonym groups, product boosts, filters and predictive search. That demonstrates the range of controls available in one platform; it does not mean the default configuration understands a business’s specialist catalogue.

Relevance and merchandising

Relevance should balance textual match with commercial and customer context. A result can match every word and still be unsuitable because it is discontinued, unavailable in the region or intended for another application.

Define how availability, popularity, newness, margin, brand, compliance or campaigns may influence ordering. Merchandising rules should not silently override relevance. A promoted product that does not satisfy the query damages trust.

Predictive search

Suggestions can help people refine a query and expose products, categories or content while they type. Keep the list readable, keyboard operable and resilient on mobile. Do not make the dropdown the only way to submit a full query.

No-result and weak-result states

“No products found” is diagnostic evidence and a customer-service moment.

Offer useful recovery:

Corrected spelling or related terms
Nearby categories
A clear reset path
Contact or assisted-selection option for complex products
An honest message when the range does not contain the item

Do not fabricate results that are unrelated to the request.

Filters: expose the attributes that change the decision

More filters do not automatically create more control. Every filter asks the customer to interpret a label, scan values and understand its effect.

Prioritise filters that:

Distinguish products in the current category
Reflect real customer decision criteria
Have sufficiently complete and reliable data
Use understandable values
Produce useful result sets

Context matters. “Size” may be essential in one category and meaningless in another. Filters should adapt to the product set rather than presenting a global wall of attributes.

Filter interaction details

A strong implementation should make it clear:

Which filters are active
How many results remain
Whether values combine with AND or OR logic
How to remove one value or clear all
Whether zero-result combinations are prevented or explained
Whether the state persists through back navigation and sharing
How the controls behave on mobile

Use customer labels, not database field names. Keep selected values visible after a mobile drawer closes. Avoid applying an expensive update after every tap if the experience becomes unstable, but show clearly when an “Apply” action is required.

Accessibility is part of product discovery

Search and filters are interactive applications. They need labels, keyboard operation, visible focus and understandable status changes.

Relevant WCAG 2.2 guidance includes logical focus order, visible focus, labels or instructions and programmatic status messages. When filtering updates a result count without moving focus, assistive technology should be able to receive that change without the interface unexpectedly interrupting the user.

Test with keyboards, screen readers, zoom and real mobile devices. An automated scan cannot evaluate whether a person understands the filter relationships or can recover from a dead end.

Protect search visibility while improving filters

Faceted navigation can generate large numbers of parameter combinations. Some represent valuable landing pages; many repeat substantially the same products in different orders.

Define deliberately:

Which categories and useful facet combinations should be indexable
Which filtered and sorted URLs should remain crawlable but consolidate elsewhere
Which should be prevented from creating crawl waste under the chosen architecture
Canonical behaviour
Internal-link rules
Pagination and incremental loading
Sitemap and product-feed coverage

Google’s pagination guidance recommends crawlable sequential links and warns that crawlers generally do not click buttons that require user interaction. Its URL guidance explains how alternative URLs can duplicate retrieval or cause content to be missed.

Do not apply one global rule such as “noindex every filter”. Search demand, catalogue scale, platform behaviour and crawl evidence should determine the model.

Measure the whole discovery journey

Search analytics should lead to action, not a monthly list of popular queries.

Useful measures include:

Search usage by device, audience and landing page
Queries with no results
Queries with results but no clicks
Result click-through and product-view rate
Search exits and reformulations
Filter use, removal and zero-result combinations
Product-list clicks and add-to-cart actions
Purchases or qualified enquiries following discovery
Time needed to maintain synonyms, rules and attributes
Missing or invalid product data

Shopify’s current Search & Discovery analytics, for example, includes searches by query, no-result searches, no-click searches, click rate and purchase rate. Interpret these as stages. A higher search purchase rate does not prove that a synonym caused the change without a controlled comparison and context.

Segment the evidence. Customers who search may already have higher intent than browsers. New mobile users may behave differently from logged-in trade buyers.

Measure discovery as a customer and operating system, not a search-box feature.

A public Emote example: Sutton Tools

Emote’s public Sutton Tools case study shows why discovery can extend beyond ordinary keyword search.

The current page describes more than 21,000 products, a multi-region website, complex ERP integration for inventory and an Expert Tool Selector. The selector guides a user through the job, material and setup towards a suitable tool path.

The transferable lesson is not that every large catalogue needs a custom selector. It is that product data, customer decision logic and operational systems must align. A clearly structured catalogue may need excellent categories, search and filters. A specialist range may also benefit from guided questions where customers do not know the correct product language.

Public Emote example: discovery quality depends on data, decision logic and experience.

A practical improvement sequence

Establish the baseline. Capture queries, no-results, filter behaviour, product-list performance, support questions and product-data quality.
Identify priority journeys. Select commercially important categories and customer tasks rather than redesigning every path at once.
Repair the data foundation. Normalise the attributes, units and relationships required for those journeys.
Prototype the routes. Test category language, search behaviours and filters with representative users and real catalogue data.
Define technical and SEO rules. Resolve URLs, crawlability, pagination, performance, analytics and accessibility before build.
Release in controlled increments. Compare segmented behaviour and qualitative feedback.
Govern ongoing tuning. Assign owners for synonyms, zero-result reviews, merchandising and attribute quality.

When paid Full Website Discovery is proportionate

A focused search or filter improvement may be scoped from good evidence and clean product data. Full Website Discovery becomes appropriate when unresolved taxonomy, data, ERP or PIM integration, multi-region behaviour, custom relevance, selector logic, accessibility or SEO architecture could materially change the solution.

Discovery can recommend a smaller intervention, data remediation before interface work, a platform-native tool, specialist search technology, a custom selector or no major rebuild.

Test product discovery with real tasks and catalogue conditions

A redesign should be tested against the work customers are trying to complete, not only against visual preference. Build a small task set from search terms, support questions, sales conversations and analytics. Include known-item searches, ambiguous needs, category exploration, compatibility questions, unavailable products and common misspellings.

Run those tasks across meaningful customer and catalogue segments. A search experience that works for a small consumer range may fail for technical buyers, account-specific products, long-tail spare parts or mobile users. Record the starting query or category, the route taken, the products returned, the decision information available and whether the customer reaches a credible next action.

Separate interface defects from catalogue defects. If a filter produces no useful result because attributes are missing, changing its colour or position will not solve the problem. Assign data-quality work to the catalogue owner, relevance rules to the search owner, page and interaction changes to the experience team, and integration failures to the responsible system team.

Release improvements in observable groups. For example, first repair high-value attributes and zero-result queries; then change category labels and filters; then test guided selection for decisions that remain difficult. Keep a control period or comparable segment where practical, and annotate promotions, stock events and campaign changes that could distort interpretation.

The review should combine behaviour and outcome. Look at no-result and no-click queries, result clicks, filter use, exits, product views, add-to-cart or qualified enquiry, and customer-service evidence. A movement in one measure is a diagnostic signal, not proof of causation. Confirm whether the change helped customers find a suitable product with less uncertainty and created an operating model the merchandising team can maintain.

Govern zero-result and low-confidence journeys

Search quality is visible not only in successful results but in what happens when confidence is low. Define synonyms, suggestions, fallbacks, merchandising rules and reporting for zero-result and misleading-result sessions.

Frequently asked questions

Should every ecommerce website have site search?

Not necessarily. A very small range may be easier to browse. As catalogue size, product specificity and known-item demand grow, search becomes more valuable. Test the customer need.

How many filters should a category have?

There is no universal number. Use the smallest set of reliable attributes that helps customers make the relevant decision. The useful filters can differ by category.

Should filtered pages be indexed by Google?

Some valuable combinations may deserve indexable landing pages. Many do not. Decide from search demand, distinct content, crawl behaviour and platform architecture rather than using one global rule.

Can artificial intelligence fix ecommerce search?

AI can assist language understanding and ranking, but it does not replace authoritative catalogue data, safe relevance controls, evaluation or recovery when uncertain.

Is a product selector the same as search?

No. Search interprets a query. A selector asks structured questions and applies product or compatibility logic. They can complement one another.

Does every discovery problem require a rebuild?

No. Data cleanup, synonyms, navigation changes, category restructuring or selected filter improvements may solve the priority issue. Choose the smallest credible intervention.

How Emote can help

Customers do not need to understand the database. They need to recognise a path, express a need, narrow the choices and trust the result.

Connect navigation, search and filtering to the same customer language and product model. Measure where people get stuck. Govern the catalogue after launch. Then add sophistication only where it solves a demonstrated discovery problem.

If customers struggle to find the right product in your range, book an initial meeting with Emote. We can assess the evidence, data and technical constraints, then recommend the most proportionate next step.