Category: Guides

Your visitors see “No results found” on your WordPress site more often than you’d like — and you’re not sure why. This is what’s happening and what to do, in order of effort.

Why WordPress search misses so much

WordPress default search runs one MySQL LIKE query against three columns: post_title, post_content and post_excerpt. That’s it. Every non-obvious limitation follows from this:

• All words must appear literally. A user searching “summer dress blue” misses a product titled “light cotton navy sundress” because the words summer, dress and blue are not all in the text.
• Custom fields are invisible. Anything stored in post meta — ACF fields, WooCommerce SKUs, product attributes, custom repeaters — is skipped entirely. If your product’s only distinguishing text is in an attribute, that product will not appear in the results.
• Taxonomies are invisible. Category names, tag names and WooCommerce attribute term names are not part of the search. A user searching “sneakers” will not find products in a category called Sneakers unless the word appears in the description too.
• No stemming, no synonyms. “Running” and “run” are different queries. “Trainers” and “sneakers” are unrelated.
• No cross-language matching. A French visitor typing “robe d’été” finds nothing in your English catalogue, even if the product description means exactly that.
• Public-only, published-only. Draft and private content is hidden, and custom post types are excluded unless you explicitly opt them into search.

None of this is a bug — it’s the intentional, 20-year-old default. The fix depends on which of these limitations is costing you the most.

Step 1 — find out what your users actually search for

Before you install anything, log the searches that return zero results. Two ways:

• Google Analytics 4: the built-in site_search event captures the query. Filter to sessions where the search event fires and a page-view immediately after does not, and you have a proxy for zero-result searches.
• WordPress plugins: several plugins log search queries and result counts to a database table. AI Search does this out of the box (only for searches where its AI tier rescued the query) on its Insights tab; SearchWP has a similar report.

Look at the top 20 zero-result queries. Group them into three buckets:

1. The content exists but not with those words. “Warm jacket” when the product is a “wool overcoat”. Fix: semantic search.
2. The content exists in fields WordPress doesn’t see. Attribute values, ACF fields, SKUs, PDF text. Fix: index more sources.
3. The content doesn’t exist. Nothing you can do at the search layer — a gap in your catalogue or content. Note it for editorial.

Whichever bucket is biggest is the fix you should make first.

Fix for “the content exists but not with those words”

This is where semantic search earns its place. Semantic search converts each product, post or page into a numeric fingerprint of what it means, and matches the user’s query by proximity in meaning. “Warm jacket” finds “wool overcoat” because the two mean similar things.

AI Search installs in two minutes, needs no API key, and covers up to 2,000 pieces of content on the Free plan. It leaves your existing keyword search alone — keyword and exact SKU matches still rank first; AI results are added below them. Nothing about the search form or results template gets touched. Uninstall reverses it in one click.

Try it against your own three worst zero-result queries. If you don’t want to install yet, pick one of your queries and drop it into the live demos to see how the same query behaves on and off the AI layer.

Fix for “the content exists in fields WordPress doesn’t see”

If your top zero-result queries are exact SKUs, model numbers, part references, or ACF field values, semantic search doesn’t help — you need a keyword indexer that reads more than the default columns. Real options:

• Relevanssi (freemium) — the classic. Indexes taxonomies, custom fields and comments, adds stemming, works well for content sites. Free version is genuinely usable.
• SearchWP (paid, from $99/year) — more polished, indexes PDFs and media too, has a granular weighting UI. Best for content-heavy sites where custom fields and documents matter.
• AI Search (free tier) — if the missing content is only in custom fields you control, opt them into the AI Search index from the plugin settings and they’ll be part of both keyword and semantic matching. Doesn’t handle PDFs or media metadata.

These aren’t either/or: Relevanssi or SearchWP can handle the “index more sources” job while AI Search adds the semantic layer on top. See AI Search vs SearchWP for the composition detail.

Fix for “users type in a different language”

WordPress default search has no cross-language matching — a French query never finds an English product. Two options:

• Translate your catalogue with WPML, Polylang or Weglot. Ideal but expensive if the catalogue is large.
• Use semantic search that matches meaning across languages. AI Search does this out of the box on 100+ languages, and the paid Standard plan runs on text-embedding-3-large which is materially better at cross-lingual queries (roughly 10 points better on OpenAI’s MIRACL benchmark, per this post).

