Help readers recover from empty search results.

1. Separate no matches from other states

List the situations the search interface can actually encounter: nothing entered yet, a search in progress, results found, no matching results, and a request that failed. Use wording that matches the underlying outcome. Do not tell someone that no content exists when the search service simply could not respond.

ATN suggests giving each state one clear reader-facing message and recording the condition that triggers it. If search covers only a section of the site, identify that scope. A visitor searching the guide catalog should not be led to believe that the same query was checked against every listing, review, and page elsewhere on the website.

2. Keep the search easy to revise

The U.S. Web Design System recommends retaining the original search terms in the search field when displaying results. It also calls for a label that identifies the search field to screen-reader users. These principles make the next attempt easier to understand and perform.

Keep active filters visible beside the result context. An original ATN example is “No guides match your search in Build,” followed by a clear way to remove that section filter. Do not silently broaden the search and then present the new results as though they match the original request. Let the reader see what changed and keep the query editable.

Sources: [1]

3. Offer a few relevant recovery options

Choose options that actually exist: revise the search words, remove a filter, browse a relevant category, or return to the main catalog. Keep the suggestions short enough to act on. A long list of unrelated featured items can obscure the simple task of trying again.

Do not invent a spelling correction or claim that a topic is unavailable forever based on one unsuccessful query. If you provide suggested content, label it as suggestions and use verified internal destinations. ATN recommends testing the recovery links from the empty state itself, because a link that works on the homepage may still be implemented incorrectly inside a search component.

4. Make dynamic updates understandable

W3C’s status-message guidance distinguishes a search-results list from a brief update such as a no-results message. When that message appears without moving focus or refreshing the page, it can be a status update that needs to be available to assistive technology.

Ask the builder to check the actual behavior, including keyboard use and a suitable screen reader, rather than relying only on the visible design. Avoid repeatedly interrupting someone while they are still typing. A message should communicate the completed state at the appropriate moment, and the person should remain able to edit the query and reach the next useful action.

Sources: [2]

5. Verify recovery with a small query set

Choose a known matching query, a deliberately unmatched query, and a query whose results disappear under a restrictive filter. Add a simulated service-failure case when the search architecture has a separate request that can fail.

Record the exact queries and expected outcomes with the implementation notes. This article describes a review workflow; it does not claim that a particular search component has already passed it.