When to Upgrade Your Site Search: What Baymard's Data Says You're Actually Failing At

Roughly half your visitors use search rather than navigation to find a product, and 56% of ecommerce sites fail to adequately support what those people type^[1]. Not "could be better." Fail.

The reflex is to buy a search vendor. Sometimes that's right. Often the failure is in your product data, and a better search engine over the same bad data returns the same nothing, faster and for $449 a month. Here's how to tell which one you've got.

What Baymard actually measured

Baymard Institute benchmarks 170+ ecommerce sites and apps with over 10,000 usability scores for 2026, and their search research breaks failure down by query type rather than giving one useless overall grade^[1].

The eight query types, with the share of sites that have issues on each:

Query type	Example	Sites with issues
Exact search	"Nike Air Max 90"	12%
Product type	"running shoes"	20%
Symptom	"shoes for flat feet"	37%
Feature	"waterproof running shoes"	39%
Use case	"shoes for a marathon"	43%
Compatibility	"laces for Air Max 90"	44%
Abbreviation and symbol	"sz 10", "10 in"	54%
Non-product	"returns policy", "delivery times"	66%

Source: Baymard Institute, updated 29 April 2026^[1].

Read that table again, bottom-up

The two worst failures are non-product searches at 66% and abbreviations at 54%^[1]. Neither is a relevance-ranking problem. Neither is fixed by semantic search, vector embeddings or an LLM.

Someone typing "returns policy" into your search box wants a page, not a product. Someone typing "sz 10" is using a shorthand your synonym list doesn't have. Both are fixable in an afternoon on almost any platform, for free.

Meanwhile exact search, the thing every vendor demos, fails on only 12% of sites^[1]. It's mostly solved. It's mostly solved by whatever you already have.

Does your search actually need upgrading?

Do the test before you do the shopping. It takes an hour.

Export your top 200 search queries from the last 90 days with result counts. Sort by zero-result queries first, then by high-volume-low-conversion.

Then classify each into Baymard's eight types. You'll usually find one of three patterns.

Pattern one: lots of zero-result queries for products you definitely stock. That's a synonym and product data problem, not an engine problem. Fixable free.

Pattern two: results come back, but they're wrong, on feature and use-case queries. That's an attribute problem. Your engine can't filter on "waterproof" because "waterproof" isn't a structured attribute anywhere, it's a word in paragraph three of the description.

Pattern three: results are relevant but the ranking is poor, and merchandisers can't fix it. That's the one where a search vendor earns their fee.

Only pattern three justifies a purchase. Patterns one and two waste it, because the new engine indexes the same data.

The stakes, without the invented statistics

I'm not going to quote you the usual "searchers convert 3x higher" figure, because the sourcing on it is a mess and the causality runs both ways. People who search are further down the funnel already.

What's defensible is narrower. Roughly half of shoppers use search as their primary product-finding strategy in Baymard's testing^[1]. A zero-result page for a product you stock is a lost sale with no recovery path. And Baymard's testing has captured thousands of instances of search failing participants when the product was available on the site^[1].

That last one is the actual cost. Not "search could be better." You have the product, the customer asked for it in plain English, and you said no.

What we found: the AI tier is quote-only almost everywhere

We priced the search vendors from their own pages, looking for one thing: what does the AI-relevance product actually cost, as opposed to the keyword product.

Algolia

Build is free with 10K search requests a month and 1M records. Grow includes 10K requests then $0.50 per additional 1K, with 100K records then $0.40 per additional 1K. Grow Plus is the same record pricing but $1.75 per additional 1K searches, and adds AI Ranking and advanced personalisation^[2].

NeuralSearch, which is the actual AI retrieval product, is Elevate tier. Custom pricing, annual contract required, quote only^[2].

So the figure you'll see quoted around the web for "Algolia AI search" is usually the Grow Plus price, and Grow Plus is not NeuralSearch. Worth knowing before a budget conversation.

Klevu and Athos Commerce

This one's genuinely confusing now and I'll be honest that I couldn't resolve it cleanly. Klevu merged with Searchspring and Intelligent Reach into Athos Commerce in January 2025. Standalone Klevu pricing tiers are no longer consistently published.

What's findable: a free Starter tier at 100 sessions a month, then paid tiers around $39.99, $99.99 and $299.99 on the Shopify App Store listing^[14], while Athos-level pricing for AI Site Search is quoted from around $449/month with merchandising and recommendations as separate modules from around $549 and $449. The Athos site itself publishes no pricing^[15].

Different sources give different numbers and I can't reconcile them from primary material. Treat any published Klevu figure as unreliable until the vendor confirms it in writing for your session volume.

Constructor, Coveo, Bloomreach

All quote-only, all enterprise, all realistically starting in the tens of thousands per year. Constructor documents genuine natural-language attribute extraction, which most of the SMB tier does not, and prices accordingly.

Shopify Search & Discovery

Free, and better than its reputation, with a specific and important catch.

Semantic search requires your store to be on Grow, Advanced or Plus, and to have fewer than 200,000 products. It isn't supported for the Japanese locale, and it doesn't apply to predictive search^[3].

