Why On-Site Search Decides Whether Retail Shoppers Buy

A shopper who types into your search box has told you, in their own words, what they want to buy. When the results are wrong or empty, most of them assume you do not stock the item, and they leave. Ecommerce site search deserves the same care as the checkout for that reason.

Below: what shoppers expect from the search box, where the default search on a WordPress store runs out, the features that close the gap, three ways to get them, and the monthly report that tells you whether any of it is working.

What shoppers type, and what they expect back

Read a week of real queries and you will find six kinds:

• exact product names and model numbers,
• categories ("running shoes"),
• attributes ("waterproof jacket size 12"),
• SKUs and part numbers, especially from trade buyers and anyone ordering spares,
• uses and problems ("gift for dad", "squeaky hinge"),
• things that are not products at all ("returns", "delivery times").

Whatever they type, people expect the same things back. Suggestions should appear while they type, ideally with a thumbnail and a price. Spelling should be forgiven. The most relevant items that are in stock should come first, and there should be a way to narrow a long list.

Where default WordPress search runs out

WordPress search is a database text match. For each word in the query it looks for that exact string in the title, the excerpt and the content. On a product, those are the name, the short description and the long description. Simplified, the query looks like this:

WHERE (post_title LIKE '%jacket%' OR post_excerpt LIKE '%jacket%' OR post_content LIKE '%jacket%')
  AND (post_title LIKE '%waterproof%' OR post_excerpt LIKE '%waterproof%' OR post_content LIKE '%waterproof%')

The WooCommerce product search runs the same query limited to products. Several limits follow from that design:

• Every word has to appear somewhere. One typo and the product is gone.
• There are no synonyms, and "shoe" will not find a product that only says "footwear".
• Attributes, custom fields and variation details are not part of the match. Do not assume SKUs are either. Search for one of yours on the storefront and see.
• Results are ordered by where the words matched and then by date. Stock, sales and margin play no part.
• A pattern that starts with a wildcard cannot use an ordinary database index, so the query gets slower as the catalog grows.

For a store with a couple of hundred products and distinctive names, this is enough. Beyond that, the gaps start to cost sales. The WP_Query reference documents the search parameters if you want to see what can be tuned in code.

Typos, plurals and synonyms

Three techniques cover most of what people mistype or phrase differently.

Typo tolerance (fuzzy matching) accepts words that are one or two characters away from an indexed term, so "runing" finds "running". Good engines allow more slack on long words than on short ones.

Stemming reduces words to a root, so "shoes" matches "shoe" and "painted" matches "paint". It is language-specific, which matters for a multilingual store.

Synonyms connect the words your customers use to the words in your catalog: "sofa" and "couch", "trainers" and "sneakers", a brand and its common misspelling. Build the list from your own search log, not from a dictionary. A short list taken from real failed queries does more than a long generic one.

Check formats as well. "10mm" and "10 mm" should match, and so should a part number with and without its hyphens. When the engine is unsure, a "did you mean" line is more honest than silently showing something else.

Filters turn a long list into a short one

A query like "jacket" cannot be answered by ranking alone. The shopper has to narrow it, and filters are how: category, size, color, brand, price, rating, availability. What separates useful filters from decoration:

• Show only the filters that apply to the current results, with a count beside each value.
• Several values inside one filter should widen the list (red or blue). Different filters should narrow it (red, and size 10).
• On a phone, open filters in a panel over the results with a visible count and an apply button.
• Keep the selection in the address, so the back button works and a filtered view can be shared or used as an ad landing page.
• Disable values that would return nothing.

Filters are only as good as the attribute data behind them. "Navy", "navy blue" and "Blue - Navy" become three separate options. Clean the attributes before you pay for a search tool, because no tool fixes that for you.

A zero-result page is a page you design

An empty result should never be a dead end. In order of preference:

1. Retry automatically with looser matching, and say so: "No exact matches. Showing results for a similar term."
2. Offer spelling suggestions and related categories.
3. Show best sellers or recently viewed items.
4. Give a way to ask a person, which matters most for trade buyers and spare parts.

Send service queries such as "returns" or "delivery" to the matching help page instead of an empty product list. And log every query that returns nothing. A search term for something you do not stock, repeated week after week, is free market research for whoever does the buying.

Three ways to get better search

Approach	How it works	Suits	Limits
A search plugin with its own index in your database	Builds a weighted index of titles, SKUs, attributes and custom fields on the same server	Small and mid-sized catalogs	Shares the server with the store, with modest typo tolerance and speed on large catalogs
A self-hosted search engine	A separate service, such as Elasticsearch or OpenSearch, that receives product data whenever it changes	Large catalogs and teams that want full control of ranking	Another server to run, monitor and keep in step
A hosted search service	The vendor runs the index and supplies the search interface or an API	Instant results without operating infrastructure	A recurring fee, vendor limits, and product data held outside your server

Whichever you choose, the same three things decide whether it works in practice. Price and stock changes have to reach the index within minutes, or search will show items that cannot be bought. The store needs a fallback to the built-in search for when the service is unreachable. And someone has to own the ranking rules, including what happens to out-of-stock items.

Read the search log every month

Record four things for each search: the query, the number of results, what was clicked and whether an add to cart followed. Google Analytics 4 collects the search term on its own when the address carries a recognized query parameter, and the s parameter WordPress uses is one of them. The event is view_search_results, as described in Google's enhanced measurement documentation. Result counts need an extra parameter or the reporting built into your search tool.

Then look at four lists:

• The most frequent queries. Run each one yourself. Are the first results what you would want a customer to see?
• The most frequent queries with no results. Each is a missing synonym, a product named differently from how people ask for it, or a gap in the range.
• Queries with results but no clicks. The products exist and the ranking is wrong.
• Searches followed by an exit. These are the expensive ones.

An hour a month is enough. Most fixes are small: a synonym, a renamed product, a redirect to a help page.

When a plugin is enough and when to build

A catalog of a few thousand products with clean attributes is usually well served by a search plugin and a maintained synonym list, and a store manager can run both. It becomes a development project when you connect an external engine and have to keep its index current, when ranking should follow stock or margin, when trade customers must see their own prices in results, or when the store runs in several languages. That is typical of the eCommerce and retail projects we work on, usually as part of WooCommerce development. If search and filters are slow more than inaccurate, start with performance optimization and with the queries behind them.

Search brings the shopper to the right product. What happens next is covered in the anatomy of a product page that sells.

Frequently asked questions

Does a small store need a dedicated search engine?

Usually not. With a few hundred products, clear names and a handful of synonyms, a search plugin that indexes SKUs and attributes is enough. A separate engine pays off when the catalog is large, queries are varied, or instant suggestions matter to your customers.

Should search result pages be indexed by Google?

No. Internal search results create endless thin pages, and WordPress marks its own search results as noindex by default. If many people search for the same thing, build a proper category or landing page for it.

How should search treat out-of-stock products?

Rank them below items that can be bought and label them clearly. Keep them visible if they are coming back, so the shopper can ask for a notification. Remove discontinued items from the index altogether.

Should store search also return blog posts and help pages?

Yes, kept apart from products. Show products first, then a short group of help pages and articles. A shopper who types "returns" or "size guide" is looking for an answer, not for something to add to the cart.