The one-hour workflow that catches most zero-results

If you want a concrete plan to work through in an afternoon:

1. Enable site search tracking in Google Analytics (15 minutes).
2. Wait a week; export the top 20 search queries and note which ones returned zero results.
3. Group them into the three buckets above.
4. Fix the biggest bucket first. For most stores and blogs, it’s bucket 1 — semantic gaps — and installing AI Search Free clears it in 2 minutes with no risk to the current setup.
5. Re-check zero-results after 2 weeks. Whatever is left will be much clearer.

What not to do

• Don’t just lower the similarity threshold on whatever search plugin you use. Broader results with more noise usually feel worse than fewer, correct ones.
• Don’t rebuild the search UI first. Fancier autocomplete on top of the same broken engine doesn’t fix zero-results — it just makes them appear faster.
• Don’t install five search plugins. Two well-chosen plugins that compose (one for indexing sources, one for semantic matching) beats a stack.

---

Related: wondering if a Shopify migration is the only fix for weak store search? See our take on Shopify vs WooCommerce search and how to get semantic search on WordPress.

Two OpenAI embedding models, one plugin, one very different search experience. Here is what the difference actually looks like on a store – and why the paid plans are worth the upgrade if you care about precision or sell in more than one language.

Every search starts with a “meaning fingerprint”

When AI Search indexes your store, it converts each product into an embedding – a numeric fingerprint of what the product actually is. When a user searches, their query gets its own fingerprint, and we match by meaning, not just keywords. That is why “summer blue dress” can find your “light cotton navy sundress”.

The quality of those fingerprints depends on the model that generates them. AI Search uses OpenAI’s third-generation embedding models – and the plan you are on decides which one.

The two models, in plain English

text-embedding-3-small (AI Search Free) produces fingerprints with 1,536 dimensions. Think of dimensions as the number of “traits” the model can use to describe a product. It is fast, efficient, and a big step up from keyword search – the model our Free plan runs on, and it is genuinely good.

text-embedding-3-large (AI Search Standard & Pro) produces fingerprints with 3,072 dimensions – twice the descriptive resolution. More dimensions means finer distinctions: “running shoes” vs “trail running shoes” vs “walking sneakers” occupy clearly separated spots in the model’s map of meaning, instead of blurring together.

What the benchmarks say

On OpenAI’s published benchmarks (see the announcement linked below):

• English retrieval (MTEB): small scores ~62.3%, large scores ~64.6%. A solid, consistent gain – every point here is a query that finds the right product instead of a near-miss.
• Multilingual retrieval (MIRACL): small scores ~44.0%, large scores ~54.9%. This is the headline: an improvement of roughly 10+ points in cross-language search quality.

That multilingual gap matters enormously for stores selling across Europe or in more than one language. AI Search supports 100+ languages on every plan – but the large model is dramatically better at matching a Portuguese query to an English product description, a French search to a German product name, and so on. If you run a multilingual store, this single difference is usually worth the upgrade by itself.

Sources: OpenAI’s “New embedding models and API updates” announcement and embeddings documentation – links at the end of this post.

What this looks like in real searches

Concrete examples of where large pulls ahead:

• Nuance: “something warm but breathable for hiking” – small finds jackets; large separates insulated shells from breathable fleece midlayers.
• Cross-lingual: a user types “vestido de verão às flores” on an English-catalog store – large surfaces the floral summer dresses reliably; small is hit-and-miss.
• Technical proximity: “USB-C hub with HDMI 4K 60Hz” – large distinguishes 30Hz vs 60Hz variants that small treats as near-identical.

You can try each of these on the live demo stores, which run the plugin on real catalogs – clothing, books, and electronics.

Why we do not run large on the Free plan

Honest answer: cost. Large embeddings cost roughly 6-7x more to generate than small ones, and every fingerprint is twice the size to store and compare. The Free plan exists so any store can prove that semantic search works on their own catalog – small does that well. Standard and Pro fund the heavier model and the infrastructure behind it, which is also why every plan has a clear embedding limit rather than a vague “unlimited”.

Upgrading re-indexes for you

Fingerprints from the two models are not compatible – you cannot compare a small query fingerprint against a large product fingerprint. So the first thing to do after upgrading is to regenerate the embeddings for your existing catalog on the large model. Right after you paste the activation key in AI Search → General, the plugin shows a one-click Regenerate embeddings card that runs the whole re-indexing in the background – search stays online on the small-model index until the new one is ready, so nothing on your storefront blinks.

