When your store search can't find your own products

Nobody uses a search box casually. Browsing is exploratory; searching is a statement of intent — a product name, a model number, a colour, a size, sometimes a whole shopping list typed as one phrase. That makes search traffic the most valuable segment on the site and the easiest to lose, because the failure is silent. A shopper who gets no results does not file a complaint. They close the tab, and analytics records a session that looks like any other bounce. Baymard Institute's ecommerce search usability research is essentially a catalogue of these silent failures: queries for product types, attributes and model numbers that return nothing on sites which plainly stock the item. The pattern is consistent enough that it is worth assuming your store has some version of it until you have actually checked the logs.

WooCommerce inherits WordPress search, and WordPress search was built for a blog. It matches words in a post title and post body, so a product only surfaces if the shopper happens to use the language in its title or description. SKUs, attributes, variation names, brand taxonomies and category labels live elsewhere and are frequently not searched at all. There is no typo tolerance, so one wrong letter returns zero results. There is no synonym layer, so sneakers and trainers are unrelated as far as the database is concerned. And the query itself is a LIKE '%term%' scan that cannot use an index, so it gets slower exactly as the catalogue gets more valuable — the same load pattern that shows up in general WooCommerce speed work.

• Matches post title and content, not SKUs, attributes or variations
• No typo tolerance: one wrong letter returns an empty page
• No synonyms, so your words and the shopper's words must match exactly
• Unindexed LIKE queries that slow down as the catalogue grows

Retail search is a different job. It starts responding as the shopper types, with suggestions that show products, categories and brands rather than a list of raw keywords. It tolerates misspellings and plurals, accepts that customers and merchandisers use different vocabulary, and reads structured data — attribute, brand, price, category, stock — so a query like 'black waterproof jacket size L' narrows the set instead of failing. Ranking matters as much as matching: an exact SKU should beat a fuzzy description match, items you can ship should outrank items you cannot, and a bestseller should outrank a discontinued colourway. And when there genuinely is nothing, the page should still do work — spelling suggestions, the nearest category, related products — rather than present a dead end that ends the session.

• Suggestions as you type, showing products rather than keywords
• Typo, plural and synonym handling in both directions
• Attribute, brand, price and category awareness inside the query
• Ranking that favours exact matches and items you can actually ship

Before spending on search infrastructure, spend an afternoon with the query log. Recording what shoppers type and what they got back costs almost nothing, and it is the most direct product research a store can do. Zero-result queries fall into three useful piles: things you stock but nobody can find, which is a findability bug; things you do not stock but people keep asking for, which is a buying decision; and things you will never stock, which still tells you how the market reads your positioning. Queries that return results but earn no clicks mean the ranking is wrong. Queries that convert far above average are the ones to promote on landing pages and in campaigns. Most stores also find a vocabulary gap here: customers ask by use case or nickname, the catalogue is named by manufacturer specification.

• Zero results for items you stock: a findability bug to fix
• Zero results for items you don't stock: demand data for buying
• High volume, low click-through: the ranking needs work
• High-converting queries: promote them on pages and in ads

There are three honest options and they suit different stores. A search plugin inside WordPress is the cheapest step up: it indexes attributes and SKUs and adds basic relevance, but it runs on the same server as everything else, so a heavy catalogue and a busy afternoon compete for the same resources. A hosted search service moves the index off your server and provides typo tolerance, synonyms and suggestions that answer in milliseconds; you pay monthly, usually by record count or query volume, and you accept a sync job that has to stay accurate. Building search into the storefront — the approach we take on a Next.js storefront — puts the interface, suggestions and result layout under your control, with either a hosted or self-managed index behind it. The trade is engineering time against subscription cost.

Search work does not move the store. Products, variations, stock levels, prices, categories, attributes and orders stay in WooCommerce, and merchandisers keep editing them in the same admin screens. What changes is what happens after they hit save: product data is projected into an index built for querying rather than for editing, and the storefront reads results from that index instead of asking the database to scan post content. Checkout, payments, tax and shipping plugins are untouched, because search sits well upstream of them. The real obligations are operational — keeping the index in sync when products, prices or stock change, and deciding what must never be searchable: hidden products, drafts, private B2B pricing, retired variations that still exist for order history.

Search is not a feature bolted on beside the catalogue; it is one of three doors into it. A shopper who searches for 'jacket' should land in a result set they can refine with the same product filters they would use on a category page, with the same URL behaviour, so the state is shareable and the back button behaves. Where a query maps cleanly onto a category, sending the shopper to that category is usually better than a generic result list — it is a curated page with copy, internal links and the category page SEO work already done. Treating the three as one system also prevents the common bug where search, filters and category pages each believe a different version of price and stock, which shoppers notice immediately and trust less afterwards.

If your catalogue is a few hundred products across a handful of clear categories, a monthly search subscription is usually the wrong purchase. At that scale most shoppers navigate rather than search, and the queries that do arrive can be handled by a well-configured plugin plus a short list of manual redirects for the terms people actually use. Check the logs first: if search accounts for a small share of sessions and those sessions convert normally, the money is better spent on speed, photography or the category pages carrying most of the traffic. The case for real infrastructure appears when the catalogue is large, variation-heavy or full of technical part numbers — when browsing stops being a realistic way to find anything. If you are unsure which side of that line you sit on, send us the numbers and we will say so plainly.