Search and filters: why people with money can't find the product

Short answer: someone who uses your catalogue search is the most valuable visitor in the store. They are not "browsing the range", they know what they want to buy. Which is why broken search is the most galling loss of all: you already paid for the visit, you have the product in stock, and the sale died on a typo.

Why WooCommerce's built-in search doesn't work

WordPress's default search is essentially a LIKE query against the post title and content. Everything follows from that:

• A typo means zero results. "Keybord" will not find "keyboard". The visitor concludes you don't stock it.
• Synonyms don't exist. "Sweatshirt" won't find "hoodie", "trainers" won't find "sneakers".
• SKUs often aren't searchable. The SKU lives in a meta field, not in the text — so a part-number query returns nothing.
• There is no meaningful ranking. A product with the query in its title and one that merely mentions it in a description rank the same.
• Attributes and variants don't participate. "Blue running shoes 44" is almost guaranteed to fail.
• On large catalogues it is also slow. LIKE '%word%' can't use indexes; at 20,000 products the delay is noticeable.

This is not a complaint about WooCommerce: the base search is built to be generic for a blog, not for a store. The complaint is that it gets left that way.

What store search must be able to do

Test yours against these seven points:

1. Forgive typos — fuzzy matching for at least one or two mistakes
2. Know synonyms — including your industry jargon and whatever customers actually call the thing
3. Search SKUs and part numbers — in B2B that is half of all queries
4. Suggest as you type — with image, price and stock, so people can jump straight to the product
5. Rank sensibly — a title match beats a description match; in-stock beats back-order
6. Let people filter the results — search without facets is useless on a 200-item result set
7. Never dead-end on zero results — show similar items, popular items, categories, not a blank screen

The implementation depends on catalogue size: up to a couple of thousand products a good search plugin is enough; beyond that a dedicated search engine starts to make sense. But you don't start with the technology choice — you start with the next section.

A free source of ideas: the zero-results report

Log search queries (in GA4 that is the search event with a search_term parameter) and once a month open two lists: the most frequent queries and the queries returning zero results. It is the most underrated report in any store, because it answers three questions at once:

• What you don't stock but people want — a direct hint for range expansion
• What customers call your products — their words, not yours; ready-made titles, tags and synonyms
• What is broken — if "delivery" returns zero results, your information pages aren't part of search

In my experience the first pass through this report produces 5–10 concrete tasks, each cheaper than any ad campaign.

Filters: three standard mistakes

Mistake 1: filtering by the wrong attributes. The store filters by "brand" and "price" while the buyer needs "size", "compatibility" or "delivery time". The right filter set comes from customer questions, not from your database schema.

Mistake 2: no counts and plenty of dead ends. If a filter value doesn't show how many products it will return, people are playing a lottery and keep hitting "nothing found". Show counts and disable values that would return nothing.

Mistake 3: a full page reload per click. Slow, scroll position lost, particularly painful on mobile. It also generates a stream of URLs that end up in the index (see below).

Separately: on mobile, filters belong in a panel with an "Apply" button and a visible reset. A filter that reloads the page after every checkbox doesn't get used on a phone — it gets closed.

Developer note

• Facets can't be honest WHERE queries. Counts per attribute value are aggregate queries that will flatten MySQL on a large catalogue. You need a precomputed index or a dedicated search engine.
• Filters must not breed indexable URLs. Parameter combinations produce thousands of addresses with near-identical content. Base rule: index only meaningful landing combinations (say "category + brand") and handle the rest with noindex, follow or a canonical to the clean category — see Google's guidance on canonical URLs and on robots meta tags.
• Watch crawl budget. On large catalogues the bot burns it on filter combinations instead of new products. How to manage it is in Google's crawl budget documentation. More in ecommerce SEO mistakes.
• Keep search result pages out of the index. Internal search in the index is a classic source of junk pages.
• Log the query together with the result count. Without the second field you can't build the zero-results report.
• Load-test ?s=. Bots and scrapers love hammering search; on LIKE queries that is a ready-made way to take the site down.

Practical check

• Typed a product name with a typo — the product was found
• Searched by SKU — found
• Searched using the word customers actually use — found
• Zero results shows something useful rather than a blank screen
• Search queries are logged in GA4 and I reviewed last month's report
• The filter set matches real customer questions
• Filter values have counts, and empty ones are disabled
• Mobile filters are usable and have a reset button
• Search result pages and junk filter combinations are excluded from indexing

What's next

Search serves the people already inside the store. The next topic is about the ones still outside, and why stores lose them at the search-results stage: ecommerce SEO mistakes.

This topic builds on Baymard Institute's ecommerce search research and on audits of WooCommerce catalogues.