# How to collect feedback when search finds nothing

> When a search returns no results, show a short prompt that asks what the person was looking for and opens the widget with the idea type. Save the query and the result count as metadata, then read the repeated queries each month to find missing content, features or wording problems.

Source: https://escutaproduto.com/resources/feedback-on-empty-search
Last updated: 2026-10-11

## What a zero-result search tells you

A search that returns nothing is one of the clearest signals a product can give. The person typed what they expected to find, and your product did not have it. Sometimes the feature does not exist. Sometimes it exists under a different name, or the article is there but titled in a way nobody would search for. Each reason points to a different fix, and the query text is the only thing that tells them apart.

Most products log these searches, if they log them at all, and then forget them. The better move is to ask the person in the moment what they were looking for. A short prompt on the empty results page turns a dead end into a feature request, a content gap or a naming problem you can act on.

## How to word the zero-result prompt

Show the prompt under the empty results message, not in a pop-up. The visitor has just typed something and is still in the mood to find it, so a small line is enough. Quote their query back to them so they know the prompt is about what they typed.

For example: "Nothing matched "export to spreadsheet". What were you hoping to find?" Put a button under it that says "Tell us what you expected". Do not ask for a rating, and do not ask whether the search was helpful. Those questions measure the search, when the question you need answered is what the person wanted.

If the search is on a page where people already read help articles, link the prompt to your docs as well. A visitor who finds the answer in a help article is not a feedback failure, and you can still record the query for the content team.

## How do you capture the query as metadata?

The widget saves the page URL with each report, but the search query lives on the search page, so you attach it with `setMetadata` before the form opens. Put the query, the result count and an event name in the metadata. The event name separates these reports from the ones people send from other parts of the app.

```js
function showEmptySearchPrompt(query) {
  var trimmed = String(query || "").trim().slice(0, 120);
  if (!window.EscutaProduto || trimmed.length < 2) return;

  window.EscutaProduto.setMetadata({
    event: "zero_result_search",
    searchQuery: trimmed,
    resultCount: 0,
  });
}

document.querySelector("[data-empty-search]").addEventListener("click", function () {
  window.EscutaProduto.open({ kind: "idea" });
});
```

Call the prompt function from your search results code, then render the button with `data-escuta-open="idea"` if you want the visitor to open the form directly. Limiting the query to 120 characters keeps the metadata small and avoids storing long pasted text. Skip queries that look like an email address or a token, because a search box is a common place for people to paste personal data.

## What counts as a feature gap and what counts as a content gap?

Read each repeated query and sort it into one of three buckets. A feature gap is a request for something the product does not do, such as an export to a format you do not support. A content gap is a question your docs or help pages should answer, such as how to change a billing address. A naming gap is a term users expect that your product calls something else. A person who searches for "invoices" when the screen says "receipts" has found a naming gap, and the fix is a label change.

Repeated queries matter more than one-off ones. If one person searches for a phrase once, it may be a typo. If twenty different people search for the same phrase in a month, it is a pattern worth a planning slot.

## How to read the queries each month

1. Open the inbox, filter to the product, and search the message text for the words your prompt copy used, or for the query term you are investigating.
2. Copy the query text into a spreadsheet, one row per report, with the date and the page.
3. Normalize the queries by lowercasing them and grouping the obvious variants, such as "export csv" and "csv export".
4. Count the distinct people behind each group. Ten searches from one person are not the same as ten people searching, so count distinct people where you can.
5. Assign each group to feature, content or naming, and add a short internal note to the matching feedback item with the decision.

The [guide to feature requests and bugs](/resources/feature-request-or-bug) helps you decide which group becomes a feature request and which becomes a bug. The [empty state article](/resources/empty-state-feedback) covers the same idea for screens that have no data yet.

## Acting on the most repeated queries

A repeated feature request should go into the planned queue with the query copied into the note. A repeated content gap should become a help article, and the article should use the exact words people searched, not the words your team prefers. A naming gap usually needs a small label change, plus a redirect in search so the old term still finds the new screen.

Do not treat every empty search as a request to build. Some queries are spam, some are bots, and some are people searching for things that belong on another site. Close those with a note, so the next person who reads the list does not spend time on them again.

## Using Escuta Produto to track empty searches

Create the product, copy its public key, and add the widget to the search results page with the `data-trigger="none"` option if you want the search prompt to be the only way in. The [widget docs](/docs/widget) describe the open function and metadata calls in full. Each report arrives in the inbox with the query in its metadata and the search page URL saved automatically.

For monthly reading, export the inbox to CSV and sort the query column, or search the inbox text for the phrase you are investigating. The [feedback-after-first-success guide](/resources/feedback-after-first-success) explains how to pair search prompts with a good first moment, so a visitor who finds the feature gets a chance to tell you what they expected next.

## Frequently asked questions

### Should a search with no results ask the visitor for feedback?

Yes, with a short prompt under the empty results message that quotes the query. Ask what the person was looking for. Do not ask whether the search was helpful, because that question measures the search instead of finding the gap.

### What should you store about an empty search?

Store the trimmed query, the result count of zero and an event name such as zero_result_search. Keep the query short and skip anything that looks like an email address or a token, because search boxes often receive personal data by mistake.

### How do you tell a missing feature from a missing article?

Sort each repeated query into a feature gap, a content gap or a naming gap. A feature gap asks for something the product does not do, a content gap asks a question docs should answer, and a naming gap uses a word that your interface does not use.