“No results” can mean the catalogue has no suitable item. It can also mean a remembered filter silently excluded every item. The visitor cannot choose the right next step unless the page shows what was searched, which constraints remain active, and which constraint could be relaxed.
Research supports the value of giving people visible ways to refine, while stopping short of proving a universal empty-state design. The publisher abstract of a peer-reviewed Findex experiment with 20 people reports that categories beside web search results helped participants find relevant documents faster and more accurately than a ranked list in that test. An author-posted full paper on advanced biomedical search tools, later published in the Journal of Information Science, describes 14 trained librarians comparing two query builders; one participant could not tell why a form-based query returned zero results and found it easier to revise visible query elements. Those tasks and populations differ from a store catalogue. The practical inference is to keep active constraints visible and easy to revise, then test that inference with your own visitors.
Make the empty state diagnostic
Write the result as a sentence with context: “No workshops match Saturday + under AED 200 + in Dubai.” Keep the applied filters visible. Give one-tap removal for each filter and a clear reset action. If you suggest an alternative, label how it differs: “Three workshops on other days” is more useful than silently showing unrelated items under the original heading. Never make a zero-result page look like a successful search.
If results update without a page reload, announce the count and final state in a status message. W3C's WCAG 2.2 explanation of status messages specifically gives “18 results returned” and “No results returned” as examples that need programmatic exposure when the update does not take focus. W3C's role=status technique shows a way to announce a whole result-count message. Keep keyboard focus on the control the person used; an automatic jump to the results can disorient someone still adjusting filters.
Separate the visitor's filters from the indexable pages
A directory with color, size, location, date, and price filters can produce a huge number of URL combinations. Google's faceted-navigation guidance explains how this can cause overcrawling and slower discovery of useful pages. Decide which filtered views genuinely deserve stable, indexable landing pages; do not make every combination a search target. Individual products or listings still need crawlable links from useful category paths.
Do not use a canonical tag as a substitute for deciding which URLs exist and how crawlers reach them. Google calls it a weaker long-term control than preventing crawl of unwanted facets, and says indexable faceted URLs must be constrained to avoid near-infinite spaces. Its guidance gives different approaches depending on whether filtered views need to appear in Search. Read the full faceted-navigation guidance before applying a rule to a live catalogue. Blocking useful detail pages would create a different problem.
Test two different outcomes
Ask a new visitor to find an item that exists, then use a combination known to return none. Can they see which filter caused the dead end and recover without starting over? Test the same path with a keyboard and screen reader. Separately, inspect the URLs generated by each filter action and the site's crawl reports. A good empty state does not prove the crawl setup is healthy, and a tidy URL policy does not make the search experience usable.
ARCHV can map the result and recovery states in a website or digital product brief. Search infrastructure, catalogue rules, and crawler controls are technical scope items that require separate review. Describe the catalogue, filters, and intended indexable pages in a website estimate; ARCHV's website service page makes functions and technical scope explicit in a proposal.