Find out what zero actually means
A page saying “no products” can be the outcome of several different conditions. The query may have no matching item; a size, price or availability filter may exclude otherwise relevant products; the catalogue index may be stale; or the request may have failed. Treating these as one blank state gives the shopper a misleading answer. Start with the state your search service can prove: the entered query, selected filters, total matches before and after filters, and whether the request completed. If the service failed, say that results could not be loaded and provide a retry; do not assert that the shop has no stock. If the unfiltered query has matches, explain which selected constraints removed them and let the customer remove one at a time. If the catalogue truly lacks the requested item, state that plainly and offer related, clearly labelled alternatives. This distinction is more useful than a generic “try again” message because it tells the customer which decision can change the outcome. For a small shop, a basic rule-based state model is often enough to begin. The goal is not to promise that every search becomes a sale; it is to avoid making a genuine buying task look like a dead end.
Keep the shopper's query in view
Show the searched words and keep them editable in the search field. A shopper who typed a model code needs to see whether a character was lost, autocorrected or split. Do not silently replace the query with a broader term and then label unrelated results as exact matches. If you offer a spelling correction, show the proposed term and let the shopper choose it, or plainly say that results are being shown for that revised term. This is especially important when a catalogue contains products with similar specifications but different compatibility. A suggestion to remove a filter is different from a suggestion to change the query; label the two actions separately. Make the page useful on mobile, where the active filters may be hidden in a drawer. Put the reason for zero results beside an obvious control for revising the search. A generic carousel of promoted products may be useful for browsing, but it should not appear under a heading that implies those products satisfy the customer's exact request. Shopify's storefront search documentation shows that result type and unavailable-product choices can affect what is returned. The shop therefore needs to inspect its own search configuration before blaming a customer's wording.
Offer a short ladder of honest next steps
The first recovery action should respond to the observed cause. If filters created the empty state, offer “remove size M” or “show all availability” with the current query retained. If a plausible spelling variant has results, offer that specific search as a selectable suggestion. If the query is too narrow, suggest a less specific product type, but show why it is related. A category link helps when the category actually contains relevant items; a static list of popular categories may be a last browsing route, not a substitute for contextual help. Baymard's mobile ecommerce usability research observed that generic no-results pages and unrelated category lists often left users stuck, while query-related routes gave users a way forward. This research concerns the studied sites and should guide a local test, not be presented as a guaranteed conversion lift for a Hong Kong shop. Keep every suggestion honest about availability. A sold-out item may deserve an explicit “currently unavailable” state or a restock option if the shop truly offers one, rather than disappearing into “no match.” Do not promise restock dates that operations cannot support. The next step should be one tap away, understandable before tapping, and reversible without losing the original query.
Use a concrete search to expose bad suggestions
Consider a shopper searching for a particular kettle model while a “in stock only” filter remains active from an earlier browse. The catalogue contains the correct kettle, but it is temporarily unavailable. A careless page says “no results” and displays unrelated cookware. A better page says that the exact model was found but excluded by the stock filter, offers a clear action to show unavailable items, and distinguishes any alternative kettles from the requested model. If the shop does not sell the model at all, a result for a similar number should not be called an exact match; explain that it is an alternative and show the attributes a buyer must compare, such as capacity, voltage and warranty terms where those values are verified in the product records. If the typed model code has a likely transcription error, offer a proposed corrected query without discarding the original. If the search backend times out, none of these product claims are justified: show a service error and retry instead. This scenario is a useful acceptance test because it separates absence, exclusion, approximation and failure, four outcomes that look superficially like the same empty screen but require different customer actions.
Make the state perceivable and learn from it
If results update without a page reload, the short “no results” status should be available to assistive technology without moving keyboard focus unexpectedly. W3C's explanation of WCAG status messages explicitly uses search completion and zero-result messages as examples. This article's decision is about the recovery route, but the route fails if a shopper cannot tell that search has finished. Keep the revised query control, filter removal buttons and category links reachable by keyboard and labelled with what they do. On the measurement side, record a privacy-conscious event for completed zero-result searches: query category or a safely handled query value, active filters, result count and whether a suggested route was used. Do not assume every logged term represents unmet demand. Misspellings, bot traffic, stale indexes, over-strict filters and unavailable items can all create the same count. Review a small sample with merchandising and customer service, then fix the highest-impact cause you can verify. The local site's search logs are evidence of its own users, while external benchmarks are only design context. A measurement outage should not prevent the shop from fixing an obvious dead end observed in a manual test.
Test the paths before calling the page complete
Build a test set from actual catalogue structure, using synthetic or approved example queries: one exact product in stock, one exact product excluded by a filter, one temporarily unavailable product, one plausible typo, one product not sold, and one simulated service failure. For each, write down the message a customer should see and the action that should lead to a meaningful result. Check both language versions, small screens and a keyboard-only pass. Follow every proposed query and category link to confirm it returns what the label promises. Verify that promotional suggestions are marked as suggestions, not counted as matching results. Recheck after the catalogue taxonomy, search service or filter rules change, because a once-helpful shortcut can later point to an empty category. The decision owner should be able to answer three questions from the page itself: why did this search return nothing, what can the shopper do next, and will that action preserve the original need? If the interface cannot answer those questions truthfully, a visually polished empty state is still unfinished. A small, tested recovery route gives the customer a real choice without pretending the requested product exists.
Give the merchandising team a clear rule
The interface cannot stay honest if the catalogue behind it is poorly maintained. Give the merchandising owner a routine for checking product titles, model identifiers, availability flags, retired listings and category membership after updates. When customer service hears “I searched the exact model on your site and found nothing,” capture the query and the product record, then reproduce the state with the same filters before changing synonyms. Adding a synonym indiscriminately can make a hazardous compatibility mismatch look relevant. A narrower correction may be a missing model code or a stale availability flag. Keep a small log of the change made and retest a few neighbouring queries so the fix does not dilute precise searches. If there is no product that meets the requested specification, customer service should be able to say so and point to a genuinely comparable alternative, with the differences visible. This operational loop connects a good empty-state design to truthful catalogue data and gives the shop a reasoned way to improve it over time.
Before you proceed
- Separate no match, filtered out, unavailable and service failure states.
- Label alternative products and revised queries honestly.
- Test every suggested route in both languages and on mobile.
