DEV Community: Rafał Groń

WordPress Search Plugin Not Working? Your Theme Is Probably Overriding the Results

Rafał Groń — Mon, 20 Jul 2026 13:41:35 +0000

Your AI search plugin is probably working. Your theme is hiding it.

You installed a semantic search plugin. The catalog synced. The dashboard says everything is indexed. Then you type a query into the search box at the top of your store, and you get the same results you got last week: the same keyword matches, the same misses, the same empty page when a customer phrases something naturally.

The obvious conclusion is that the plugin does not work. A lot of people stop there and uninstall.

In most of these cases, the plugin is working fine. It indexed the catalog and it returns good results, and if your plugin exposes its own results view, it will show you exactly that. What is happening is that the search box you are typing into never asks the plugin anything.

This post is about how to tell the difference in about two minutes, and how to fix it.

Quick test: type yourstore.com/?post_type=product&s=blue+summer+dress straight into your address bar. If those results look right but your header search box does not, your theme's own search is intercepting, and the plugin is fine. Full diagnostic below.

It applies to any search plugin, not just ours. This is an ecosystem quirk in how WordPress themes and page builders handle search, and every search plugin on the market runs into it.

Why does my search look the same after installing a search plugin?

A search plugin hooks into the standard WordPress search: the request that happens when someone submits a search form and lands on a URL like yourstore.com/?s=blue+summer+dress. That is the documented, supported path, and it is where a plugin can legitimately step in and replace the results.

The trouble is that a lot of sites do not use that path. Three variants cover almost everything we see.

Why doesn't my header search box use the plugin?

Many premium themes (Woodmart, Flatsome, Astra Pro, Divi and others) include an instant search in the header: you type, and a dropdown of products appears without the page reloading. That overlay is the theme's own feature, running the theme's own query. It is not the standard WordPress search, so the plugin is never consulted. The plugin is sitting there, correctly indexed, waiting for a request that never arrives. This is the variant that fools people most convincingly, because the header box is exactly where you naturally test.

Why are my search results in the wrong order?

Page builders (Elementor, Beaver Builder, Bricks and others) commonly include a search element or a product-results widget. Those widgets often run their own query with their own "Order By" setting (by date, by title, by menu order, by ID). In this case the plugin may actually be involved, and the right set of products may arrive on the page, but the widget throws away the ordering and re-sorts everything. Semantic search earns its value in the order it puts things in, so a re-sorted page looks a lot like a broken engine. The best match is often on the page, just sitting well below weaker ones.

Why do my results look wrong everywhere, even on the plain search URL?

Some custom or heavily-modified templates build their own product loop instead of rendering the query WordPress already prepared. Whatever the plugin returned gets discarded before it is ever displayed.

None of this means your theme is badly built. Theme authors added instant search because it is a genuinely nice feature, and they added it long before AI search plugins existed. The two features simply overlap, and the theme's version never issues the standard WordPress search request at all, so there is nothing for the plugin to answer.

How do I tell if it's the plugin or my theme?

Here is the diagnostic. It takes two minutes and needs no code.

Step 1: Check the plugin's own results first.

Open your search plugin's dashboard and run a test query there, one where meaning matters and keywords do not (something like "something warm for winter walks" rather than a product name). Look at what it returns.

If the plugin returns sensible, meaning-based results, the engine is fine and the index is fine. The problem is downstream, on your site. If the plugin returns nothing or nonsense here, then you have a genuine indexing or sync problem, and that is a different investigation (start with whether the catalog actually finished syncing).

If your plugin has no way to show you its own results for a query, skip to step 2. The URL comparison still works on its own.

Assume from here that step 1 looked good.

Step 2: Bypass the header box entirely.

Type this straight into your browser's address bar, replacing the domain and the query:

yourstore.com/?post_type=product&s=blue+summer+dress

There is also a plain form, which searches the whole site:

yourstore.com/?s=blue+summer+dress

Plain ?s= searches everything on the site, posts and pages too, so if your header box only searches products, use the post_type=product version for a like-for-like comparison.

This is the standard WordPress search URL. Typing it directly skips the header search box, skips any overlay, and goes straight to the path the plugin actually hooks into.

Step 3: Compare the two.

Now read the result:

The direct URL gives good, meaning-based results, but the header box does not. Your theme's own search is intercepting. The plugin works. Go to the first fix below.
The direct URL gives the right products, but in a strange order (relevant items scattered down the page, an obviously perfect match sitting well below weaker ones). Something is re-sorting: a builder widget or a custom template. Go to the second fix.
Both look wrong, but the plugin dashboard in step 1 looked right. A custom results template is probably ignoring the main query. Confirm it before changing anything: temporarily switch to the theme's default search results template and re-run the same search URL. If the results come back correct, the custom template is the culprit. Go to the third fix.
Both look right. Nothing is broken. Test again with a query your old keyword search would have failed on, because if the phrase happens to match product titles, keyword search and semantic search agree and you cannot tell them apart.

That comparison is the whole trick. One URL, typed by hand, separates "the engine is wrong" from "the site is hiding the engine."

How do I stop my theme from overriding search results?

Fix 1: turn off the theme's AJAX/instant search

Many themes that ship an AJAX or instant search expose a toggle for it, usually under theme options or a customizer panel, often labelled something like "AJAX search" or "instant results". Switch it off and the search form falls through to the standard WordPress search, which is exactly where your plugin is listening.

In most cases you keep the same search box in the same place and it simply submits normally instead of opening its own dropdown. Step 4 below is how you confirm it did.

