Someone enters the name of a service, clicks “Search”, and gets a blank screen. Technically, the search is complete. In practice, the conversation with the site has broken off at the very point where the visitor has expressed their interest most clearly. We suggest designing this moment not as a user error, but as a scenario in its own right: what will the person understand, and what will they be able to do next?
First, define exactly where the site searches
A field with a magnifying glass often promises more than it delivers. If it searches only article titles, rather than services, documents, and the full text of pages, make that clear beside the field. “Search the journal” is more precise than a generic “Search” when other content falls outside its scope. For a small site, a well-organised article archive can sometimes be more useful than a complex form that hides its limitations.
Before development, put together a few everyday queries: an exact title, a broad topic, an alternative spelling, and a word that does not appear on the site. Decide which content should appear in each case. This is an editorial agreement, not a promise that an algorithm will work out every possible intention.
Preserve the query and distinguish between different states
After a search, keep the text in the field. The person can then change one word instead of typing everything again. An empty query, loading, no matches, and a technical error each need a different message. “Nothing found” should not disguise an unavailable server: in that situation, we do not yet know whether any results exist.
For searches with filters, show the active restrictions. No items in the selected category does not mean there are none anywhere on the site. Offer a separate “Reset filters” action that does not erase the entered text. This helps the visitor understand exactly what will change when they click.
Offer a few honest routes forward, not a wall of advice
A concise empty state can include the query itself, an explanation of the search scope, and two next steps: rephrase the query or open a topic section. There is no need to show dozens of random cards immediately. If you suggest related topics, label them as recommendations rather than exact matches.
A hypothetical example for a studio: the word “relaunch” returns nothing, but there are sections about website maintenance and updates. You can offer them as an alternative route without replacing the answer or claiming to have found something that does not match the query. Link labels should explain their destination’s content, as we discuss in our article on descriptive links.
An input field is not a complete search engine
MDN describes input type="search" as a field for entering a search query. The input type alone does not create an index or determine how to match words to content. That logic needs to be implemented separately. The field also needs a clear label: an example inside the empty field should not be the only explanation of its purpose.
If results update without reloading the page, a short message stating their number or absence needs to be available to assistive technologies without forcibly moving focus. These are the kinds of messages W3C addresses in its explanation of Success Criterion 4.1.3. This does not mean the entire results list should be announced as a single message.
Test the journey, not just the presence of a magnifying glass
Work through the scenario on a narrow screen and using a keyboard: enter a query, run the search, correct it, reset a filter, open a result, and go back. Make sure buttons do not disappear behind the on-screen keyboard, long titles do not overlap neighbouring elements, and messages do not jump around in front of the reader after every character.
Test queries in the site’s languages separately, and do not hide the boundaries between language sections. Good search does not have to guess everything. Its practical value lies in letting people see the limits of the answer, keep what they have already done, and have a clear next step even when there are no results.