So a Basic-plan merchant on Shopify has keyword matching only. Basic is £19/month billed yearly and Grow is £49^[4], which means for a lot of stores the cheapest meaningful search upgrade available is a £30/month plan change rather than a £449/month app.

That's a genuinely useful thing to know and no search vendor is going to tell you.

The free fixes, in the order I'd do them

Every one of these is free on every platform, and together they address the two worst failure categories Baymard measured.

1. Make non-product searches work

66% of sites fail this^[1]. The fix: index your policy pages, FAQ, delivery info and returns page into search results, or add a rule that surfaces the right page above products for a list of known queries.

Twenty queries covers most of it. "Returns", "delivery", "shipping", "size guide", "contact", "track my order", "warranty", "exchange", "refund", "gift card". Half a day, and it removes the most common failure in the entire dataset.

2. Build a real synonym list from your own zero-result log

54% of sites fail on abbreviations and symbols^[1]. Don't buy a generic synonym pack. Use your own zero-result queries, because they contain exactly the vocabulary your customers use and your catalogue doesn't.

Look for units and abbreviations first: sz, xl, mm, cm, inch and the inch mark, litre and l, pack and pk. Then brand misspellings. Then regional variations, which matter more than people expect if you sell into both the UK and US.

3. Turn description text into structured attributes

Feature searches fail on 39% of sites and use-case searches on 43%^[1]. Both fail for the same reason: the information exists as prose, not as data.

If "waterproof" is a word in your description, no engine can filter on it reliably. If it's a metafield with a boolean value, every engine can. This is the highest-effort item on the list and the one that pays back longest, because the same structured attributes then feed your filters, your feeds and your agent readiness.

4. Fix zero-result pages

A zero-result page showing nothing is a dead end. A zero-result page showing your bestsellers in the nearest category, plus a search box with the query still in it, recovers a percentage of those sessions for the cost of a template change.

Platform by platform

Shopify

Native Search & Discovery^[13] gives you synonyms, filters, boosts and product ranking rules, plus semantic search on Grow and above with fewer than 200,000 products^[3].

Known limits worth planning around: filters cap at 25 filterable attributes, and collection filter behaviour degrades on very large catalogues. If either of those is binding on you, that's a legitimate reason to buy.

The Shopify-specific mistake: installing a search app and leaving Search & Discovery configured too, so two systems fight over the same results page. Pick one.

WooCommerce

Core Woo search is a database LIKE query against post title and content. It doesn't do relevance ranking, it doesn't handle typos, and it doesn't understand attributes. On a catalogue over a few hundred products it's genuinely not fit for purpose, and this is the single biggest functional gap between Woo and Shopify that nobody mentions in platform comparisons.

The good news is the fix is cheap. An ElasticPress or Meilisearch or Typesense layer over your product data gets you real relevance for hosting cost plus a day of setup. Woo's product data model, with attributes as taxonomies, is actually well suited to faceted search once you index it properly^[5].

The bad news is that nobody does it, so most Woo stores are running a LIKE query in 2026 and wondering why search converts badly.

Magento and Adobe Commerce

Magento requires OpenSearch or Elasticsearch as a hard dependency, so you already have a real search engine underneath, which puts you ahead of Woo by default. Adobe also offers Live Search as a separate SaaS product on top.

The Magento-specific issue is attribute configuration. Every attribute has "Use in Search", "Search Weight" and "Visible in Advanced Search" settings, and on most stores these were set once during the build and never revisited. Half an hour reviewing them usually improves relevance more than any product purchase.

Check search weight on your brand attribute specifically. It's almost always wrong.

BigCommerce

Native search is decent and faceted search works on product options and custom fields without extra work. Vendor integrations are available for all the majors. The plan boundaries at $30,000 and $100,000 trailing-twelve-month GMV, and the 0.9% GMV overage on Scale above $33,333/month^[6], are the usual thing to price in before adding a paid app.

Custom and headless

You choose the engine, which means you own the decision that everyone else has made for them. Postgres full-text search is genuinely sufficient for catalogues under a few thousand SKUs and costs nothing extra. Typesense^[16] and Meilisearch^[17] are the sensible self-hosted step up, and both publish their pricing, which by itself puts them ahead of most of this category. OpenSearch if you need the ecosystem^[18].

The thing to design deliberately: hybrid retrieval. Lexical matching catches exact codes and part numbers that embeddings miss entirely. Semantic matching catches intent that keywords miss. Reciprocal rank fusion over both, with a relevance floor so genuinely off-target queries return nothing rather than the nearest-but-wrong result.

That last part matters more than it sounds. A pure vector search always returns something, because there's always a nearest neighbour. Returning a wrong product confidently is worse than returning nothing with a good suggestion.

The search audit checklist

Lift this. Run it quarterly.

#	Check	Pass condition
1	Search "returns policy"	Policy page in top 3, not zero results[1]
2	Search your top product with a typo	Correct product still ranks first
3	Search an abbreviation your customers use	Returns results, not zero[1]
4	Search a feature you sell on	Filters to matching products only
5	Search a use case in plain English	Sensible results, not keyword soup
6	Search a compatibility question	Returns the accessory, not the parent product
7	Trigger a genuine zero-result page	Shows recovery options, not a dead end
8	Search on mobile	Keyboard type is correct, results are reachable
9	Check top 20 queries by volume	Every one converts above site average
10	Check zero-result log	Under 5% of total searches
11	Check merchandiser can pin a product	Without a developer
12	Check out-of-stock behaviour	Buried, not hidden and not ranked first