If your theme has no such setting, you are not stuck: the standard search results page still works, so point customers at it. Link the search results page directly, or ask whoever maintains the theme how to make the header form submit normally.

Fix 2: make the page builder widget inherit the main query

Open the widget that renders your search results and look at its Query settings. Set the query source to inherit the main query (builders phrase this as "Current Query", "Inherit", or similar) rather than a custom query you configured. Then clear any hard-coded Order By value, or set it to default.

Either way the ranking is lost: a custom query bypasses what the plugin returned, and a hard-coded Order By re-sorts whatever did arrive. Inheriting the main query with no forced sort avoids both.

Fix 3: fall back to the default search results template

The simplest fix is to fall back to the theme's default search results template and confirm the behaviour there. If the default template shows correct, well-ordered results, you know the custom template is the culprit, and whoever built it can adjust it to render the main query instead of building its own loop.

Step 4: re-run the test. Same query, header box and direct search URL, and check they now agree. Do not skip this. It is the only way to know the fix landed, and it takes ten seconds.

Does this happen with every search plugin?

Yes. Any plugin that improves WordPress search has to hook into the standard search request, and any theme feature that runs its own query instead will bypass it. This is not specific to semantic search, and it is not specific to Queryra. If you switch to a different search plugin without changing the theme setting, you will get the same symptom again with the same explanation.

Which is worth saying plainly, because the usual advice online is "try another plugin", and that advice will cost you an afternoon and leave you exactly where you started.

How can I see what the search engine actually returned?

Queryra is true AI semantic search for WooCommerce and WordPress. It works on meaning and intent rather than keyword matching, reads price and attributes out of plain phrasing (things like "under 40" or "not too heavy"), and handles queries in 100+ languages.

The part that matters for this post is smaller and more boring: for any query, Queryra shows you exactly what it returned, in your dashboard. That is what makes step 1 of the diagnostic possible at all. Once you can see the engine's own answer, you can compare it against what your site displays, and the question stops being "is this plugin any good?" and becomes "which layer changed the answer?" That is a question you can act on.

You can try the search itself on our public demo store at woo.queryra.com. No signup, no gate, just a real catalog and a search box. Type something awkward and conversational into it, the kind of phrase a real customer would use, and see what comes back.

More about the plugin at queryra.com.

Google AI Mode is retraining shoppers to search in sentences. Most WooCommerce search can't handle that.

Rafał Groń — Wed, 15 Jul 2026 12:32:09 +0000

The shift most store owners are treating as an SEO problem

Google AI Mode is rolling out through Summer 2026. Most of the discussion is about discovery: will my products show up inside the AI answers? That matters, but there is a second effect that lands squarely in product and engineering territory, and it is easier to act on because you fully control it.

AI Mode answers a full question directly. A shopper types "a warm waterproof jacket for hiking under £150" and gets a relevant answer, not a page of links. Do that a few times and you stop compressing your intent into two nouns. You start typing the way you actually think.

That behavior does not stay on Google. It changes the input distribution hitting the search box on your own store.

The input your search box is about to receive

For twenty years, on-site search trained users to type like a database: "blue jacket," "face cream," "running shoes." They learned that a full sentence returned nothing, so they adapted to the tool.

AI Mode reverses that training. The queries start to look like this:

"a moisturizer that isn't greasy for oily skin"
"a lightweight day cream under £25"
"krem do twarzy" (on a store listed entirely in English)

Each one carries intent, a constraint, sometimes a negation, sometimes a different language. None of them are keyword queries.

Why keyword search breaks on these

Default WooCommerce search, and most plugins marketed as "AI search," are keyword systems under the hood: token matching, fuzzy matching, synonyms, an inverted index, sometimes a chat wrapper on top. They rank by token overlap between the query and your product text. That model has predictable failure modes once the input is a sentence:

Negation is invisible. "A moisturizer that isn't greasy" contains the token "greasy." Token overlap pushes greasy products up, the exact opposite of the intent. The word "isn't" carries the meaning, and token matching does not model it.

A budget is just more tokens. "A lightweight day cream under £25" contains "under" and "25" as strings to match against product text, not as a numeric constraint on price. Keyword search has no notion that a budget was expressed.

Cross-language means zero overlap. "krem do twarzy" shares no tokens with English descriptions. Token matching returns nothing, even though you stock exactly what was asked for.

Synonym lists help a little, but they widen matching, they do not add understanding. They still cannot read a price out of a sentence or invert a negation.

This is not a chatbot

Worth stating for developers, because the two get conflated. A chat widget is a conversation surface: the shopper types, waits, reads a reply, and clicks through. On-site search is a discovery surface: the shopper types and expects to see products, immediately. The AI Mode habit is about querying, not chatting. The fix for it is better search, not a bot bolted onto the corner of the page.

What "AI-ready" on-site search actually does

The phrase "AI search" has been stretched to cover almost anything, so it helps to define it by behavior. An AI-ready search box needs to:

Understand a full sentence, not just isolated tokens.
Read constraints out of free text: a price like "under £25," attributes like "lightweight" or "for sensitive skin."
Handle negation, so "isn't greasy" removes the wrong products instead of ranking them higher.
Match across languages, so a query in one language finds products described in another.

Mechanically, that comes from a different category than keyword matching: comparing the meaning of the query against products using vector embeddings, plus an intent-parsing step that pulls structured constraints (like a price ceiling) out of the raw text before ranking. You do not need the internals to evaluate it. The behavior is testable from the outside.

A behavior matrix you can hold in your head

