When “No Results” Is Correct: A Triage Decision Tree for Ecommerce Search

A zero-result search is not automatically a search failure. It is a failure only when a shopper’s request should have produced a valid, relevant result in the context they chose.

That distinction changes the first response. Rather than immediately broadening a query or adding a fallback, capture the request as it happened, decide whether a valid match exists, and change the narrowest thing that explains the failure. If no valid match exists, preserve the honest zero and help the shopper choose a next step.

This decision tree is original operational guidance. The platform examples below show why product facts, variant facts, query controls, and final constraints can lead to different diagnoses; they are not a universal architecture or a measured industry standard.

1. The first question is not “how do we avoid zero results?”

The first question is: should a valid result exist for this request under the current constraints?

A non-empty page can still be wrong if it replaces an unavailable requested variant with a loosely related product, ignores a selected filter, or presents an alternative as an exact match. Conversely, a precise no-match state can be the most truthful answer when the catalog and the shopper’s constraints leave no valid candidate.

Use this sequence for each investigated event:

1. Reproduce the request in its original context.
2. Determine whether a valid product or variant should be eligible.
3. If it should, locate the failure path: language, searchable representation, retrieval, or final constraints.
4. Make the smallest reversible change supported by the evidence.
5. Test whether the original request now succeeds and whether the change still protects precision.

The goal is not to eliminate every zero. It is to distinguish an avoidable miss from a correct zero without turning relevance into a result-count exercise.

2. Capture the failed request before changing anything

A query log alone may not preserve the conditions that produced the empty set. Capture enough context to replay the decision before anyone changes a synonym, product record, rule, or fallback.

Table 1. Request reproduction fields and their diagnostic purpose.

Capture item	Why it matters
Raw query and timestamp	Preserves the shopper’s wording and gives the team a point to compare later.
Page or category, locale or market, and eligibility context	Identifies context that can change what is sellable or visible.
Selected filters and their visible state	Distinguishes a broad match from a final, shopper-constrained outcome.
Availability policy and requested option	Prevents a parent product from being mistaken for the requested sellable variant.
Result message and any recovery choices shown	Records whether the shopper received an honest next step rather than an unexplained dead end.

When the platform permits it, compare the broad candidate set with the final filtered outcome. Google’s Retail documentation, for example, distinguishes a canonical catalog view from final business and user filters, and documents cases where a zero may be intended rather than expanded (Google Cloud documentation). That is an example of a useful comparison, not a reason to assume every search stack works the same way.

Do not silently remove an explicit shopper filter to manufacture a result. On Shopify storefronts, separate filters combine with AND logic, while values inside one filter combine with OR logic (Shopify documentation). A filter combination can therefore explain a legitimate zero. If an operator offers a broader view, make the changed constraint visible and leave the choice with the shopper.

3. Gate one: should a valid result exist?

3.1 Product, variant, or availability gap

Start with the catalog reality, not the search configuration. These are different outcomes:

• No valid product exists for the request.
• A parent product exists, but the requested size, color, pack, compatibility, or other variant does not.
• The requested variant exists but is not sellable in the shopper’s current context.
• The relevant fact exists in the source catalog but is absent, stale, or not represented where search can use it.

Do not treat the presence of a parent product as proof that the shopper can buy the requested option. Shopify’s ProductVariant documentation illustrates that options, SKU and barcode data, inventory tracking, and availability-related facts can live at variant level (Shopify ProductVariant reference). The exact fields indexed and the way availability is applied remain implementation-specific.

For the same reason, trace the product or variant fact through its searchable representation. Google’s Retail attribute documentation distinguishes product and variant attributes and documents configuration for searchable and indexable attributes (Google Cloud documentation). It does not establish that another storefront indexes the same fields or applies the same defaults.

A practical gate question is: Could the store honestly fulfill the shopper’s exact request here and now? If the answer is no, do not fix the zero by treating a nearby product as the answer.

3.2 A correct zero

A correct zero means there is no valid match for the request after applicable catalog facts and constraints are considered. It is not a dead end.

Keep the result state honest, then offer recovery that does not mislabel alternatives as matches:

• let the shopper edit the query;
• show an explicit option to change a selected filter or location context;
• offer an adjacent category when it is clearly an alternative;
• clarify availability or variant context where that resolves the ambiguity; or
• provide an assistance path for a request that cannot be fulfilled automatically.

Baymard’s UX research distinguishes a valid no-results state from a dead end and recommends useful recovery routes rather than leaving shoppers stranded (Baymard Institute). The recovery policy above is original editorial guidance: alternatives should remain labelled as alternatives, not be silently promoted to exact results.

4. Gate two: where did a valid request fail?

Once evidence supports that a valid result should exist, classify the failure before choosing a remedy.

4.1 Language and terminology

Ask what relationship the shopper’s term has to the intended product or variant:

• Is this a typo or normalization issue?
• Is it a one-way alternate term that should lead to a canonical product term?
• Is it an exact identifier, such as a part number, that should retain strict handling?
• Is it a category-specific synonym whose meaning changes elsewhere?
• Is it merely related language that should not be mapped at all?

