Why is WooCommerce search so slow?

What actually happens when a shopper searches

Type “hoodie” into a standard WooCommerce search box and WordPress builds a query that looks, in essence, like this:

SELECT * FROM wp_posts
WHERE post_type = 'product'
  AND post_status = 'publish'
  AND (post_title LIKE '%hoodie%'
   OR  post_excerpt LIKE '%hoodie%'
   OR  post_content LIKE '%hoodie%')

Three properties of that query decide everything about how search feels on your store:

• The leading wildcard defeats indexing. A database index can jump straight to entries that start with “hoodie”, but '%hoodie%' asks for the term anywhere in the text — so MySQL has no shortcut and examines the product rows one by one. More products, more rows, more time. Every time.
• It runs on your one server. The same PHP workers and database serving product pages, carts and checkout also serve every search. On a busy day — the day search matters most — search and checkout queue behind each other.
• Plugins multiply the work. The moment you bolt on SKU or attribute searching the query grows JOINs into wp_postmeta — a table that holds dozens of rows per product and can reach millions of rows on a store with variations. The scan gets heavier exactly where the table is biggest.

And there’s a second cost hiding in “live search” plugins that stay on your server: search-as-you-type turns one search into a request per keystroke. Each of those is a fresh PHP boot and a fresh scan. Stores genuinely get slower after installing search plugins that promise the opposite.

Why the usual fixes don’t hold

Each of these is regularly recommended, and each helps less than it promises:

• Bigger hosting. A faster server scans the same tables a little faster. You’ve paid for margin, not for a different query — and the margin erodes as the catalogue grows.
• Caching plugins. Page caches serve repeat views of the same URL, and mostly skip search URLs entirely. Search is the opposite case: every term is new. “runing shoes” has never been cached, and never will be.
• Database cleanup. Removing revisions and orphaned meta trims the tables being scanned — worth doing for general health, but it shaves the scan; it doesn’t change its shape.
• Search plugins that rebuild the index inside WordPress. The honest middle ground: a proper index table beats a LIKE scan. But the index still lives in your database, the queries are still PHP on your hosting, and search-as-you-type still lands every keystroke on your server.

The fix that actually changes the shape

Fast search everywhere else on the web — the big marketplaces, the stores you wish yours felt like — is built the same way: search runs on a search engine, not on the shop’s database. The catalogue is copied into an index built for exactly one job, and the shopper’s browser talks to that index directly.

That single change fixes all three properties at once:

• The query shape changes — a purpose-built index answers “hoodie” without scanning anything, typo-tolerantly, ranked by relevance. Typically in around a tenth of a second.
• Your server leaves the search path entirely — searches add zero load to your hosting, however busy the day, however many keystrokes.
• Growth stops hurting — the index is built for catalogue-scale search in a way a general-purpose database scan never will be.