WooCommerce Product Search and Filtering That Actually Helps Buyers

Visitors who use WooCommerce product search are the best visitors your store has: they arrived knowing what they want, they typed it into a box, and they are waiting for you to show it to them. On the stores I run analytics for, buyers who search convert at three to five times the rate of buyers who browse – a pattern that holds across fashion, spare parts, food and B2B catalogues alike. And yet on most stores the search box is the single most neglected feature on the site: it is the stock WordPress search from 2003, it looks only at titles and descriptions, it does not know what a SKU is, and one typo returns an empty page with “No products were found matching your selection”.

I have rebuilt search and filtering on dozens of WooCommerce stores over the last decade, from 80-product boutiques to catalogues with 40,000 SKUs, and the pattern is always the same: findability upgrades are the cheapest conversion work you can buy. This guide covers the whole ladder honestly – why default search fails, what the upgrade plugins actually add (and what they cost), how to make SKUs and attributes searchable, instant search UX rules, filtering with attributes and facets, the performance traps that take servers down, filter UX for mobile and desktop, when categories beat filters, zero-results pages that rescue the sale, and what search analytics tell you about your merchandising. At the end I give implementation priorities by store size, so you fix the highest-leverage things first.

Table of contents

• Why default WooCommerce search fails buyers
• Search upgrade plugins, honestly compared
• Making SKUs, attributes and custom fields searchable
• Instant search and autocomplete: the UX rules
• Attributes done right: the foundation of filtering
• Faceted filtering: plugins and the performance trap
• Filter UX that buyers actually use
• Category structure vs filters: when to use which
• Zero-results pages that rescue the sale
• Search analytics: what buyers type is merchandising intel
• Implementation priorities by store size
• Frequently asked questions

Why default WooCommerce search fails buyers

Out of the box, WooCommerce hands product search to WordPress core, and WordPress core search was designed for blog posts. It runs a SQL query along the lines of WHERE post_title LIKE '%term%' OR post_content LIKE '%term%' against the posts table. That single fact explains almost every complaint store owners bring me:

• Titles-and-description only. SKUs, global attributes, variation data, brand fields, custom fields, product tags – none of it is searched. A customer typing the exact SKU from your printed catalogue gets nothing.
• No relevance ranking. Results are ordered by date or menu order, not by how well they match. The product whose title exactly matches the query can appear below an accessory that mentions the term once in its description.
• No typo tolerance and no stemming. “Hoody” does not find “hoodie”. “Running shoe” and “running shoes” can return different result sets. One transposed letter and the buyer sees an empty page.
• All words must match. Core search ANDs the terms, so “blue cotton shirt slim” fails if any single word is missing from the title and description, even when the product is exactly right.
• Variations are invisible. Variation SKUs and variation-level data live on child posts that core search never touches. On stores where each size or voltage has its own SKU, that is most of the catalogue.
• It gets slow at scale. A leading-wildcard LIKE '%term%' cannot use an index, so MySQL scans the table. At 500 products nobody notices; at 20,000 products with a busy shop, search queries start stacking up.

None of this is WooCommerce being lazy – core search is a generic tool. But an online shop lives or dies on findability, and “generic” is not good enough for the box your highest-intent buyers are typing into.

Search upgrade plugins, honestly compared

Every serious search plugin fixes the same root problem the same way: instead of scanning titles at query time, it builds an index – a separate table that maps words to products, including SKUs, attributes and custom fields – and searches that. Index lookups are milliseconds instead of seconds, relevance can be scored properly, and what gets searched becomes configurable. The three names that come up on nearly every project:

• Relevanssi – the veteran, with a genuinely useful free version. Adds relevance ranking, fuzzy/partial matching, custom field and taxonomy search, search logging, and “did you mean” suggestions. The premium version adds better WooCommerce handling. Trade-off: its index lives in your database and can get large on big catalogues, and it replaces results on the standard search page rather than giving you a live search box.
• SearchWP – paid only, and the most control per euro. You build “engines” that define exactly what is searched and with what weight: title heavily, SKU exactly, description lightly, ACF fields, taxonomy terms, even text inside attached PDFs (spec sheets are a killer feature for technical shops). Includes search metrics out of the box. Trade-off: no front-end of its own – pair it with a live-search plugin or theme support.
• FiboSearch (formerly AJAX Search for WooCommerce) – the front-end specialist. Its free version already gives you a proper instant-search bar with thumbnails, prices and category suggestions; the Pro version adds SKU and attribute search, its own fast index, synonyms and search analytics. On small and mid-size stores, FiboSearch Pro alone is often the entire fix.

