Zero results as a product backlog: what your search logs are telling you
We added Elasticsearch to a 28,000 SKU catalog and assumed the hard part was done. Search works, products show up, response times are fine. A month later I opened the no-results query logs.
340 unique search phrases in a single week. "Nike sneakers size 42" — zero results. "Waterproof jacket men" — zero results. "USB-C hub adapter" — zero results.
Not because those products didn't exist. Because the index had no idea how to find them.
Since then, the no-results log is the first thing I open when reviewing a catalog. Not to fix everything at once. Someone already wrote down exactly what needs doing — your users did it for you.
Why zero results beats any UX survey
When a user searches for something and finds nothing, it's deliberate. They knew what they wanted. They took the time to type it. This isn't an accidental click on a banner or a casual browse through a category. It's a declared intent.
A UX survey, a heat map, a clickstream analysis — these are all interpretations. A zero-results query is a fact. Someone arrived with a specific need and left empty-handed.
On a catalog with 10–30k SKU, you accumulate 200–400 of these facts every week. Each one points at a specific problem. Most teams never look at this data at all.
How to capture zero-results queries in Elasticsearch
Elasticsearch's slow query log isn't what you need here. You need queries that returned total.hits.value == 0.
The straightforward approach is at the application layer. Intercept the search response, check the hit count. If it's zero, write the query, timestamp, and context (category, referrer) to a separate Elasticsearch index or a flat log file.
In a Bitrix + Elasticsearch setup, this goes into the search component before rendering results. The record structure is minimal:
{
"query": "waterproof jacket men",
"timestamp": "2023-06-10T14:32:11Z",
"category_context": "outerwear",
"user_type": "guest"
}On an active catalog, that log produces 500–800 entries per week. After deduplication and aggregation, you're looking at 200–400 unique queries. Enough for a single focused review session.
Three failure classes your logs will reveal
Once you start reading no-results queries, a pattern emerges fast. They fall into three fundamentally different categories.
Vocabulary and synonym gaps
The biggest class by volume. "Nike" written as "Niky," "USB-C" when you've indexed it as "Type-C," "waterproof jacket" when the product is tagged as "Gore-Tex jacket." The user knows the product. They just call it something different than you do.
Elasticsearch synonyms solve this class. But building a synonym dictionary manually is a task that never ends. The no-results log solves it automatically — it tells you exactly what terms people are using that you haven't accounted for.
Catalog structure issues
The second class is harder. "Cat food for urinary health" — zero results. The product exists. But it's in a "cat food" category without a "urinary formula" tag in the Elasticsearch index. The user is searching by attribute; the catalog is organized by brand.
These queries reveal a mismatch between the user's mental model and your catalog structure. Synonyms won't fix this. You either need to add fields to the index or reconsider how product attributes flow into Elasticsearch.
Real inventory gaps
The third class: the product genuinely isn't there. "Brand X sneakers size 48" — that size isn't stocked. "Electric unicycle" — the category doesn't exist at all.
This isn't a search bug. It's a signal for the buyer or the merchandising team. On one project, the top 20 queries in this class over a quarter went directly into the next season's purchasing plan. No market research needed — just reading what people who'd already arrived on the site were asking for.
How we turn the log into a sprint
Every Monday morning. Export the top 50 no-results queries from the previous week, sorted by frequency. Twenty minutes to classify each one by the three types above.
Synonyms go straight into Elasticsearch's synonyms.txt. Usually 5–10 per session, done in 15 minutes.
Structural issues go into the backlog with a note on which field needs to be added or corrected. Prioritized by query frequency.
Inventory gaps go to a separate list for the buying team. It's not our problem to solve, but they need the data.
The whole process takes about an hour a week. Over three months of this routine, the no-results rate dropped from 18% to 7%. Not because we rebuilt the search engine. Because we started reading what it was trying to tell us.
Real queries as your synonym source
The standard approach: give an editor a list of product categories and ask them to write synonyms. It works poorly for one reason — they're guessing what users might call something. No-results logs aren't guesses. Those are what users actually typed, today, and got nothing.
The quality gap is noticeable within weeks. Synonyms from the log address whatever is blocking discovery today. Hand-written dictionaries are guesses about what might block it tomorrow.
On the 28k SKU catalog, six months of log-driven synonym work gave us a dictionary of 380 synonym pairs. About 70% of those we'd never have thought of ourselves.
Measuring whether it's working
The core metric is the no-results rate: zero-result sessions divided by total search sessions. On an uncurated catalog, 15–25% is a typical baseline.
Alongside that, watch conversion for users who searched. As the no-results rate drops, this tends to climb — people searching for something specific come with high intent.
The third number is less dashboard-friendly: what share of last week's top-50 no-results queries resolved this week. It answers the actual question — are we working the list, or are we just watching it.
On the project we ran this on, moving from 18% to 7% over a quarter produced a measurable lift in conversion for the categories where search was used most. No infrastructure rewrite required. Just showing up every Monday.
Setting up Elasticsearch takes a day. Actually reading what it's logging is a months-long habit. The no-results log is where to start.
More on how search affects catalog conversion: Elasticsearch is not a fast database. It's a UX tool. And what actually moves the needle in faceted navigation: Filters that sell.