Zero Results

In one line: a recommender always has something to show, and search can genuinely fail — which makes an empty page a design surface rather than an error state.

Why this has no analogue

A feed with nothing in it is a bug. Search returning nothing can be entirely correct: the user asked for something you do not have.

The difference matters because it means search needs a designed failure path. And an empty result page is the worst possible outcome — the user has told you exactly what they want, they are already engaged, and you have answered "no". They will either reformulate or leave, and reformulation is the good case.

The recovery ladder

Never return zero without descending this first. Each rung is worse than the one above and better than an empty page.

Spelling first, because it is the most common cause and the cheapest fix.

Relaxing constraints is the highest-value rung and the one that most needs care. Dropping the price ceiling is different from dropping the size — one produces results the user might accept, the other produces results that are wrong. Relax the least selective constraint first, and tell the user what you did: "no results under £80 — showing results up to £120". Silent relaxation produces a page of items the user has already excluded, and they cannot tell why.

Dropping terms uses IDF: remove the least informative term first. waterproof hiking boots gore-tex vibram size 11 becomes progressively shorter until something matches, and dropping waterproof costs less than dropping boots.

Semantic-only retrieval distinguishes a vocabulary problem from an absence problem. If dropping to pure vector search finds good matches, the corpus had the thing and the lexical path missed it — and that is a synonym you should add.

Suggesting is the honest floor. If nothing works, offer queries that do return results, drawn from what similar users searched next.

Distinguishing the two causes

A zero-result query has one of two causes and they need opposite responses.

Retrieval failure. The corpus has it and you did not find it — a spelling variant, a synonym gap, a bad analyser, an over-restrictive filter. Fixable in the search system.

Genuine absence. You do not stock it, the document does not exist. Not a search problem at all; a catalogue problem, or a signal to acquire something.

Separating them is straightforward and rarely done: run the failed query against a relaxed retrieval offline and see whether anything reasonable comes back. If yes, it was a retrieval failure and belongs on the search team's backlog. If no, it belongs in a demand report.

The log is a demand signal

The part that makes this a business conversation rather than an engineering one.

Every zero-result query is a customer telling you what they wanted and could not find. Aggregated, the null-query log is direct evidence of unmet demand — repeated searches for something you do not stock are a stocking decision that took no research to discover.

This is worth raising unprompted, because it reframes zero results from a bug to be minimised into a data asset. The metric is the zero-result rate, and the report is the ranked list of null queries by volume.

Measuring the real cost

The zero-result rate understates the problem in both directions.

It undercounts, because a query returning three bad results is as much a failure as one returning none, and it does not appear in the metric at all. The better metric is the unsuccessful search rate: queries with no click, no reformulation to success, and no conversion. That captures near-misses that zero-result counting misses entirely.

And it hides recovery, because a query that returned nothing and was successfully rescued by relaxation is counted as a failure by a naive implementation. Measure zero results after the ladder has run, and separately track how often each rung fired — a rung that fires constantly is telling you about a systematic gap upstream.

The design consequence

Two things follow for the architecture.

The recovery ladder lives between retrieval and the response, not in the client. It needs access to the parsed query, the constraints and the index, and it must be able to re-run retrieval — so it is a server-side loop, and it has a latency budget of its own that a design should account for.

And every rung must be logged with which one fired. That log is simultaneously your quality dashboard, your synonym backlog and your demand report, and none of those are available if the response only records that results were returned.

Next: the ground truth that makes search evaluable.