About4 min read
Ecommerce Site Search: Read Your No Results Log
People using your search box have told you exactly what they want, which makes them the most likely to buy and the most annoyed when they do not find it. Three free reports will tell you where the loss is.
By Juan Molina
On this page
Site search is the most undervalued surface in a store. The people using it have told you exactly what they want, which makes them the most likely to buy and the most annoyed when they do not find it.
It is also the one place where your store answers a question in your own words rather than the customer's, and the gap between those two vocabularies is where most of the loss happens.
Why searchers matter disproportionately
Somebody typing into a search box has moved from browsing to looking for something specific. They have declared intent. If the result is good they convert at a much higher rate than a browser; if it is empty they usually leave, because a store that does not have what they asked for is done being useful.
Which means search quality is a conversion feature rather than a convenience, and the store's own search log is the highest-signal document you own about demand.
Read your search log before changing anything
Three reports, none of which require a new tool.
Searches with no results. Each one is either a product you do not sell, which is a buying decision, or a product you do sell under a different name, which is a free fix. The second category is usually larger than people expect.
Searches with results and no clicks. Worse than no results, because the store answered confidently and wrongly. Usually a relevance problem or a missing image.
Most frequent searches. If people are repeatedly searching for something that is in your main navigation, your navigation is not working. If they are searching for a category you do not have, that is a category page waiting to be built.
An afternoon with these three lists is worth more than any search product.
The vocabulary problem
Customers do not use your words. They use the manufacturer's name, the old name, the regional name, the abbreviation, or the thing they heard from a friend.
Synonyms are the fix and they are manual and worth it. Build the list from your own no-results log rather than from imagination, because the log tells you what people actually typed. Include common misspellings, and include the terms your industry uses casually but never writes down.
This is unglamorous maintenance that nobody owns, and it is usually the single biggest improvement available in store search.
What a search needs to do beyond matching text
Tolerate typos. A missing letter should still find the product. This is table stakes and plenty of stores still fail it.
Search across attributes, not just titles. Somebody searching for a material, a size, a certification or a compatible model is searching your attribute data, and that only works if the attributes exist on the product record rather than being buried in a description.
Filter the results it returns. A search that returns two hundred items and no way to narrow them has shifted the work back to the customer.
Respect availability. Out-of-stock items ranked above available ones is a self-inflicted wound. Rank them down rather than hiding them, because a customer who wants the unavailable thing still wants to know you carry it.
Suggest as they type. Autocomplete shortens the path and, more usefully, steers people toward terms you actually have.
The empty result page is a page, not an error
Most stores treat no results as a dead end. It is a moment where you know exactly what somebody wanted and have their attention.
A useful empty page shows the closest matches you do have, suggests corrected spellings, offers the relevant category, and gives a way to ask a human. What it should not do is say no products found and stop, which is the default in most implementations.
When to buy a search product
Dedicated search services are good and they earn their cost above a certain catalog size, roughly where relevance tuning stops being something a person can do by hand. They bring typo tolerance, synonym management, ranking rules and merchandising controls in an interface.
Below that, database search plus a synonym list plus a good empty-results page covers most of the value, and the money is better spent elsewhere. The deciding factor is catalog size and how much variation there is in how people describe your products, not how many visitors you have.
Where we fit, and where we do not
What a backend contributes is the data search needs: attributes and variants on the record, live stock so availability can affect ranking, and an API that a dedicated search service can index from without an export step, so the index does not drift from the catalog.
Where we are the wrong answer: we do not ship a search product with relevance tuning, merchandising rules and an interface, and at real catalog size that is exactly what you want. If you are on a hosted platform with a search app that works, this is not a reason to move. And no search engine rescues a catalog where the attributes are missing, which is the problem underneath most bad store search.
The short version
Read your no-results log this week and fix the ones you actually sell. Build a synonym list from what people typed. Make the empty page useful. Then decide whether your catalog is big enough to need a real search product, because below that line the list is the whole job.
