When a guest’s search finds nothing, ask your website provider to show a plain-language no-results message, keep the search words available to edit, and offer a few relevant next steps. Those steps might include browsing the menu, choosing another location, or contacting the restaurant. The page should work on a phone and with a keyboard, too.
Put those requirements in writing before approving the page. A generic “no results” notice may be technically correct, but it gives a hungry guest little reason to stay. The goal is to help the person make a useful next choice without pretending the site found something it did not.
Explain what did not match
The message should say that the search returned no matches and identify the words used. For example: “No results found for ‘mushrom pizza.’ Check the spelling or browse the pizza menu.” Keep the message close to the search box, where the guest is likely to look next.
Ask the provider what the search covers. Does it search menu item names, descriptions, location pages, or only some of those? A guest who searches for an ingredient may expect a different result from someone looking for a restaurant address. The message should reflect the actual scope. If only menu items are searched, “No menu items found” is clearer than “Nothing found on this site.”
Decide who supplies the information behind the search. The owner or menu manager may control item names and descriptions, while the provider controls which fields are searchable and how the page responds. Agree on how menu changes reach the search index and who checks that they appear. A dish missing from search because its description is outdated calls for a different fix from a misspelled query.
Also ask how the site distinguishes a genuine no-match result from a search that could not run. If the search service fails, the page should say there was a problem and offer a way to try again or browse. It should not tell the guest that an item does not exist. Likewise, an empty search field needs a prompt to enter a term, not a no-results message.
Offer relevant menu and location routes
Choose a small number of next steps based on what the guest can actually do. For a menu search, a link to the full menu and a relevant category can help. For a location search, a locations page or the restaurant’s contact details may be more useful. Label links by destination: “Browse pizzas” is more helpful than “Click here.”
Hypothetical example: A two-location restaurant lets guests search its menu after selecting a location. A guest at the downtown location searches for “mushrom pizza” and gets no match. The page keeps the query visible, suggests checking the spelling, and offers “Browse pizzas” and “Change location.” The pizza link opens the downtown menu; the location link lets the guest choose the other restaurant before browsing its menu.
That design avoids suggesting that the other location definitely sells the item. It also keeps the guest’s current location clear. If menus or availability differ, ask whether category links respect the selected location and how the site labels items that cannot currently be ordered. A broad link to the menu is better than a specific recommendation that sends the guest to an unavailable item.
Do not turn the empty page into a long list of promotions. Each extra choice competes with the guest’s original task. A general menu link can serve as a dependable fallback, while one contextual link can shorten the route when the destination is genuinely relevant. If your site connects search to online ordering, ask where each link lands and whether the selected location and order type remain visible.
Contact details can help when the guest is looking for something the site cannot answer. Make sure the phone number or contact page is current, but do not make contacting staff the only recovery route. Many guests would rather correct a typo or scan the menu themselves.
Preserve the query so guests can correct it
Keep the original words in an editable search field after a no-match response. The guest should not have to remember and retype the whole phrase. If the site also repeats the phrase in the message, check that long searches and punctuation display cleanly on a small screen.
Ask what happens when a guest corrects the term and submits again. The new search should replace the old no-results state with the appropriate response. If results appear, the guest should be able to understand that the search succeeded and navigate to them. If there are still no matches, the revised words should remain available for another edit.
Spelling suggestions can be useful, but they need a clear rule. Ask whether the site merely suggests a different term or automatically searches for it, and how the guest can see which words were used. A suggestion should not look like a confirmed menu item. For ingredient or dietary searches, do not infer that a dish meets a guest’s needs from a loose spelling match; send the guest to accurate item details or a contact route.
Privacy matters as well. Ask whether search terms are stored or reported, who can see them, and how long they are kept. Menu searches are useful signals for improving descriptions, but guests may also type personal information into a search box. Agree on a sensible handling approach with your provider and consult a qualified adviser if you need contract or privacy guidance.
Use an acceptance checklist before approval
Give the provider the checklist below and ask them to demonstrate each outcome on the actual site setup. The middle column describes what a guest should experience; the last column identifies an owner decision or question. A provider can use different visual designs and still meet these requirements.
| Check | Accept when | Owner decision or question |
|---|---|---|
| No match | The page states that no items matched and shows the submitted words. | What content does the search cover? |
| Correction | The query remains editable and a revised search can be submitted. | Are spelling suggestions offered, and are they clearly labeled? |
| Next steps | Menu and location links lead to the destinations their labels promise. | Which links fit each search context? |
| Different states | An empty input and a search failure receive messages distinct from no matches. | Who should investigate a recurring failure? |
| Location | The selected location stays clear, and links use it where appropriate. | What happens when a guest changes locations? |
| Keyboard and phone | The message, field, and links are readable and usable without a mouse and on a small screen. | Which devices and browsers will the provider demonstrate? |
For a practical check, use the hypothetical “mushrom pizza” search above as a simulated search on a test site or another safe environment. Confirm the no-match message, edit the query to “mushroom pizza,” and follow the menu and location links. Use test data or browsing-only paths. The simulation must not place an order, charge a card, send a guest message, or dispatch a courier.
Then try the page with only a keyboard. You should be able to reach the search field and each recovery link, see which element has focus, edit the words, and submit the search. Ask the provider how a screen reader is informed when the result changes. On a phone, check that the message wraps, the field remains usable, and links are easy to tap without horizontal scrolling.
A single demonstration cannot cover every menu change, device, or search term. Agree on who owns follow-up checks after menu updates and what happens when a guest reports a problem. If you are comparing providers more broadly, the restaurant website builder comparison offers additional buying questions. Also settle who owns the website domain, so a future move does not leave your restaurant without control of its address.
Use the checklist on your current site, then ask Fleksa about its restaurant website, the search behavior you need, and verified US availability for your setup.
Frequently asked questions
Should a no-results page suggest menu items?
It can suggest a relevant category or item when the destination is accurate for the selected location. Label suggestions clearly and keep a general menu link available; do not imply that a suggested item is an exact match.
Should the site automatically correct a guest’s spelling?
That is a design choice to discuss with the provider. If the site changes the search, it should make the words used clear and allow the guest to edit them. A visible suggestion gives the guest control over whether to use it.
What if a search fails rather than finding no matches?
Show a problem message rather than saying there are no matches. Offer a retry and a dependable route such as the menu, and ask the provider who is responsible for investigating repeated failures.