What search means when the searcher is an agent

This is where site search stops being a UX feature and becomes a distribution channel, and it's the part I'd pay most attention to over the next two years.

Google's Universal Commerce Protocol launched at NRF on 11 January 2026 with Shopify, Etsy, Wayfair, Target and Walmart as co-developers, and it defines how agents discover and transact with merchants across the whole shopping journey^[7]. Shopify's engineering team has written up their side of building it^[8]. The Agentic Commerce Protocol maintained by OpenAI and Stripe covers the checkout half at spec version 2026-04-17^[9].

An agent doesn't use your search box. It queries a feed or an endpoint. Which means everything in the "structured attributes" section above stops being a search relevance improvement and becomes the difference between being comparable and being invisible.

Two grounding facts on how far behind most catalogues are. Adobe Analytics reports that traffic from AI sources to US retail sites grew 138% year on year in May 2026, and that large parts of US retail sites are not fully readable by machines, with product pages scoring worse than homepages or category pages^[10].

The specifics are worse than the summary. An audit by Reza Moaiandin at SALT.agency looked at 141 product detail pages across 29 retailers and found 70% missing all three of the attributes an agent needs to transact responsibly. Only 18% carried priceValidUntil, 13% shippingDetails.deliveryTime and 11% merchantReturnDays. 65% had no GTIN, and 15% returned an HTTP 403, making them invisible to agents entirely^[11].

SALT has also published a technical guide on optimising for the Agentic Commerce Protocol, which is more useful than most of what is written on this^[12]. Worth noting it is an agency that sells this work.

A sanity check on the hype at the same time. Adobe is measuring AI referral growth from a very small base, so the growth rates are real and the absolute share is still low^[10]. This is a thing to prepare for, not an emergency.

What to do this week

1. Export 90 days of search queries with result counts and conversion. If you can't, install that first. You're flying blind otherwise.
2. Classify the top 200 into Baymard's eight types. The distribution tells you what to fix^[1].
3. Make non-product queries return the right page. Twenty rules. Biggest single win available^[1].
4. Build a synonym list from your own zero-result log. Not a generic pack.
5. If you're on Shopify Basic, price a Grow upgrade against a search app. Semantic search comes with the plan^[3].
6. If you're on WooCommerce, check whether you're still on a LIKE query. If so, that's your entire problem.
7. Pick three product attributes buried in descriptions and promote them to structured fields. Search, filters and agents all read the same data.

The takeaway

The two worst-performing search query types in Baymard's data are non-product searches and abbreviations^[1], and neither one is a relevance problem. Both are free to fix. Meanwhile the query type every vendor demos, exact search, already works on 88% of sites^[1].

So my stance, which people who sell search software will not like: most stores buying a search vendor are buying a better engine for the same unstructured data, and would get more from three days of catalogue work. Buy the vendor when your merchandisers need control your platform can't give them, or when your catalogue has genuinely outgrown native. Not because search "feels bad."

Go and look at your zero-result log. How many of those do you actually stock?

Sources

1. Ecommerce Search UX Best Practices: the 8 search query types. Baymard Institute, updated 29 April 2026. 170+ benchmarked sites, 10,000+ usability scores.
2. Algolia Pricing. Algolia. Accessed 22 July 2026.
3. Modifying search with Shopify Search & Discovery. Shopify Help Center. Accessed 22 July 2026.
4. Shopify Pricing (UK). Shopify. Accessed 22 July 2026.
5. Managing Products. WooCommerce documentation. Accessed 22 July 2026.
6. BigCommerce Pricing. BigCommerce. Accessed 22 July 2026.
7. Under the Hood: Universal Commerce Protocol (UCP). Google Developers Blog, January 2026.
8. Building the Universal Commerce Protocol. Shopify Engineering, 2026.
9. Agentic Commerce Protocol specification. Maintained by OpenAI and Stripe. Spec version 2026-04-17.
10. AI traffic grows but retail sites lag in AI search visibility. Adobe Analytics, June 2026. Reported independently by Digital Commerce 360, 17 June 2026.
11. 70% Of Top Retailers Are Invisible To Agentic Commerce. Search Engine Journal, reporting the SALT.agency audit by Reza Moaiandin. 141 PDPs across 29 retailers.
12. Optimising for Agentic Commerce Protocol: a technical guide for SEOs. SALT.agency. Agency-published; they sell this work.
13. Shopify Search & Discovery. Shopify App Store listing. Accessed 22 July 2026.
14. Klevu Smart Search. Shopify App Store listing. Accessed 22 July 2026.
15. Athos Commerce. Accessed 22 July 2026. No pricing published.
16. Typesense. Accessed 22 July 2026.
17. Meilisearch Pricing. Accessed 22 July 2026.
18. OpenSearch. Accessed 22 July 2026.