Query	Keyword search	Semantic search
"a moisturizer that isn't greasy"	ranks greasy products up (token "greasy")	returns oil-control and matte formulas
"a lightweight day cream under £25"	matches "under"/"25" as words, ignores budget	reads the price, filters to it
"krem do twarzy" (EN store)	no token overlap, no results	matches meaning across languages

The one-minute test

You do not have to trust a label. Run this on any store, whatever search it uses:

Type a full sentence with a use case: "a warm jacket for hiking in the rain."
Type a sentence with a price in plain text: "a lightweight moisturizer under 25."
Type a negation: "a moisturizer that isn't greasy."
If you sell into more than one language, type a query in a second language.

If two or more return nothing useful, the search is keyword-based. That is not a criticism of the store, it is the category the tool belongs to, and it is the category AI Mode is about to make feel broken.

For developers choosing or building search

Two takeaways. First, do not take "AI search" at face value; the label sits on both categories, so test with sentences, constraints, and negations. Second, on-site search is a conversion surface, not a nice-to-have. A shopper who searches is telling you exactly what they want, and a "no results" for a question they would say out loud is wasted intent that never even registers as a failed search. It looks like a normal exit.

Where I'm coming from

I build semantic search for WooCommerce and WordPress (Queryra), so I see this gap daily. Rather than argue it, there is a public demo you can run the test against without signing up, including the cross-language and price cases above:

woo.queryra.com

The full write-up is the canonical source for this post:

queryra.com/blog/google-ai-mode-woocommerce-search

If you are evaluating on-site search for a store right now, run the one-minute test first. It will tell you more than any feature list.

