Search on Your Store That Actually Works: Typos, Synonyms, and the Zero-Results Goldmine

Store search works when it forgives typos, understands the words your customers use rather than the words your catalog uses, ranks results by what is likely to sell, and never answers with an empty page. It matters out of all proportion to its size because the people who use it are your most decided visitors: someone typing a product name into your search box has already chosen to buy something and is asking only whether it will be from you. The built-in search on most platforms is word matching against titles, which is why one wrong letter or an unfamiliar synonym returns nothing. Fixing it rarely requires custom software. It requires a real search engine behind the box, clean product data in front of it, and a monthly look at the queries that came back empty.

The short version

• Searchers are your most decided visitors. A query is a declared intent, and a store that answers it badly is turning away the people who arrived ready to pay.
• Default search is word matching, not understanding. Titles and descriptions are scanned for the exact string typed, so typos, plurals, synonyms, and attribute queries fall through.
• Four capabilities separate search that works from search that exists: typo tolerance, a synonym list built from real queries, ranking that knows what is in stock and what sells, and a no-results page that still sells something.
• The zero-results log is free market research. It is a list of things customers asked for, in their own words, that your store failed to answer, and it sorts neatly into vocabulary gaps, catalog gaps, and stock gaps.
• A plugin or hosted service is enough for most stores. Custom search earns its cost only when the catalog has structure a generic engine cannot express: part numbers, compatibility, customer-specific pricing.
• Clean data beats clever algorithms. No engine can find an attribute nobody filled in.

Why does store search matter more than its size suggests?

Greg Linden, one of Amazon's early engineers, has written on the record about the moment the company learned to respect intent. He had built a prototype that recommended items based on what was already in a shopper's cart. A senior marketing executive was firmly against it, worried that anything extra at checkout would distract people from finishing, and Linden was told to stop. He ran a controlled test instead, and the feature won by such a margin that it shipped, an episode he recounted years later in his own account of early Amazon. The lesson that stuck was not about recommendations. It was that a shopper who has revealed what they want is the most valuable person on the site, and serving that revealed intent well beats almost any other optimization.

Your store has a place where intent is revealed in plain text, and it is the search box. Browsing visitors are undecided; they may leave with nothing and were always likely to. A visitor who types "merino base layer medium" has skipped the undecided stage entirely. In nearly every store analytics account we have opened, the segment that used site search converts at a multiple of the segment that did not, and buys more per order. Search is a minority of visits and a disproportionate share of revenue, which makes it the most under-maintained high-value feature in most stores. The search bar gets designed once, by the theme, and never looked at again.

Why does the default search on most stores fail?

Because it is not really search in the sense customers expect. WooCommerce inherits WordPress search, which scans product titles, descriptions, and excerpts for the words typed and returns whatever contains them. That is fine for "blue mug" against a product called Blue Mug. It breaks in all the ways real people type. Shopify's built-in search is more capable out of the box, but with default settings and no synonym work it fails on the same categories of query, just somewhat less often.

• Typos and near-misses. "Sweater" typed as "swaeter" matches nothing, because nothing in the catalog contains that string. On a phone keyboard, a meaningful share of all queries carry at least one wrong letter.
• Synonyms and customer vocabulary. You sell a "hooded fleece pullover"; the customer types "hoodie." You list "sofa"; they search "couch." Industry terms in the catalog and everyday words in the query pass each other without touching.
• Attribute queries. "Red dress medium" describes a variant, but color and size live in attributes or variant options, not the title, so plain search either returns nothing or returns every dress and leaves the filtering to the shopper.
• Part numbers, model numbers, and compatibility. "Filter for WF-2200" is a question about fit, and the answer lives in a compatibility field nobody indexed, if it was ever recorded at all.
• Ranking by the wrong thing. When results do appear, default ordering favors date or an unweighted title match, so a discontinued item from 2019 outranks the bestseller, and out-of-stock products fill the first row.
• The empty page. "No products found" followed by white space is the store equivalent of a clerk shrugging and walking away, with a customer who had cash in hand.

Underneath every one of these is the same limitation: the default engine compares strings, and customers communicate meaning.

What does search that works actually do?

Use this as the checklist when you evaluate what you have or what you are about to install:

• It forgives one or two wrong letters and matches as the shopper types, so "swaet" already shows sweaters.
• It maps customer words to catalog words through a synonym list you control and grow from real queries.
• It indexes every field that carries meaning: SKU, brand, tags, attributes, variant options, and any compatibility or specification data, not only the title.
• It ranks with business signals: in-stock first, sales velocity, margin if you choose, plus manual boosts and pins for the products you want seen this season.
• It offers filters on the results page, so a broad query narrows in two taps instead of a second search.
• It returns results instantly with image, price, and stock state, without a round trip that makes the page feel heavy.
• It never returns nothing. The no-results page offers a corrected spelling, the closest matches, bestsellers, and a way to ask.
• It keeps a log of queries, zero-result queries, clicks, and purchases by query, and shows them to you without a data export.

How do you fix your store's search, step by step?

1. Test it with twenty real queries and score them. Take ten bestsellers with one letter wrong, five phrases lifted from customer emails or chat transcripts, and five attribute or model-number queries. Mark each as found, buried, or missing. This twenty-line sheet is the honest state of your search, and it doubles as your acceptance test later.
2. Find your zero-results log, or start one today. Google Analytics 4 records site searches as an event once the site search setting is enabled, and every dedicated search tool keeps its own report. If neither is running, switch one on before anything else, because every week without it is market research thrown away.
3. Clean the product data before you touch the engine. Add the customer's word to titles where it belongs, fill in the attributes that were left blank, standardize tags, and make sure every product has a SKU and a brand. On Shopify, structured specifications belong in metafields and metaobjects so they can be indexed and filtered. An engine can only find what is there, and this step is the one owners skip because it is unglamorous, which is exactly why it moves the needle most.
4. Choose the engine. On WooCommerce, a dedicated search plugin or a hosted search service adds typo tolerance, attribute indexing, and analytics in an afternoon. On Shopify, the platform's own Search & Discovery app handles synonyms, boosts, and filters for free, and third-party apps or a hosted service take over when the catalog outgrows it. Pick the option whose admin screen you can imagine yourself opening monthly, because the engine you never revisit is no better than the default.
5. Load the synonym list from the log. Do not brainstorm synonyms in a meeting. Take the top zero-result queries, decide which product each one meant, and record the mapping. Twenty entries from real data beat two hundred guesses.
6. Set the ranking rules. In-stock before out-of-stock, always. Then boost by recent sales, pin seasonal priorities, and demote discontinued items rather than deleting them, so old links still land somewhere useful.
7. Build the no-results page as a sales page. Show the closest matches even when confidence is low, show bestsellers from whatever category the query hints at, and add a one-field form that sends the query to your inbox. That form quietly becomes a product-request channel.
8. Put thirty minutes on the calendar each month. Review the top zero-result terms and the top queries with low click-through. Add synonyms, fix titles, adjust boosts, and note any product people keep asking for that you do not carry.

When is built-in enough, when is a plugin enough, and when is it custom?

Built-in search is genuinely fine for a small, simply named catalog, a few dozen products with names customers already know, where most visitors browse collections and search is a courtesy. If that describes your store, spend the afternoon on product photography instead.

A plugin or hosted service is the right answer for the large middle: hundreds to tens of thousands of products, variants, a mixed vocabulary, and a team that can spend a little time each month on synonyms and boosts. This is most stores, and we say so even though it means we are not the ones to hire. The one caution is performance. Instant search that fires a request to a slow server on every keystroke can make the whole site feel sluggish, and a hosted index or a properly cached endpoint solves that, a topic that belongs with everything else in speeding up a slow WooCommerce store.

Custom search earns its place when the catalog has structure that generic relevance cannot represent. Parts and supplies stores where the real query is compatibility, "fits my 2018 model," and the answer depends on a fitment table rather than on words. Wholesale storefronts where results and prices must differ by customer. Headless storefronts where the search box is your own code from the first line. And the newer category: search that should answer a question, "which filter do I need for a 40-gallon tank," where the right tool is an assistant grounded in your catalog and policies, the kind we describe in an AI assistant that knows your store and, for the mechanics, in the retrieval-augmented assistant guide. Even then the honest first move is small. When we scope search work, the first phase is instrumentation plus a proper engine plus a real synonym list, measured against search-led conversion for a month. Only if the log shows queries the engine structurally cannot answer does the second phase, a fitment model or a customer-aware index, get funded, and the evidence for it is already in the report by then.

