AI Search: semantic search for WordPress and WooCommerce, as a plugin anyone can install.

Out of the box, WordPress and WooCommerce search run a LIKE '%query%' against titles and content. It works when the visitor types the exact word that appears in the product. It fails on everything else: “summer wedding guest dress” finds nothing in a store full of midi wraps and linen sets; “cozy winter sweater” misses every merino pullover; “trainers” misses a category called Sneakers. The result is an empty page, and an empty search page is a visitor who leaves.

Vector embeddings solve exactly this. Turn each product into a 1,536-number fingerprint of its meaning, do the same with the query, and compare them. The technique is well understood. What stops most WordPress site owners is everything around it: API keys, a vector store, an indexing pipeline, quotas, failure modes, and the fact that none of it survives contact with a shared host and a 5,000-product catalogue unless it is engineered carefully.

So the brief I set myself was narrow: semantic search that a store owner installs from the plugin directory, that goes live without an account or a key, and that never makes the results they already have worse.

The first version replaced WordPress search outright and loaded every published post into memory to score it. On 50 posts it was fine. On 5,000 it was a ten-second page. Worse, it registered with the embedding service inside the constructor, so when the service went down every page load on every site waited on a 20-second timeout. I wrote that one up publicly, because it is the kind of mistake you only make once.

The fixes were not clever: move work off the request, cache results, exit early, batch the network, and measure on a real catalogue instead of a local one. Search went from 3 to 8 seconds to under a second, then to 90 ms, then to under 30 ms once ranking moved to Postgres. Each step came from a real site complaining, not from a benchmark.

The product lesson was bigger. Replacing search was wrong; extending it was right. Once keyword results stayed where they were and AI results were only added below, store owners stopped asking whether the plugin was safe to install, because it was. The similarity threshold moved from a 0 to 1 slider to a 0.5 to 1 range after watching what people actually set. And the search endpoint itself turned out to be a security problem, which became a WordCamp Europe talk and a second plugin.

I would design the three-tier ranking on day one, treat the embedding service as production from the first commit (health checks, timeouts, a status page), and ship the batched, resumable sync before the one-click button. I would also run the first hundred sites’ real queries through an evaluation set before touching the ranking, instead of tuning by feel. None of that is novel. It is the difference between a demo that works and a feature a store can depend on, and it is how I build AI features for clients now.