---
title: "What to Do With Zero-Result Searches"
canonical: https://supportpages.io/guides/what-to-do-with-zero-result-searches
updated: 2026-08-13
---

You will finish with a weekly routine that converts your help centre's empty search results into a ranked list of things to write, rename or alias. This log is the least ambiguous source in documentation measurement: everywhere else you infer intent from behaviour, and here the reader types it out.

## Before you start

Confirm your search actually stores the query text and not merely a count of searches. Hosted help centres vary on this, and client-side search libraries often log nothing at all, in which case you need to fire an analytics event carrying the query string and the result count.

Check the retention period as well. A log that keeps fourteen days is enough for a weekly routine but not enough to spot seasonal questions, and you will want at least a quarter before ranking anything.

## Steps

1. **Normalise the log before you read it.**
   Lowercase everything, strip punctuation, collapse plurals, and drop single-character queries and stray keystrokes. Raw logs split one real question across a dozen rows and make everything look like long tail.

2. **Sort the cleaned list by frequency and read the top fifty aloud.**
   Reading them as sentences rather than scanning a table is what makes the clusters visible. Several rows that look unrelated in a spreadsheet turn out to be the same question in different words.

3. **Classify each entry by cause, not by topic.**
   There are three: the content does not exist, the content exists under different words, or the search itself is broken - stemming, typo tolerance, an index that skipped a section. The distribution usually surprises people, because the second cause is the largest and the first is the one everybody assumes.

4. **Fix vocabulary first.**
   Add the reader's word as a synonym, alias or keyword on the article that already answers it. This is minutes of work per entry and it resolves the biggest group. Product teams name things internally; readers search for what the thing does.

5. **Verify the search engine on a query you know should match.**
   Search for an exact phrase from the middle of a known article. If that returns nothing, stop the analysis - you have an indexing fault, and the whole log is currently measuring your search configuration rather than your content.

6. **Rank the genuine gaps by frequency multiplied by consequence.**
   A query asked twice about data deletion or SOC 2 outranks one asked two hundred times about where the settings icon lives. Frequency alone will always point you at trivia, because trivial questions are the most common ones.

7. **Write the article using the reader's words in the title and first line.**
   The query that failed is a ready-made title. Keeping the internal name as a secondary mention gets you both.

8. **Also review searches that returned results but got no click.**
   These are silent failures: the reader saw your titles and judged none of them relevant. They never appear in a zero-result report and they represent the same missing answer.

9. **Re-run the same queries a month after each fix.**
   Confirming a query now returns something takes seconds and is the only proof that the work landed.

![Zero-result searches sorted into three outcomes: write the article, fix the wording, or build the feature.](/images/guides/figures/what-to-do-with-zero-result-searches.webp)

*Roughly one in five is a product gap wearing a documentation costume.*

## Common mistakes

**Assuming a zero-result query means missing content.** Most of the time the article exists and is called something else. Writing a new page for a naming problem creates two overlapping articles and makes the original harder to find.

**Sorting by frequency and working down.** The tail is where the expensive questions live: security review questions, migration blockers, billing edge cases. Each appears a handful of times and each may be attached to a deal or a cancellation.

**Failing to de-duplicate before ranking.** Typos, plurals, capitalisation and trailing spaces will split one genuinely popular question into fifteen rows that all look marginal, and the real top entry never surfaces.

**Adding a synonym that resolves to a page which does not answer the question.** This converts a visible failure into an invisible one. The zero-result log stops showing the problem while the reader is still stuck, and now there is no record at all.

**Reading the log once, as a project.** The value is in the cadence. A single audit fixes the backlog that accumulated; a weekly fifteen minutes catches each new feature's vocabulary mismatch in the week it ships.

## When this stops scaling

Manual review holds up to somewhere around a hundred distinct cleaned queries a week. That is roughly a help centre serving tens of thousands of sessions a month. Past that, the frequency-ranked list stops fitting on a screen, the tail becomes unreadable by hand, and the classification step - which is the step that produces the value - is the first thing to get skipped.

There is a second limit that arrives sooner: search logs only capture people who used the search box. Readers who ask an assistant, or who open a ticket without searching, never appear, and that population grows as more people put a question to a chat interface rather than a search field. Capturing both means logging the questions asked of the help centre through any route, ranked, with the article that should have answered each. [SupportPages](https://supportpages.io) keeps that list for the help centres it serves. The routine above is worth doing by hand first though - it takes an afternoon, and it will tell you whether your problem is missing articles or a naming disagreement before you spend money on either.