What is the zero-results report worth?

More than any survey you could commission, because nobody in it was asked to imagine what they might want. Every line is a person who stood in your store, said what they came for, and got nothing. Sorted, the report falls into four piles, and each has its own fix.

• Vocabulary gaps. They asked for a couch; you sell sofas. Fix with a synonym, and consider whether the customer's word belongs in the title itself.
• Catalog gaps. They asked for something you do not carry. When the same request appears month after month, that is demand you have measured for free, and it is the best product-development signal a small store ever gets.
• Stock gaps. They asked for something you carry but had run out of. Show the product anyway with a back-in-stock signup, and let the count of signups tell purchasing how much to reorder.
• Misdirected queries. "Return," "track my order," "discount code." Route these to the help pages with a redirect rule, and note how often they appear; a spike in "return" searches is a product quality signal in disguise.

Keep the report where you will actually see it. A search analytics screen inside the plugin is enough for most owners; a store running several channels may want the zero-results count on the same page as the rest of the morning numbers, the approach in building an internal dashboard your team opens. Either way, it should take less effort to read than to ignore.

Common pitfalls

The failures we see fall into two families: engines installed and abandoned, and data never prepared for them.

A case, details changed. A retailer of replacement parts for household appliances had a catalog titled by manufacturer part number, because that is how the distributor's feed arrived. Their customers did not know part numbers. They searched by the model number printed on the appliance, or by nicknames like "fridge water filter," and the zero-results log, once we switched it on, was dominated by exactly those queries. The engine was not the problem; the data was. The fix was a compatibility field on every product listing the appliance models it fit, indexed alongside the title, plus a synonym list built from the first month of the log. Search-led orders became the largest single slice of revenue within a quarter, from customers who had been arriving all along and leaving empty-handed. The store had been paying for that traffic for years.

The other pitfalls repeat across stores. Ranking that lets out-of-stock and discontinued products crowd the first row, teaching customers that search is where products go to disappoint. A synonym list written once at launch and never touched, so the vocabulary of last year's customers shapes this year's results. An index that falls out of sync, showing yesterday's price or a product deleted last week, which is a trust problem more than a search problem. Boosting margin so aggressively that relevance collapses and the shopper feels steered. Hiding the search box behind an icon on mobile, where most of your queries originate, because the design looked cleaner. And the no-results page that scolds, "please check your spelling," as if the customer failed the store rather than the other way round.

If your log is full of queries you cannot explain, or your catalog has structure no plugin seems to understand, send us a sample of the zero-results report and we will tell you which pile each query belongs in and whether the fix is a synonym list, a data cleanup, or something built.

FAQ

Why does my WooCommerce search not find products?

Because WooCommerce uses the standard WordPress search, which looks for the exact words typed inside product titles and descriptions. It has no typo correction, does not know that a hoodie is a hooded sweatshirt, and cannot see color, size, or other attributes unless they appear in the title text. A search plugin or hosted search service replaces that string matching with an index that tolerates misspellings and covers every product field.

What is the best way to add typo tolerance to store search?

Install an engine built for it rather than trying to patch the default. On WooCommerce that means a dedicated search plugin or a hosted service; on Shopify the platform's own Search & Discovery app and third-party apps handle it. Typo tolerance should match as the shopper types and allow one or two wrong characters, and it should be paired with a synonym list, since misspellings and alternate words are the two halves of the same problem.

How do I see what customers are searching for on my store?

Enable site search tracking in Google Analytics 4, which records each query as an event, or use the analytics screen of your search plugin, which will usually also show queries that returned no results and which results were clicked. If neither is set up, turning one on is the first step, before any engine change, because the query log is what tells you which synonyms and products are missing.

Should search results show out-of-stock products?

Show them, but never first. Hide them entirely and customers conclude you do not carry the item; rank them at the top and customers conclude your search is broken. The working compromise is in-stock products ranked ahead, out-of-stock products shown lower with a clear label and a back-in-stock signup, and discontinued products demoted or redirected to their replacement.

When does store search need custom development?

When the right answer depends on structure a general relevance engine cannot model: compatibility between parts and the models they fit, prices and catalogs that vary by wholesale customer, a headless storefront where search is your own code, or questions that need an assistant grounded in your catalog to answer. For everything short of that, a well-configured plugin or hosted service with a maintained synonym list is the better investment.