For very large catalogues there is a fourth class: hosted search engines such as Algolia or Typesense, where the index lives on external infrastructure and results return in tens of milliseconds regardless of your server load. Powerful, but you take on a subscription, an integration and an external dependency – I only recommend them past roughly 10,000 products or serious traffic.

My honest rule of thumb: if the complaint is “the search box feels dumb”, start with FiboSearch. If the complaint is “the right products do not come up”, start with SearchWP or Relevanssi. On many stores I install FiboSearch for the front end and let its own index do the work; only complex catalogues need the heavier engines behind it.

Making SKUs, attributes and custom fields searchable

The single most common search failure I get hired to fix is SKU search. Stores that sell parts, components, consumables or anything with a printed catalogue have customers who search by code – and default search ignores codes entirely. What to cover:

• Parent SKUs – the basic case every upgrade plugin handles. Test with an exact SKU and a partial one; buyers often type only the memorable half of a code.
• Variation SKUs – the case that separates good setups from lazy ones. If “TS-100-BL-M” is the SKU of the blue medium variation, a search for it must return the parent product, ideally with that variation pre-selected. FiboSearch Pro and SearchWP both do this when configured; check the box, then actually test it.
• Global attributes – brand, material, colour, compatibility. When attributes are set up as proper taxonomies (next section), search plugins can index the terms, so “Makita 18V” matches products carrying those attribute values even when the title says neither word.
• Custom fields – ACF specs, GTIN/EAN fields, model-compatibility lists (“fits models X200, X250, X300”). SearchWP is the strongest here because each field gets its own weight; a match in “compatible models” can rank higher than a match buried in the long description.

Weighting matters as much as coverage. My standard scheme: exact SKU match first, then title, then attributes and key custom fields, then short description, then long description at a low weight. Without weighting, a term that appears in fifty product descriptions buries the one product that carries it in the title. And re-test after every catalogue import: bulk imports have a habit of writing SKUs into fields the index does not watch, and nobody notices until a customer emails “your search is broken” – which most never do; they just leave.

Instant search and autocomplete: the UX rules

Instant search – results appearing under the box as the buyer types – is not decoration. It shortens the distance between intent and product to a couple of seconds, it corrects the buyer’s course before they hit a dead end, and on mobile it saves a page load on a slow connection. The rules I implement, learned from watching session recordings on client stores:

• Show products, not just text. Thumbnail, name, price, and stock status. A picture confirms “yes, that one” faster than any words. If a product is out of stock, say so in the dropdown rather than after the click.
• Group the suggestions. Products first, then matching categories (“in: Trail running”), then, only if genuinely useful, guides or posts. Categories in the dropdown quietly teach buyers your store structure.
• Be fast or be off. Suggestions should render within about 200 milliseconds of a keystroke. Index-based plugins achieve this; anything that runs live product queries per keystroke will feel sluggish and hammer the server. Debounce input so you are not firing a request per letter.
• Start at two or three characters, highlight the matched part of each result, support arrow-key navigation, and always include a “See all 34 results” row – the dropdown is a shortcut, not the whole answer.
• On mobile, go full-screen. A cramped dropdown over a keyboard is unusable. Tapping the search icon should open a dedicated overlay with a big input and generous result rows.
• Keep the box visible. On a content site, hiding search behind an icon is fine. On a store, an always-visible search field in the header measurably increases usage – and searchers are your best converters, so you want more of them, not fewer.

One caution: instant search responses bypass your page cache by nature, so every suggestion request hits PHP. With an efficient index this is fine; with a badly built AJAX handler it is a self-inflicted load test. If your store already struggles under traffic, fix that first – my speed optimisation service exists for exactly this kind of groundwork.

Attributes done right: the foundation of filtering