The bottom line

• Free (small): real semantic search, great for trying it on your own store. Up to 2,000 embeddings.
• Standard (large): the precise model, a 25,000-embedding index, full taxonomy boosting, a year of search insights. €49/year (or €5.90/month).
• Pro (large): the same precision across up to 10 sites with a 100,000-embedding pooled index and priority support. €129/year (or €14.90/month).

Launch offer: 35% off for your first 6 months, applied automatically at checkout.

---

References

• OpenAI, “New embedding models and API updates” – openai.com/index/new-embedding-models-and-api-updates
• OpenAI embeddings guide – platform.openai.com/docs/guides/embeddings

Related: weighing a Shopify migration for better product search? See our take on Shopify vs WooCommerce search and how to get semantic search on WordPress.

Every zero-result page is a user telling you exactly what they wanted to buy, and your store answering “no”. Let us dissect one real failed search, see precisely where it dies, and what it takes to save it.

The search: “warm jacket for hiking”

This is a real query you can run on our demo store – a small clothing catalog that contains hoodies, tees and accessories. A user typing this has money in hand and a clear need. Watch it fail.

Where does the default search kill it?

WordPress runs one query: find published items whose title or content contains “warm” AND “jacket” AND “hiking”, as literal substrings. Walk through the catalog with that rule and everything dies. The Hoodie with Zipper? Its description says “cozy” and “zip-up” – no “warm”, no “jacket”. Nothing in the store contains “hiking” at all. Three reasonable words, each fatal on its own; together, guaranteed emptiness. The store has a warm zip-up layer a hiker would happily buy. The search just cannot know that.

Why does the user not retry?

Some do – once. Studies of site-search behaviour consistently find that a large share of visitors abandon after a failed search rather than reformulate, and search users convert at a multiple of browsers, so the lost visitor was disproportionately valuable. Worse, the failure is invisible: default WordPress keeps no record of searches that returned nothing, so the store owner never learns which products people wanted. The demand evaporates without a trace.

What saves it without AI?

Honest answer: for this particular query, not much. You could add “warm”, “jacket” and “hiking” to the hoodie’s description – and you should write customer-language descriptions anyway – but you cannot anticipate every phrasing in every language. Keyword tooling (better relevance ranking, OR-matching, typo tolerance) softens the AND-rule brutality but still cannot bridge “jacket” to a product that never uses the word.

What does AI do differently?

Semantic search compares meanings, not letters (we explain the mechanics in plain English here). “Warm jacket for hiking” and “cozy zip-up hoodie” produce nearby meaning-fingerprints, so the hoodie surfaces – on the demo store it is the first AI result for exactly this query. And because AI Search only ever appends AI results below exact and keyword matches, rescuing this dead search costs nothing on the searches that already worked.

The takeaway

Zero-result pages are not a search-engine curiosity; they are your highest-intent traffic hitting a wall you cannot see. Fix the visible part with better product copy. Fix the invisible part with search that understands meaning – and test it with the weirdest, most human query you can think of, because that is what your customers actually type.

Last updated: August 2026.

Semantic search sounds like magic and gets explained like mathematics. Here is the middle ground: how AI-powered search actually works on a WordPress or WooCommerce site, in plain English, with no equations and no hand-waving.

What problem is it solving?

Normal search matches letters, not meaning. When a user types “sneakers” and your product is tagged “trainers”, nothing matches – even though any human knows they are the same thing. The same failure happens with descriptions (“warm jacket for hiking”), misremembered names, and other languages. Semantic search exists to close that gap: matching what people mean instead of the exact letters they typed.

What is an embedding?

An embedding is a fingerprint of meaning. An AI model reads a piece of text – a product title plus its description, say – and produces a long list of numbers that captures what the text is about. The crucial property: texts that mean similar things get similar numbers. “Insulated trekking parka” and “warm jacket for hiking” come out close together; “insulated trekking parka” and “strawberry jam” come out far apart. Nobody wrote a rule that parkas are jackets – the model learned it from reading enormous amounts of text.

What happens when someone searches?

