Design search results that help when nothing matches

A reader searches for “replication lag,” chooses a topic filter and sees nothing. Did the site search all articles? Is the term wrong? Is the catalogue still loading? Or does the topic simply have no matching article? A blank space answers none of those questions. A useful empty state turns the dead end into a clear next step.

Three different kinds of empty#

Before writing a message, identify why the area is empty. These states need different words and different actions:

State	What the reader needs to know	Useful next step
A new topic has no articles yet	The collection really is empty	Browse another topic or return later
A search or filter has no matches	The request completed but matched nothing in the current scope	Change the query, clear a filter or widen the scope
Results failed to load	The site cannot yet say whether matches exist	Retry, and keep the query for that retry

Calling all three “No results” hides a meaningful difference. In particular, an error must not pretend that the full catalogue was searched successfully. The message is part of the interface’s feedback: it tells readers whether their action was understood and what the system knows.

Say what was searched#

Put the result in the first line: “No articles found for ‘replication lag’ in Data.” That tells the reader what happened and which scope applied. If the page searched titles and summaries but not full article text, describe that scope accurately in the search help. If a filter is active, show it near the result message so the reader can see why the set may be narrow.

Use plain language and front-load the useful information. “We couldn’t find a match in Data” is more helpful than a cheerful paragraph that eventually mentions there are no results. Avoid suggesting that the reader made a mistake. The library’s vocabulary may differ from theirs, and an exact phrase may miss an article that answers the same question.

The page should preserve the typed query in the input. That gives the reader an editable starting point and makes it possible to inspect spelling or shorten the phrase. Clearing the input as soon as a search returns zero forces them to reconstruct what they tried.

Offer a short route back#

Show the actions most likely to change the outcome, in that order. If a topic filter is active, “Search all topics” is a strong first action because it removes a visible constraint. “Clear search” is another direct recovery path. A link to browse every topic gives someone who cannot name the exact term a way to explore. If a close synonym is known and genuinely matches existing content, a suggested term can help; invented suggestions simply produce another dead end.

Keep this set small enough to scan. Three clear actions beat a panel of ten unrelated articles. Recommendations can come after the recovery controls, labelled as other reading rather than disguised as search results. The point is to restore a reader’s ability to choose, not to fill the empty space with decoration.

An illustration can make the state warmer, but it cannot carry the explanation or be the only sign that there are no matches. Keep the heading and actions as text. This is where visual hierarchy matters: the status should be visible, and the next action should look actionable.

Keep context through recovery#

When a reader removes a filter, keep the query and search again across the wider set. When they change the query, keep a clearly visible topic filter unless they deliberately clear it. These rules should be predictable and reflected in the result count and URL where practical. A vague “Reset” can erase more context than the reader intended; name the action precisely, such as “Clear topic filter” or “Clear search.”

Make the state accessible when it changes without a page load. Announce the new result count or zero-result message to assistive technology, and keep keyboard focus in a sensible place rather than jumping it to a decorative block. On a page that works without JavaScript, the search route should still return a legible result page or leave a clear path to the full library.

Test the unlikely queries#

Test at least four cases: a typo, a precise phrase that is absent, a valid query narrowed by the wrong topic, and a failed request. Ask someone what they think happened in each case and what they would try next. If they cannot tell a true zero from a failure, rewrite the status. If they cannot find the control that widens the search, move it closer to the message or give it a clearer label.

Then test a successful search, because the recovery path should lead somewhere useful. The matching cards still need clear titles and summaries that let the reader choose. A polished empty state can recover attention; it cannot compensate for a catalogue that makes every real result look the same.

Continue with Jakob’s Law for article discovery to check whether the whole route from search to article matches readers’ expectations.

Questions people also ask

2 QUESTIONS

▸ Should a zero-result page recommend unrelated articles?

Only if the suggestions are clearly labelled as alternatives. Prioritise actions that repair the search, such as editing the query or removing a filter, before unrelated content.

▸ What should a site say when there are no articles in a new section?

Explain that the section has no articles yet and give a useful route to existing topics. Do not call it a search failure or show filter controls that cannot change the result.