Everything in the second half of this guide – filtering, facets, counts – stands on one unglamorous foundation: global attributes. WooCommerce gives you two ways to add attributes to a product, and one of them is a trap:

• Global attributes (Products > Attributes) are real taxonomies. “Colour” is a taxonomy; “Blue” is a term shared by every blue product. Taxonomies can be queried efficiently, get archive pages, power layered-navigation widgets and feed every filtering plugin on the market.
• Custom product attributes (typed free-hand on the product edit screen) are text blobs stored in the product’s meta. They display on the product page and can drive that product’s variations – and that is all. They cannot be filtered on, cannot be counted, and cannot be fixed in bulk.

Stores that grew organically almost always have the trap version: three years of products where colour was typed by hand, so the catalogue contains “Blue”, “blue”, “Navy blue” and “Blau” as four different values. Before installing any filter plugin, do the hygiene work:

• Define the vocabulary once. One “Colour” attribute with a curated term list. One “Size” attribute with terms ordered logically (S, M, L, XL – drag the order; alphabetical size lists look broken).
• Migrate and merge. Convert hand-typed attributes to global terms and merge the duplicates. On big catalogues I script this rather than click through 4,000 products; it is a day of careful work that every later feature depends on.
• Attribute what buyers filter by, not everything you know. Colour, size, brand, material, key spec – yes. Sixteen technical dimensions nobody shops by – product page content, not attributes.
• Keep values buyer-worded. “Fits: iPhone 15” beats an internal compatibility code. Filters speak your customers’ language or they go unused.

This is also where product page quality and findability meet: consistent attributes feed the spec tables and variation pickers I cover in WooCommerce product page optimisation. One data model, several payoffs.

Faceted filtering: plugins and the performance trap

Faceted filtering is the shop-page sidebar (or drawer) where buyers narrow by colour, size, price and brand, with live counts next to each option and results updating without a full reload. Done well it is the browsing equivalent of good search. The tools I actually use: FacetWP (paid, the most robust – it builds its own index table, so counts and combinations stay fast even on large catalogues), JetSmartFilters (fits Elementor-based stores), and the woocommerce-blocks filters in core (basic, but fine for small shops filtering on one or two attributes). Plenty of free filter plugins exist; the question that separates them is always the same – does it query an index, or does it compute facets live?

Here is the performance trap, and I have been called in more than once after it took a store down. Every facet with counts must answer “how many matching products per option, given the filters already applied?”. Computed live, that is a stack of expensive queries – meta and taxonomy joins across the whole catalogue – on every filter click, for every visitor. Three things then go wrong at once:

• Filtered pages defeat the page cache. Each filter combination is a distinct URL or AJAX request, so most of them are cache misses that hit PHP and MySQL directly.
• The combinations are effectively infinite. Six facets with a handful of options each generate tens of thousands of URL combinations. Real buyers use a few; crawlers try to visit all of them, all night.
• The queries are the slow kind. Unindexed meta_query filtering on a large catalogue means table scans measured in seconds. Twenty concurrent scans and the database stops answering the checkout too.

The defences are straightforward: choose an indexed filtering plugin and rebuild its index on a schedule; keep facet counts off attributes you have not converted to global taxonomies; add noindex to filtered URLs and a canonical to the base category so crawlers stop farming combinations; rate-limit aggressive bots; and load-test the shop page with three filters applied before a sale period, not during it. Filtering is one of the classic ways stores fall over under load – the full picture of query cost, object caching and capacity planning is in my guide to scaling WordPress for high traffic.

Filter UX that buyers actually use

A technically fast filter that buyers cannot operate still loses the sale, and most filter UX failures happen on mobile, where most shop traffic is. The rules I apply on every store build:

• Mobile: a bottom drawer, not a squashed sidebar. A “Filter” button on the shop page opens a full-height drawer; options have big tap targets; a sticky button at the bottom reads “Show 43 products” so the buyer knows applying is worth it before they tap.
• Desktop: a sidebar with live counts. Counts (“Blue (12)”) tell buyers what is worth clicking and stop the zero-results click before it happens. Collapse any option list longer than about seven entries behind “Show more”.
• Applied filters as removable chips. Above the product grid: “Blue x”, “Under EUR 50 x”, “Clear all”. Buyers must always see what is narrowing their results and be able to undo one step without starting over. Missing chips are the number one reason session recordings show people abandoning filtered pages – they get stuck in a narrow result set and cannot see why.
• Instant on desktop, apply-button on mobile. Desktop users expect results to update as they tick; on mobile, batching choices behind one “Show results” tap avoids reflowing the page under the buyer’s thumb after every selection.
• Keep filter state in the URL. Back button works, refresh works, and a buyer can send “blue running shoes under 100” to a friend as a link. Plugins that hold state only in JavaScript break all three.
• Offer few facets, ordered by use. Price, size, colour, brand cover most stores. Order facets by how often they are used (your analytics will tell you), and cut the ones nobody touches – every extra facet is UI noise and server load.
• Never dead-end. If a combination yields nothing, say so in the grid area, keep the chips visible, and offer one-tap removal of the last filter. An empty grid with no explanation reads as “shop is broken”.

Category structure vs filters: when to use which

Categories and filters both narrow the catalogue, so store owners often treat them as interchangeable. They are not, and mixing up their jobs hurts both SEO and usability.

• Categories are navigation and landing pages. They appear in the menu, they get indexed by Google, they can carry an intro text targeting a real search term, and they give buyers a mental map of the store. “Running shoes” should be a category because people search Google for running shoes and land there.
• Filters are refinement within a page. Colour, size and price are how a buyer narrows a category to their case. “Blue running shoes size 43” should be a filtered state, not a category – nobody navigates a menu to that, and you do not want a thousand thin category pages.

The practical test I use: if a combination has real external search demand and enough products to fill a page, promote it; otherwise it stays a filter. “Waterproof trail running shoes” with steady search volume and thirty matching products deserves a category (or a curated landing page) with its own title and text. A colour variant of it does not. Two structural rules keep this clean: keep the category tree shallow – two levels is almost always enough, because deep trees force buyers to guess your taxonomy – and never create a category and an attribute for the same concept, or products will be classified inconsistently within a month. Categories carry the broad, wordable intents; attributes carry the dimensions. When the same concept seems to want both (“brand” is the classic case), make it an attribute first, and add a brand landing page only for the brands buyers genuinely search for. This division also keeps your filtered URLs safely noindexed without losing SEO, because everything worth ranking has a real page.

Zero-results pages that rescue the sale

Every store has zero-results searches – typos, products you do not carry, words you do not use. What separates stores is what happens next. The default is a shrug: “No products were found matching your selection.” The buyer, who had money in hand seconds ago, closes the tab. A rescue page does four things:

• Admits it, briefly, and keeps the search box filled and focused so a typo costs one corrected keystroke, not a restart. If your search plugin supports “did you mean” suggestions, this is where they earn their keep.
• Shows something buyable. Bestsellers, current top categories, or – smarter – results for the nearest matching term. An empty page converts at zero; a page of bestsellers converts at something.
• Offers a human exit. One line: “Cannot find it? Tell us what you are looking for” linking to the contact form or chat. On B2B and parts stores this line alone recovers real orders, because the product often exists under a name the buyer did not guess.
• Logs the query. Every zero-results search is recorded for the analytics review below. This is the difference between a dead end and a feedback loop.

The same thinking applies to zero-results filter states: keep the applied-filter chips visible, say “No products match these filters”, and offer one tap to remove the last filter. I treat the zero-results template as a real template with a design pass, not an afterthought in the theme – it is the page your most motivated buyers see at their most frustrated moment.

Search analytics: what buyers type is merchandising intel

Search logs are the cheapest market research your store will ever get: a list of what visitors wanted, in their own words, matched against whether you showed it to them. FiboSearch Pro, SearchWP and Relevanssi all log queries; GA4 can track site search too if you pass the term. What I actually look at with clients, roughly monthly:

• Top searches vs what they return. Search your own top twenty terms and look at the results with a buyer’s eyes. The number one query returning a mediocre first row is the highest-leverage fix in this entire guide.
• Zero-results queries. Three causes, three fixes. Vocabulary mismatch (“trainers” vs “sneakers”, German buyers typing German terms): add synonyms in the search plugin. Typos the engine misses: enable or tune fuzzy matching. Products you genuinely do not stock: that is demand data – a recurring zero-results term is a buying signal your competitors are collecting on.
• Searches from category pages. Buyers who search while standing in a category are telling you its filters or structure failed them. A spike of searches for a term from one category usually means that term deserves a facet or a subcategory.
• Search-to-purchase rate. If searchers convert well below the multiples they should, results relevance is the suspect – re-check weighting before touching anything else.

There is also an AI angle – semantic search that matches intent (“warm jacket for cycling”) rather than keywords – which deserves its own deep-dive post; the honest short version is that it only pays off once everything in this guide is already done. Merchandising decisions coming out of the log review feed directly into the conversion work in my WooCommerce optimisation tips for better sales – the two loops belong together.

Implementation priorities by store size

Not every store needs everything above, and the order matters. Here is how I sequence findability work when a client gives me a budget and a catalogue:

• Small stores (up to ~200 products): Install FiboSearch (free tier is fine to start), tidy your categories to one shallow level, and convert attributes to global ones even if you only filter by two of them. Skip heavy faceting – with 40 products per category, buyers can see the whole page. Budget: half a day plus a possible Pro licence. This alone fixes 80% of findability complaints.
• Mid-size stores (200 to ~2,000 products): Everything above, plus SKU and variation search properly configured and tested, an indexed facet plugin (FacetWP class) on the top categories with three to five facets, applied-filter chips, a designed zero-results page, and monthly search-log reviews. Budget: two to four days of work plus licences. This is the sweet spot where findability work pays back fastest.
• Large stores (2,000+ products or high traffic): Everything above, plus a serious look at hosted search (Algolia or Typesense) for speed at scale, Redis object caching so filter queries stop hammering MySQL, noindex and crawl rules on filtered URLs, load testing of filtered shop pages, and weekly rather than monthly analytics reviews. At this size search and filtering are infrastructure, and the scaling guide linked above applies in full.

The common thread: attribute hygiene and a proper search index come first at every size, because every later feature – facets, counts, analytics, even future AI search – sits on top of them. The most expensive mistake is buying a facet plugin to put on top of messy hand-typed attributes; the second most expensive is enabling six live-computed facets the week before your biggest sale.

Want search and filtering that actually sells?

I set up search, filtering and findability for WooCommerce stores of every size – plugin selection and configuration, attribute clean-ups, custom facet work and the performance groundwork underneath it – as part of my WooCommerce development service, at EUR 15 per hour or a fixed price quoted within 24 hours. Have a look at the portfolio, then tell me what your buyers cannot find – I reply within 24 hours.

Frequently asked questions

How do I improve WooCommerce product search?

Replace the default with an index-based search plugin (FiboSearch, SearchWP or Relevanssi), make SKUs, variations and attributes searchable, add instant results with thumbnails and prices, and review the search log monthly for zero-results queries.

Why is the default WooCommerce search so bad?

It uses WordPress core search, which scans only titles and descriptions with slow LIKE queries – no SKUs, no attributes, no relevance ranking and no typo tolerance. It was built for blogs, not catalogues.

Does WooCommerce search find SKUs?

Not by default, and variation SKUs are invisible to it. Plugins like FiboSearch Pro or SearchWP index parent and variation SKUs so a code search returns the right product.

FiboSearch, SearchWP or Relevanssi – which should I choose?

FiboSearch if you mainly want a fast instant-search bar; SearchWP if you need fine control over what is searched and how it is weighted; Relevanssi if you want a strong free starting point. Many stores need only FiboSearch.

Do product filter plugins slow down a store?

Badly built ones do – live-computed facet counts run heavy queries that bypass caching and can take a server down under load. Choose an indexed plugin (FacetWP class), limit facets, and noindex filtered URLs so crawlers do not hammer them.

How many filters should a shop page have?

Three to five well-chosen facets – typically price, size, colour and brand – ordered by how often buyers use them. Cut facets your analytics show nobody touches.

Are filtered URLs bad for SEO?

Unmanaged, yes – thousands of thin filter combinations waste crawl budget. Add noindex to filtered states, canonical to the base category, and create real category pages for combinations with genuine search demand.