Three steps, all in a fraction of a second. First, the search query gets its own fingerprint, made the same way. Second, that fingerprint is compared against the stored fingerprint of every product – the comparison is a simple mathematical closeness score between the two lists of numbers. Third, products whose meaning is close enough to the query’s meaning are returned, best matches first. That closeness cutoff is the “similarity threshold” you may have seen in settings: lower it and vaguer matches get in, raise it and only near-certain matches survive.

Does the AI run on every search? Is it slow?

The expensive part – turning product text into fingerprints – happens once, in the background, when a product is published or updated. At search time, only the query needs a fresh fingerprint; comparing it against stored ones is fast arithmetic on your own server, and results are cached. This is why a semantic search plugin does not slow your storefront down: the heavy lifting was already done before the user arrived.

Why does it work across languages?

Modern embedding models are trained on text in a hundred-plus languages, and they map meaning – not words – into the numbers. “Roupa quente para o inverno” and “warm winter clothing” land in nearly the same place, so a Portuguese query happily finds English product descriptions. No translation step, no per-language configuration.

Where does semantic search fail?

On strings with no meaning. A SKU like B08M5XDKFG is gibberish to a meaning model – it produces a useless fingerprint, and a user pasting that code gets nothing. That is why a serious implementation never relies on semantic matching alone. The way we handle it in AI Search is a strict order: exact SKU and title matches are pinned first, everything your traditional keyword search finds comes next, and semantic results are added after them. Meaning-matching is the extension, never the replacement – you can see the three tiers side by side in our live demo.

The short version

Every product gets a meaning fingerprint, computed once. Every search gets one too, computed live. Close fingerprints become results. Keep exact and keyword matches in front, and you get search that understands users without breaking anything that already worked.

Last updated: August 2026.

A shopper who uses your search box is telling you exactly what they want to buy. When the answer is “no results found” – and the product exists – that is the most preventable lost sale in ecommerce. Here is why it happens on WooCommerce stores, and what actually fixes it.

How does WooCommerce search actually work?

Out of the box, a store search runs WordPress’s default text matching: it looks for your search words as literal substrings of the product title, content and excerpt, and every word must appear. There is no understanding of meaning – “sneakers” will not find a product tagged “trainers”, “couch” will not find your sofas, and a Portuguese query will not match an English description. Product codes are fragile too: the default search does not look inside the SKU field, so a shopper pasting a code from a catalog or an old order often gets nothing.

What do shoppers actually type?

Not your product titles. Real queries look like “gift for someone who loves cooking”, “warm jacket for hiking”, “something flowy for summer”. These long-tail, descriptive searches are where literal keyword matching breaks down – the shopper describes a need, your catalog describes a product, and the words rarely overlap. The stores that win these searches are the ones whose search understands that the two descriptions mean the same thing.

Why are zero-result pages so expensive?

Because search users are your highest-intent visitors. Someone browsing categories is window shopping; someone typing into the search box has a specific purchase in mind. A dead end at that moment does not just lose the sale – it teaches the shopper that your search cannot be trusted, so they stop using it, and you lose every future sale it could have made. On top of that, every failed query is invisible in most analytics setups: the store owner never finds out which products people wanted and could not find.

What can you fix without any plugin?

A few traditional fixes genuinely help: write product titles with the words customers use (not internal naming); fill in attributes and tags, since well-structured data helps every search tool; add the words shoppers use to descriptions, including common synonyms; and check your search results page template shows enough products. Keyword-search plugins like FiboSearch, SearchWP or Relevanssi go further – better relevance ranking, instant dropdowns, searching custom fields. All of this improves keyword matching, and it is worth doing.

Where does semantic search fit?

Keyword fixes cannot close the meaning gap: no amount of tuning makes “trainers” literally match “sneakers”, or Portuguese match English. That is what semantic (AI) search does – it compares the meaning of the query against the meaning of every product, so descriptive and cross-lingual searches finally land. The approach we take with AI Search is deliberately conservative: your traditional keyword results always come first, exact SKU and title matches are pinned to the top, and semantic results are only added after them. Enhancement, not replacement – if a search works today, it keeps working exactly the same, and the searches that returned nothing start returning products.

Where to start

Do the free fixes above first – they help any search. Then try a semantic layer on top: AI Search is free up to 10,000 products, needs no API key, and is reversible in one click. Search for something a shopper would type, in their words, and see what comes back.

Last updated: August 2026.