Related terms are not necessarily equivalent terms. Algolia documents regular, one-way, and alternative-correction synonym types, and notes that synonym terms do not have to return identical results (Algolia documentation). Treat that as an example of why mapping direction is a control choice. A broad mapping can recover one zero while making an identifier search or a high-intent term less precise.

4.2 Retrieval and searchable representation

If the shopper’s language is valid, inspect the representation that retrieval can use. Check whether the relevant product or variant fact is:

1. present and populated in the source record;
2. available in the representation supplied to search;
3. configured to be searchable or indexable where appropriate; and
4. eligible under the retrieval or filter configuration used for this request.

Exact identifiers deserve extra care. Google’s attribute documentation uses exact-searchable handling as a precision-oriented configuration option (Google Cloud documentation); it is not a universal default to copy into every engine. The safe question is whether the chosen representation supports the shopper’s intended level of specificity.

4.3 Context and final constraints

A candidate may be relevant in a broad catalog view and invalid in the shopper’s final context. Review, as applicable:

• availability or location;
• customer eligibility or permissions;
• category scope;
• business rules; and
• selected filters.

Google documents applying final filters after its initial search process in its Retail product (Google Cloud documentation). Shopify documents the conjunction of separate storefront filters (Shopify documentation). These are product-specific mechanics, but they support a general diagnostic habit: compare the broad candidate view with the final constraint outcome before deciding a relevance rule is broken.

5. Choose the smallest safe remediation

Choose the narrowest change that addresses the observed evidence and can be tested without hiding a new precision problem.

Table 2. Candidate remediations, precision risks, and required follow-up.

Observed evidence	Smallest candidate remediation	Precision risk to check	Required follow-up
A product or requested variant fact is missing, stale, or inconsistent	Correct the source fact or its propagation path	A repair may expose records that should remain unavailable in a given context	Re-test the original request and its sellability context
A clearly defined term lacks a needed mapping	Add or revise a directional mapping	The added term may mean something different in another category or query	Test the mapped query, the canonical term, and a nearby ambiguous term
A valid fact is not searchable or is configured incorrectly	Repair the searchable representation or relevant configuration	Broadening an identifier field can reduce exactness	Test exact identifiers and general-language queries separately
An explicit constraint removes the last candidate	Improve visible filter or context guidance	Clearing a constraint without consent overrides shopper intent	Keep the original zero; test an opt-in changed-context path
A broader candidate is helpful but not exact	Use controlled expansion or show a labelled alternative	The result can be mistaken for a match	Verify labels, order, and negative cases
No valid match exists	Preserve the zero and offer honest recovery	A fallback can imply availability or equivalence that is not true	Review the recovery path in the original context

Query expansion is not a replacement for this classification. Google’s Retail documentation presents query expansion as a conditional feature and describes configuration that can retain zero results in selected situations (Google Cloud documentation). Algolia likewise documents empty-result and broadening controls that can affect matching and ranking (Algolia documentation). Both examples illustrate a trade-off: increased recall can introduce alternatives that are not exact matches. There is no universal trigger threshold in this decision tree.

6. Prove recovery without losing precision

A result appearing is not proof that the shopper’s request was satisfied. Build a compact regression set around the change:

Test case	What to verify
Original query in the original context	A valid result appears only if one should exist.
Exact identifier or requested variant	Specific requests remain specific.
Approved spelling, abbreviation, or terminology variant	The intended recovery works without unexpected drift.
Negative or ambiguous query	The change does not convert an honest zero into a misleading match.
Relevant filter combinations	Final constraints still behave visibly and predictably.
In-stock and unavailable variants	Availability handling does not substitute a parent or an invalid option.
Human review of the first useful results	The leading results satisfy the request, not just the system’s match rule.

Elasticsearch documents evaluation of typical queries with supplied relevance ratings and a chosen metric (Elastic documentation). That is a platform example for the underlying practice: use representative queries and relevance judgement, rather than relying only on an empty-versus-non-empty count. The exact regression set and evaluation method should fit the catalog, risk, and search architecture.

7. Turn repeated failures into an adaptable operating practice

For recurring events, group the evidence by cause instead of treating every query as an isolated fix. A catalog owner may need to resolve product or variant facts; a merchandising or search owner may need to review terminology or filters; a technical owner may need to inspect representation, indexing, or context rules.

For each decision, retain the failed request, the context, the evidence that a valid match did or did not exist, the chosen remediation or correct-zero policy, and the regression result. Review patterns at a cadence that matches query volume, catalog change rate, and the consequences of a wrong match. This is adaptable operating guidance, not a fixed weekly requirement.

For broader background on identifying and fixing zero-result searches, see Wizzy’s How to Identify & Fix Zero-Result Searches. This article takes a narrower, classification-first approach: decide whether an exact valid match should exist before changing a query rule, filter, or fallback.

The practical standard is simple: preserve a zero when it is the truthful answer, and when it is not, make the smallest change that restores a relevant answer without weakening the shopper’s constraints.