What AI Search for WooCommerce Actually Costs (The Developer's TCO View)

Rafał Groń — Wed, 24 Jun 2026 06:08:05 +0000

If you've priced AI search for a WooCommerce store, you've hit the same two walls everyone does. Half the vendors don't publish a price at all. The other half say "free" — and they mean the plugin is free, not the AI behind it.

This is the developer's version of that breakdown: what each model really costs to operate, where "bring your own key" genuinely wins, and where a flat price earns its premium.

Wall one: no price on the page

A chunk of this category hides pricing behind "contact us." Legitimate for enterprise and usage-based contracts, but for anyone comparing options it means a sales call before you can even budget. Read "contact us" as: negotiated, probably higher, and a time cost to find out.

Wall two: "free" means "bring your own key"

This is the part worth understanding as an engineer, because it's the most common model and the one that looks cheapest on the surface.

A typical free AI search plugin is open on WordPress.org, but to make it work you connect your own OpenAI API key, and sometimes a Pinecone or Supabase instance on top. The plugin generates embeddings and runs queries against services you pay for directly.

Three things move onto your plate:

A metered bill. Embeddings are genuinely cheap to index — for a small catalog you're realistically in single-digit dollars a month, and per-query cost is smaller still. The catch isn't the steady state, it's the variance: a full re-index, a traffic spike, or an LLM call in the query path changes the number, and it's hard to forecast in advance.
The infra. If the plugin needs a vector database, you're now running a Pinecone or Supabase account, picking dimensions, and keeping it in sync. That's real setup, not a toggle.
The operations. Keys rotate, accounts need a card on file (even for free credits), spending limits need watching. The AI backend is now something you maintain.

None of this is hidden maliciously. It's just a cost that lands after install, which is exactly why "free" is a confusing label here.

The honest part: when bring-your-own-key wins

If you're a developer, BYO-key is often the right call, and I'll say it plainly: on raw cost, you can beat any subscription. Small catalog, modest traffic, comfortable with an API key and a usage dashboard — paying OpenAI directly can run you a few dollars a month. You trade a predictable subscription for metered cost and full control, and for a technical owner that's a fair trade.

The trade-off is predictability, effort, and support. You own the setup, you carry the surprise-bill risk, and there's no managed support line at 2am. For a non-technical store owner who wants search to just work, that math flips.

The models, side by side

As of June 2026 (check each vendor's page, these move):

Model	Published price?	Also on you
Free plugin + your OpenAI key (e.g. Mori)	No	Metered OpenAI bill; account + key
Free plugin + OpenAI + vector DB (e.g. OC3)	No	Two metered bills; self-hosted setup
Keyword by default, semantic via your backend (e.g. AI Vector Search)	Managed tier unpriced	Supabase + OpenAI for the real semantic mode
Freemium SaaS, key for real use (AI Search / wp-search.ai)	Free tier yes, premium not listed	Own key once you outgrow the free service
Published hosted SaaS (Motive)	From ~EUR 39/mo	Nothing extra, all-in
Hosting-locked (WP Engine Smart Search)	From ~USD 140/mo	Requires WP Engine hosting
Queryra	14-day trial, then from USD 9.99/mo	Nothing — no key, no per-search bill

Pattern: nearly every "free" true-semantic plugin runs on BYO-key, so its real cost is a metered bill you can't see up front. The flat-price products tend to be the more mature hosted services.

What you're actually buying

"Semantic" means matching on meaning, not exact words. Each item becomes an embedding — a numeric fingerprint of meaning — so "warm waterproof jacket under 100 dollars" can find the right coats even when those words aren't in the titles, and can read the price as a filter. Generating those embeddings and running queries through a model is the part that costs money. Whether that cost reaches you as a metered bill or a flat subscription is the entire pricing question. The search quality can be similar; the billing model is what differs.

Test before you pay

One practical filter that cuts through all of this: can you try the search on real data before you commit? Most plugins gate it behind install, signup, or a sales call. A public demo is a vendor saying "judge the quality yourself, first." Queryra keeps one open — search a live WooCommerce store, no signup. Whatever you pick, prefer the option you can actually test over the one you can only read about.

Where Queryra fits

Disclosure: I build Queryra, so treat this as the contrast, not a neutral verdict.

Queryra runs vector embeddings plus LLM intent parsing, hosted — no OpenAI account, no key, no per-search bill. The AI stack runs on our side; you install, connect once, sync. Pricing is flat and published: a 14-day trial, Starter from $9.99/mo, Pro at $199/mo, Enterprise custom. Current breakdown always on the pricing page.

To be clear: Queryra is not the cheapest. A dev on their own key beats any subscription on raw cost. What it offers is one predictable price with zero AI setup and real support. The price on the page is the price.

The checklist

Is the price published, or "contact us"?
Does it need my own OpenAI / Pinecone / Supabase key?
Flat billing or usage-based?
Actually semantic, or keyword with an AI label?
Tied to a specific host?
Can I test it on real data without a sales call?

Answer those six and the real cost stops being a surprise.

How to verify if a WordPress AI search plugin actually uses AI

Rafał Groń — Mon, 08 Jun 2026 09:53:00 +0000

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

How I Got My WordPress Plugin Into Two Major Page Builders' Official Docs in One Week

Rafał Groń — Mon, 25 May 2026 09:30:49 +0000

I'm a solo developer building Queryra — an AI semantic search plugin for WordPress and WooCommerce. For three months, I was stuck below the visibility wall on WordPress.org. Reviews require active installs. Installs require visibility. Visibility requires reviews. Classic chicken-and-egg.

Then I tried something different — and within a week, my plugin was listed in the official integration documentation of both Oxygen Builder and Breakdance (combined ~600k+ active sites, both owned by Soflyy).

Here's the actual playbook, including the email template I used.

The Distribution Problem (Technical Context)

WordPress.org's plugin search algorithm weights:

Active installs (capped buckets: 10+, 100+, 1k+, etc.)
Review count and recency
readme.txt keyword density
Update frequency

If you have <10 active installs, you're effectively invisible. WP's update_check cron only counts active sites that ping back, which means demo installs and dev environments don't count toward your install threshold.

I had 10+ active installs after weeks of cold outreach. But to break past 50+ (where organic discovery kicks in), I needed a different distribution channel.

The Insight: Page Builder Docs

If you build a WooCommerce store in 2026, you're almost certainly using a page builder — Elementor, Divi, Oxygen, Breakdance, Bricks, or Beaver Builder. Each maintains an integration docs section listing compatible plugins.

Plugin developers focus on WordPress.org, the WooCommerce marketplace, and Product Hunt. Almost none email page builder doc teams. That's the gap.

The Email Template That Worked

Here's the actual structure I sent. Copy and adapt for your own outreach:


text
Subject: [Plugin Name] integration documentation for [Builder Name]

Hi [Name],

I'm a solo developer building [Plugin Name] ([what it does in one line]).
I'd like to propose adding an integration page to your documentation.

**Confirmed compatibility:**
- [Builder Name] [exact version] + [Plugin Name] v[X.Y.Z] — empirically tested
- [Specific features that work]: [list]
- [Specific features not yet supported]: [be honest]

**What gets indexed/integrated on [Builder] sites:**
- [Specific technical details — show you actually tested]

I've drafted a complete integration page formatted for [WordPress editor / their CMS]. 
Includes intro, semantic search explanation, compatibility matrix, setup steps, 
and a support disclaimer protecting your team from third-party plugin issues.

Draft below — you should be able to copy-paste directly. Happy to adjust 
length, tone, or structure to match your editorial preferences.

---

[Full integration doc here, ~600-1000 words, formatted in HTML or markdown 
matching their CMS]

---

Should I prepare the same for [other builder you own]?

Best,
[Your name]
[Link to plugin]

My Plugin Has 20 Installs. ChatGPT Recommends It Over Competitors With 100,000+.

Rafał Groń — Tue, 28 Apr 2026 08:08:09 +0000

Three months ago, I asked ChatGPT: "What's the best WooCommerce search plugin?"

It gave me the usual names. Algolia. Relevanssi. SearchWP. All with 10,000 to 100,000+ active installs. Years of development. Teams behind them.

My plugin — Queryra, an AI search engine for WooCommerce — had about 15 installs at the time. ChatGPT had no idea it existed.

Today, things look different.

What changed

ChatGPT now recommends Queryra when you ask about AI search for WooCommerce. So does Gemini. ProductRank.ai shows Queryra as #1 for "semantic search for WooCommerce" across multiple AI platforms.

Don't take my word for it. Open ChatGPT right now and type: "best semantic search for WooCommerce" — see what comes up.

Or try: "semantic search plugin for WordPress" — and check the results.

I still have under 20 active installs on WordPress.org. The competitors ChatGPT used to recommend exclusively have 100,000+.

No ads. No agency. No budget. One person.

The traffic behaves differently

This is the part I didn't expect.

Users who arrive from ChatGPT don't behave like Google traffic. They don't browse around, read three blog posts, and leave. They arrive with intent already formed — like the buying decision happened inside the AI conversation, before they ever clicked.

They sign up faster. They ask fewer questions. They already know what the plugin does because ChatGPT explained it to them.

One of my users — running an Islamic educational bookstore with 300+ products — told me he found the plugin because AI recommended it in his search queries. He's now one of my most active testers, running hundreds of real searches against his catalogue.

The window is real

I ran some checks on companies you'd expect to dominate AI visibility.

Stripe scored 66/100 on an AEO (AI Engine Optimization) audit. Stripe — with that documentation team, that brand, that SEO.

Vercel got 60/100.

Product Hunt: 71/100.

If companies with hundred-person marketing teams aren't optimizing for AI visibility, your competitors in a WordPress niche almost certainly aren't either.

That's the window. It won't stay open forever — but right now, a solo founder can outrank established players in AI recommendations.

What the demo looks like

If you want to see what AI search actually does on a real store, here's a live WooCommerce demo: woo.queryra.com

Try these searches and compare them to what default WooCommerce search would return:

"present for my girlfriend" — returns gift sets, not zero results
"face cream without fragrance" — excludes fragranced products
"moisturizer under $30" — understands price from natural language
"crème pour le visage" — French query on an English store, still works

That's the difference between keyword matching and understanding what people actually mean.

The plugin is free to try: Queryra AI Search on WordPress.org

What I want to know

I've shared my story. Now I'm curious about yours.

Are you seeing traffic from AI assistants? Has ChatGPT or Perplexity ever sent someone to your product?

And if you're building something small — what channels are actually bringing real users at the early stage?

Would love to hear what's working.

I Tracked 24 WordPress Plugins Across 5 Review Sites. Here's What Paid Promotion Actually Does.

Rafał Groń — Wed, 15 Apr 2026 14:12:30 +0000

I was about to pay $500 for a sponsored review on one of the big WordPress blogs.

Before I did, I decided to check whether they actually move the needle.

I spent three weeks pulling Wayback Machine snapshots for 24 plugins across 5 WordPress review sites — tracking active install counts before and after each review published.

The results were not what I expected.

Methodology

For each plugin I followed the same process:

Find the exact publication date of the review
Pull a Wayback Machine snapshot of the WordPress.org plugin page from just before the review
Pull snapshots from 2–4 weeks after, then 2–6 months after
Compare install counts

Same process. 24 plugins. 5 blogs.

WP Mayor — 6 Plugins

Paid placements range from $250 to $750. All content is disclosed as paid — that transparency is commendable.

Results: 4 zero impact, 1 possible small bump (~120 installs), 1 no change.

I contacted WP Mayor CEO Mark Zahra before publishing. He responded in detail. His main point was fair: their clients usually sell premium plugins where conversions happen through direct sales, not WordPress.org installs. The free install count isn't a metric they track or promise. I included his full response in the original article.

Barn2 — 2 Plugins

Sponsored content starts at $499. But the most interesting data comes from Barn2's own transparency reports — sponsored content revenue dropped 82% in one year ($4,883 to $894). They've since removed the advertising page from their site.

Results: 1 zero impact, 1 decline.

ThemeIsle — 5 Plugins

They explicitly refuse paid reviews: "We do not interfere with their work and cannot accept sponsored review/link requests."

Results: organic listicle, some plugins showed modest consistent growth.

The only site with any positive signal — and they don't sell reviews.

WPExplorer — 5 Plugins

Results: 3 zero impact, 2 declined.

One declining plugin hadn't been updated in 4 years — so that's a plugin problem, not a review problem.

LearnWoo — 3 Plugins

Operated by WebToffee, a company that also sells its own plugins on the same blog.

Results: 2 zero impact, 1 growing — but growth started well before the review published.

Summary

Blog	Tracked	Zero impact	Possible bump	Declined
WP Mayor	6	4	1	0
Barn2	2	1	0	1
ThemeIsle	5	5	0	0
WPExplorer	5	3	0	2
LearnWoo	3	2	0	0
Total	21	15	1	3

Why Doesn't It Work?

Most WordPress users discover plugins through WordPress.org search or the admin dashboard — not blog articles. WP Mayor has ~16k monthly visitors. WordPress.org gets millions. The path from "reading a review" to "installing" has too many steps and too much friction.

What Does Work?

Based on building Queryra — an AI search plugin for WordPress and WooCommerce:

WordPress.org readme.txt SEO — this is where most installs come from
Organic mentions in curated lists — ThemeIsle's data backs this up
Direct community presence — Reddit, Facebook groups, developer forums

Paid editorial placements don't appear in the data.

Full Research

All individual plugin data, methodology details, and Mark Zahra's full response are in the original article:

👉 AI-powered WordPress search plugin — full research

Queryra vs Relevanssi: Do You Need AI Search or Is Keyword Search Enough?

Rafał Groń — Wed, 08 Apr 2026 11:05:51 +0000

Relevanssi is the default answer when someone asks "how do I fix WordPress search?" And for good reason — 100,000+ active installations, 1.6 million downloads, a genuinely useful free version, and over a decade of active development by Mikko Saari.

Queryra takes a different approach entirely. Instead of making keyword search smarter, it uses AI to understand what people mean — regardless of the words they use.

Full disclosure: I'm the founder of Queryra. I'll be straightforward about where Relevanssi is the better choice.

Two Approaches to the Same Problem

Relevanssi builds a custom index in your WordPress database. Uses TF-IDF weighting to rank results by keyword relevance. Intelligent keyword matching — the same approach Google used before they added AI.

Queryra converts content and queries into vector embeddings — numerical representations of meaning. Finds content whose meaning is closest, regardless of keyword overlap.

Relevanssi asks "do these words match?" Queryra asks "do these meanings match?"

Where Relevanssi Wins

The free version is genuinely good. Not a teaser — a fully functional search plugin. For blogs and small stores, often enough on its own.

100,000+ installs means battle-tested. Every WordPress configuration, theme conflict, plugin compatibility issue — they've seen it.

Runs on your server. Content never leaves your hosting. No external dependency.

PDF indexing. Search inside product manuals, spec sheets, documentation.

Deep customization. Extensive API with dozens of filters and hooks.

Database space is your only cost. No API calls, no per-search fees. Trade-off: index can be 2–3x the size of your wp_posts table.

Multisite support. Search across multiple sites in a network.

Where Queryra Wins

Natural language queries. Customer searches "something warm for winter evenings." Relevanssi needs exact word matches. Queryra understands "cozy fleece blanket" is semantically related.

Intent-aware parsing. "Headphones under $50, not Beats, sort by rating" becomes a semantic search with price filter, brand exclusion, and sort preference — all from plain text.

Zero synonym management. No need to manually map "couch" to "sofa." The AI understands they mean the same thing.

Multilingual without plugins. 50+ languages, no WPML or Polylang needed.

No database bloat. Queryra stores the index in the cloud. Your WordPress database stays clean.

Try before you install. Despite 100,000+ installs, Relevanssi has no public demo. We couldn't find a single site showcasing it. Queryra has live demos you can try right now — or search 3,000+ Wikipedia articles.

The Same Store, Five Queries

"coffee mug" — Both work perfectly. Keywords match.
"something to keep my drink hot" — Relevanssi might miss it. Queryra returns thermoses and insulated mugs.
"gift for someone who just moved" — Relevanssi finds nothing unless you configured synonyms. Queryra connects it to housewarming gifts.
"modern lamp, not floor standing, under $75" — Relevanssi can't parse negation or price from text. Queryra handles all three.
"lámpara de mesa" (Spanish for "table lamp") — On an English store, Relevanssi returns nothing. Queryra returns table lamps.

The pattern: the more natural the query, the bigger the gap.

Pricing

Relevanssi: Free version with core features. Premium ~$99–129/year (unlimited sites). Permanent ~$299–434 (lifetime). No per-search costs.

Queryra: Free 14-day trial, no credit card. $9.99/month ($120/year). Sandbox Club for unlimited testing.

Relevanssi's free version is hard to beat on budget. For premium features, both cost roughly the same annually — but deliver very different search experiences.

Who Should Use What

Choose Relevanssi if you run a blog or content site with keyword searches. You want a free plugin that dramatically improves default search. You need PDF indexing or multisite. You prefer everything running locally.

Choose Queryra if you run a WooCommerce store where product discovery impacts revenue. Your customers search with natural language. You don't want synonym lists. You need multilingual search. You want AI to handle relevance automatically.

The Honest Take

Relevanssi is the most important search plugin in WordPress history. It proved that default search was broken and gave 100,000+ sites a real fix — many for free. If you run a content site, install Relevanssi. Don't overthink it.

But keyword search has a ceiling. No amount of synonym configuration can bridge the gap between "gift for someone who loves cooking" and a Le Creuset Dutch oven. That's not a Relevanssi limitation — it's a keyword search limitation.

Queryra exists for the stores where that ceiling matters. Where a failed search means a lost sale, not just a frustrated reader.

WordPress plugin: wordpress.org/plugins/queryra-ai-search

Originally published at queryra.com

Queryra vs SearchWP: AI Semantic Search vs the Most Popular Keyword Plugin

Rafał Groń — Wed, 08 Apr 2026 11:04:57 +0000

SearchWP is one of the most respected WordPress search plugins. Trusted by 30,000+ sites, acquired by Awesome Motive in 2021, and backed by over a decade of development since its launch in 2013.

Queryra takes a fundamentally different approach. Instead of making keyword search better, it replaces keyword matching entirely with AI that understands what people mean.

This isn't a case of one being "better" — they solve the same problem with completely different technology.

Full disclosure: I'm the founder of Queryra. I'll be honest about what SearchWP does better.

The Core Difference: Keywords vs Meaning

SearchWP makes keyword search smarter. It indexes custom fields, PDFs, taxonomies, and WooCommerce product data. When a customer searches "blue running shoes," SearchWP finds products containing those words and ranks them by configured weights.

Queryra doesn't match keywords at all. It converts products and queries into vector embeddings — numerical representations of meaning. When a customer searches "something comfortable for morning jogs," Queryra returns running shoes even though no product contains those words.

SearchWP is the best keyword search plugin for WordPress. Queryra is semantic search — a different category entirely.

Where SearchWP Wins

Customization depth. Granular control over ranking — weights for titles, content, slugs, excerpts, custom fields. Multiple search engines for different site sections.

Content indexing breadth. PDF documents, custom database tables, media files, shortcode output, ACF fields, taxonomy terms.

Analytics. Popular terms, top clicks, failed searches — directly in WordPress dashboard.

Ecosystem. Part of the Awesome Motive family. Integrates with WooCommerce, EDD, BigCommerce, Gravity Forms, ACF, and more.

Track record. 30,000+ sites, 10+ years, acquired by the largest WordPress plugin company.

No external dependency. Runs entirely on your server. Data never leaves your hosting.

Where Queryra Wins

Natural language understanding. "Gift for mom under $50, not jewelry" — Queryra understands intent, price constraint, and exclusion. SearchWP needs exact keyword matches plus manual synonyms.

Zero configuration. Install, paste API key, sync. No weight tuning, no synonym lists.

Multilingual out of the box. 50+ languages without WPML or Polylang.

Price for WooCommerce. SearchWP Pro (WooCommerce) = $199/year. Queryra = $120/year ($9.99/month).

Intent-aware query parsing. Two-layer architecture: semantic matching + structured intent extraction (price ranges, brand exclusions, sorting).

Try before you install. SearchWP has no public demo. Queryra has live demos: real WooCommerce store and 3,000+ Wikipedia articles.

Real-World Example

A customer types: "budget laptop for college, nothing too heavy"

SearchWP looks for "budget," "laptop," "college," "heavy." No match unless you've configured synonyms for each term.

Queryra understands "budget" = affordable, "college" = student use, "nothing too heavy" = lightweight. Returns relevant results without configuration.

Pricing

SearchWP: Standard $99/year (no WooCommerce). Pro $199/year (WooCommerce included). All Access $399/year. No free tier. 14-day money-back guarantee.

Queryra: Free 14-day trial, no credit card. $9.99/month with full WooCommerce support. Sandbox Club for unlimited testing.

Who Should Use What

Choose SearchWP if you need PDF indexing, custom database tables, or complex post types. You want full control over ranking. You prefer everything on your server. You have time to configure synonyms and weights.

Choose Queryra if your customers search in natural language. You don't want synonym lists. You need multilingual search. Product discovery directly impacts your revenue. You want to test AI search for free before committing.

The Honest Take

SearchWP is the best of traditional search. It rewards configuration investment with precise results.

Queryra is the next generation. It removes keywords entirely and matches by meaning. Less manual control, but no synonym maintenance.

If your customers type "SKU-12345," keyword search works perfectly. If they type "comfortable shoes for standing all day under $80," semantic search wins.

WordPress plugin: wordpress.org/plugins/queryra-ai-search

Originally published at queryra.com

Best AI Search Plugins for WordPress in 2026 (Beyond WooCommerce)

Rafał Groń — Wed, 08 Apr 2026 11:02:52 +0000

Most "best AI search plugin" articles focus on WooCommerce stores. Makes sense — product search has an obvious ROI. But WordPress powers far more than just online stores.

Blogs with thousands of articles. Knowledge bases where customers need to find the right answer fast. Recipe sites, real estate listings, job boards, documentation wikis, membership sites with years of archived content.

On all of these sites, the default WordPress search is equally terrible. And on all of them, AI search can make a real difference.

This guide covers AI search plugins that work for WordPress broadly — not just WooCommerce. We'll look at what each one actually does, what it costs, and whether the AI is real semantic search or just marketing.

Because in 2026, half the plugins calling themselves "AI search" are still keyword search with a chatbot wrapper.

What Actually Makes Search "AI" (And What Doesn't)

Real AI search (semantic search) uses vector embeddings to understand meaning. Your content is converted into numerical representations by a language model. When someone searches, their query is converted the same way, and the system finds content whose meaning is closest — regardless of keyword overlap. A search for "how to fix a leaky faucet" can find an article titled "Repairing kitchen plumbing drips" even though no words match.

Keyword search with AI features is still traditional keyword matching, but with extras like typo correction, synonym suggestions, or an AI chatbot on top. The search itself is still matching words, not meaning.

AI content generation — plugins that use GPT to write content or generate meta descriptions. Nothing to do with search.

Queryra — Semantic Search for Any WordPress Site

AI semantic search that replaces default WordPress search. Uses vector embeddings to match content by meaning, with an intent-aware query parser that handles natural language filters.

Works with any WordPress post type — blog posts, pages, products, custom post types. The REST API works on any platform.

Install the plugin, sync your posts. When a visitor searches "articles about managing remote teams across time zones," Queryra finds relevant posts even if they're titled "Async communication best practices for distributed companies." The meaning matches even though the words don't.

What's good: True semantic search. Intent-aware parser handles complex queries ("posts about X, not Y"). 50+ languages without configuration. 5-minute setup, no API keys from OpenAI needed. REST API for headless WordPress or non-WordPress sites.

What's not: New product (launched January 2026). Requires cloud API connection. No PDF indexing. Free trial is 14 days, then $9.99/month.

Try it: Search 3,000+ Wikipedia articles or search the Queryra blog with AI

WordPress plugin: wordpress.org/plugins/queryra-ai-search

Full disclosure: I built Queryra. I'll be honest about the alternatives below.

AI Search — OpenAI-Powered Semantic Search

Uses OpenAI's text-embedding-3-small model to generate embeddings for your WordPress content. Stores embeddings in your local database and matches queries by vector similarity. Smart 4-tier fallback: semantic → fuzzy → keyword → spell-correct.

What's good: True semantic search. Smart fallback system. Embeddings stored locally. Works with WooCommerce, ACF, and custom post types. Free plugin on WordPress.org.

What's not: Requires your own OpenAI API key. Costs can exceed $1,000/month for large sites. 90 active installs despite 27,000+ downloads — the API key requirement kills activation.

Despite thousands of downloads, we couldn't find a single public-facing website using AI Search in production. The plugin's demo appears to run on a showcase domain rather than a real customer site.

ExpertRec — AI Search as a Service

Cloud-based search service with a WordPress plugin. Uses AI and machine learning for search, autocomplete, voice search, and recommendations.

What's good: AI-powered with NLP and typo correction. Voice search. PDF, DOCX, XLSX search. Multisite support.

What's not: SaaS pricing that scales with traffic. Less WordPress-native feel.

Price: Free plan (100 pages) → paid plans from $9/month

The Keyword Plugins Worth Mentioning

These aren't AI search, but they're what most WordPress sites currently use.

Relevanssi (100,000+ installs, free + premium) — The most popular WordPress search plugin. TF-IDF relevance ranking, fuzzy matching, custom field indexing, PDF search. Best for: blogs and content sites that need better keyword matching without any cost.

SearchWP (30,000+ users, $99–399/year) — Premium keyword search with deep customization, analytics, and WooCommerce integration. Best for: sites that need precise control over search ranking.

Ivory Search (free, 90,000+ installs) — Lightweight plugin with exclusion rules and custom field search. Best for: simple sites that need minor improvements.

FiboSearch (free + premium) — Live AJAX search with product thumbnails. Best for: WooCommerce stores that want better search UX without AI.

One thing worth noting: none of the keyword search plugins above offer a public demo. Despite a combined 230,000+ installations, you can't test any of them before installing. Queryra is the only search plugin in this article with live demos anyone can try.

When Is AI Search Actually Worth It?

You probably need AI search if:

Your site has 500+ posts and visitors struggle to find content
You see "zero results" queries for terms that should match something
Your visitors search with questions and descriptions, not precise keywords
Your content uses varied terminology across articles
You serve a multilingual audience

Keyword search is probably fine if:

Your site has fewer than 100 posts
Visitors search with exact terms they already know
Your budget is zero and Relevanssi's free version covers your needs
Your content is in one language with consistent terminology

Our Recommendation

For blogs on a budget: Relevanssi (free). For knowledge bases: Queryra or ExpertRec. For WooCommerce stores: see our WooCommerce-specific comparison. For multilingual sites: Queryra's 50+ languages out of the box. For developers: Queryra's REST API works outside WordPress entirely.

No matter what you choose, replacing default WordPress search with anything is an improvement. The default search in 2026 is the same basic keyword matching it was in 2006.

Originally published at queryra.com

How to Make Your WooCommerce Store Discoverable by ChatGPT (And Convert That Traffic)

Rafał Groń — Wed, 01 Apr 2026 08:07:32 +0000

Shopify just got native ChatGPT integration. WooCommerce store owners have to set it up manually — but the manual approach actually gives you something Shopify's integration doesn't.

Here's the full setup.

Part 1: Discovery — Tell ChatGPT Your Store Exists

Create an llms.txt file

Place it at yourstore.com/llms.txt. ChatGPT-User bot, PerplexityBot, and other AI crawlers read this file to understand what your site is about.

# YourStore
> [What you sell, in one sentence]

## About
YourStore sells [product category] for [customer type].

## Product Categories
- Category 1: https://yourstore.com/category/cat-1/
- Category 2: https://yourstore.com/category/cat-2/

## Search
AI-powered semantic search available.
Endpoint: https://yourstore.com/?s={query}&post_type=product

## Key Pages
- Shop: https://yourstore.com/shop/
- Contact: https://yourstore.com/contact/

Add schema.org Product markup

For WooCommerce, Rank Math or Yoast handle this. Make sure these fields are populated: name, sku, price, availability, brand.

Consistency matters more than completeness. A product where SKU matches across schema, feed, and title is a stronger entity signal than one with rich but inconsistent markup.

Part 2: Conversion — Fix What Happens When They Arrive

Here's what most guides skip.

You can't put 1,000 products into llms.txt. So when a customer arrives from ChatGPT and searches your store, default WooCommerce search still fails them:

"moisturizer for sensitive skin, under $30" → 0 results
"wireless headphones, not Sony" → 0 results
"gift for someone who loves cooking" → 0 results

ChatGPT brought them to you. Your search lost them.

The fix: semantic search trained on your specific catalog

Queryra is a WooCommerce AI search plugin that replaces default keyword search with vector embeddings. It indexes your catalog in minutes and understands natural language queries, price filters, brand exclusions, and 50+ languages out of the box.

Customer types: "wireless headphones under $60, not Sony"
→ Layer 1: vector search finds semantically relevant headphones
→ Layer 2: intent parser extracts price cap ($60) and brand exclusion (Sony)
→ Result: filtered, ranked, relevant products

No OpenAI API key required — everything runs on Queryra's infrastructure.

The Full Funnel

ChatGPT (discovers your store via llms.txt + schema)
    ↓
Customer arrives with purchase intent
    ↓
Queryra (AI trained only on YOUR catalog)
    ↓
Customer finds the right product
    ↓
Sale

General AI for discovery. Your own AI for conversion.

Resources:

Queryra AI Search Now Works in 50+ Languages — Multilingual WooCommerce Search

Rafał Groń — Thu, 26 Mar 2026 10:35:34 +0000

Default WooCommerce search is broken in English. In Polish, German, or Dutch — it's even worse.

Today I shipped multilingual support for Queryra — AI semantic search for WooCommerce now works in 50+ languages out of the box.

What this means in practice

A Polish customer searching "prezent dla mamy" finds gift products — even without exact keyword matches in the product titles.

A German customer searching "etwas Warmes für den Winter" finds winter clothing.

A Dutch store with Dutch product descriptions works end to end.

No configuration. No language settings. No extra cost.

How it works

We switched to a multilingual sentence transformer model that understands semantic meaning across 50+ languages. The same AI that matches "gift for someone who likes cooking" to relevant products in English now does the same in Polish, German, French, Spanish, Dutch, Serbian, and dozens of others.

Why this matters

Most "AI search" plugins for WooCommerce are English-only. Non-English stores — which represent the majority of WooCommerce installations globally — have been stuck with keyword search that fails on natural language queries in any language.

This update unblocks all of them.

Plugin: wordpress.org/plugins/queryra-ai-search
Demo: woo.queryra.com