The WordPress plugin directory is full of "AI search"
plugins. Most don't use AI in the technical sense. They
use keyword matching, sometimes with synonym lookup or an
optional ChatGPT API call layered on top.
For developers evaluating these plugins for client projects
or personal stores, the marketing-vs-reality gap matters.
Knowing what's under the hood determines whether the plugin
will handle the queries your users will actually type.
Here's how to verify any "AI search" plugin's technical
claims yourself.
The architectures behind "AI search"
There are three main approaches:
1. TF-IDF (keyword matching with statistics)
Term Frequency × Inverse Document Frequency. Classic
information retrieval since the 1970s. Words from the
query are matched against indexed product fields (title,
description, tags). Each match is weighted by how often
the word appears in the product vs the catalog overall.
Synonyms and fuzzy matching can be layered on top.
Strengths: fast, deterministic, no LLM calls, low cost.
Limitations: requires keyword overlap between query and
product. Does not understand intent. "Pull-out wall mount"
cannot match "Pull-Down Full Motion TV Mount" unless
explicit synonyms are configured.
2. Vector embeddings (semantic search)
Each product is converted to a mathematical representation
(vector) using an embedding model. The vector captures
meaning, not just words. Queries are embedded the same way.
Similarity is measured by cosine distance between query
vector and product vectors.
Strengths: handles paraphrasing, intent, multiple languages,
natural language queries.
Limitations: requires embedding infrastructure (ChromaDB,
Pinecone, Supabase pgvector). Embedding cost per product
at indexing. Query embedding cost per search.
3. LLM-augmented keyword search
Traditional keyword search with an LLM (usually ChatGPT or
similar) called to enhance the query or rerank results.
The base architecture is keyword. The LLM provides query
expansion or natural language understanding as a layer.
Strengths: better than pure keyword, simpler than full
vector setup.
Limitations: still bottlenecked by keyword matching at the
retrieval stage. LLM costs per query. Latency from API calls.
How to test which architecture a plugin uses
Run these four queries against any "AI search" plugin demo:
Test 1: Out-of-vocabulary intent
Search a product attribute that does not appear in any
product title. For a TV mount store: "pull out from wall"
when products are titled "Pull-Down Full Motion."
Expected behavior:
- Vector embedding semantic search: returns relevant products
- TF-IDF with synonyms: returns relevant products IF synonyms are configured for this exact case
- Pure keyword: returns nothing
Test 2: Multilingual without configuration
Search the same product category in a different language
than your catalog. For an English catalog: "kurtka zimowa
bez futra" (Polish: winter jacket without fur).
Expected behavior:
- Vector embeddings with multilingual model: returns relevant products
- Keyword search without translation plugin: returns nothing
- Keyword search with translation plugin: depends on per-language synonym config
Test 3: Misspellings
Search a product type with a deliberate typo: "moisturiser"
(UK) when catalog uses "moisturizer" (US), or "anty aging"
instead of "anti aging."
Expected behavior:
- Vector embeddings: typically handles minor spelling variations
- TF-IDF with fuzzy matching: handles some variations based on edit distance configuration
- Pure keyword exact-match: returns nothing
Test 4: Abstract intent
Search a problem description rather than a product. For a
skincare store: "dry skin on my elbows" or "something for
tired-looking eyes."
Expected behavior:
- Vector embeddings: bridges intent to product (e.g., body moisturizer for elbows)
- Keyword search: returns nothing unless products literally contain those phrases
If only Test 4 returns no results, the plugin is
keyword-based regardless of marketing language. If Tests
1 through 3 also fail, it is purely keyword matching with
no synonym configuration.
Results from testing 5 popular WordPress AI search plugins
I ran these tests against the major "AI search" plugins in
the directory last weekend. Verified through public
documentation and free tier setup.
FiboSearch
Architecture: keyword matching with fuzzy logic and
synonyms. Optional ChatGPT integration for query enhancement.
Test results: handles Test 3 (misspellings) via fuzzy
matching. Fails Test 1, Test 2, Test 4 without explicit
synonym configuration. The "AI" in marketing refers to the
optional ChatGPT layer.
Verdict: TF-IDF with optional LLM enhancement.
SearchWP
Architecture: keyword indexing with weighted engine
configuration. AI features (semantic, image, suggest) are
paid add-ons calling OpenAI for query refinement.
Test results: similar to FiboSearch. Base retrieval is
keyword. Paid AI add-ons improve query understanding but
do not change the underlying architecture.
Verdict: TF-IDF with paid LLM augmentation.
Relevanssi
Architecture: full-text search with custom weighting,
ranking control, and synonym support.
Test results: handles Test 3 if fuzzy matching is configured.
Fails Tests 1, 2, 4 in default setup.
Verdict: TF-IDF. Documentation explicitly does not claim
AI or semantic search. Honest about being keyword.
AI Vector Search (Semantic)
Architecture: dual mode. Default Lite Mode uses TF-IDF
with synonyms and stopwords. Real vector embeddings
activate only with paid Self-Hosted Supabase mode plus
your own OpenAI API key.
Test results in default Lite Mode: same as FiboSearch
(TF-IDF). Test results in paid vector mode: full semantic
capability.
Verdict: depends on configuration. Default install behaves
as TF-IDF. Marketing claims describe the paid configuration.
Queryra
Architecture (disclosure: my product): vector embeddings
via ChromaDB. Each product indexed with a multilingual
embedding model. Customer queries parsed by an LLM
(gpt-4.1-mini) that extracts semantic intent plus
structured filters (price range, brand, exclude terms).
Query vector compared to product vectors via cosine
similarity.
Test results: passes Tests 1, 2, 3, 4 in default free
tier. No additional configuration required.
Verdict: vector embedding semantic search with LLM intent
parsing. Default install delivers what marketing describes.
What this means for plugin selection
For developers picking an "AI search" plugin for a client
project:
If the use case is small catalogs with predictable customer
queries, TF-IDF plugins (FiboSearch, SearchWP, Relevanssi)
work well and have lower runtime costs.
If customers describe needs in natural language, search
across languages, or use terminology that differs from
catalog vocabulary, true vector embedding semantic search
becomes the requirement. The marketing-vs-reality check is
critical here. A plugin claiming "AI" but using TF-IDF will
not bridge intent to product the way customers expect.
The four-query methodology above lets you verify any
plugin's actual architecture in 15 minutes. Worth doing
before committing to a paid tier or recommending to a
client.
Conclusion
"AI search" is marketing language that covers multiple
technical architectures. TF-IDF with optional LLM layers
is the most common. True vector embedding semantic search
is the rarest.
For WordPress in 2026, the field of plugins delivering
true semantic search out of the box, without requiring
paid add-ons or external infrastructure, is small.
Full methodology, FAQ, and side-by-side test results:
https://queryra.com/blog/which-wordpress-ai-search-plugins-actually-use-semantic-search
Try a live demo (no signup): woo.queryra.com
Top comments (0)