NEWNow shipping: ACP Β· Google UCP Β· Retail MCP integrations
MnT Future
AI Search & Recommendations

The 4 Search Query Types Keyword Matching Fails

CEO UdhayaseelanΒ·Β·6 min read
The 4 Search Query Types Keyword Matching Fails

A shopper on a skincare site doesn't type "niacinamide serum." She types "something for redness that won't break me out." A shopper on a hardware site doesn't type the SKU. He types "bracket that holds a 55-inch TV on drywall." Both of them hit "search," and on most ecommerce sites in 2026, both of them get nothing useful back β€” not because the catalog doesn't have the answer, but because the search box was never built to understand the question.

That's not a hunch. Baymard Institute's ecommerce search benchmark β€” 170+ sites and apps tested, more than 10,000 individual performance ratings, most recently updated April 29, 2026 β€” found that 56% of ecommerce sites have search UX rated mediocre or worse. But the more useful number in the report isn't the headline; it's the breakdown by query type. Search doesn't fail evenly. It fails in a very specific, very predictable pattern.

The Failure Isn't Random. It's By Query Type.

Baymard splits shopper queries into eight types and scores how well sites handle each one. The split is stark. "Exact" queries β€” a model number, a brand plus product name β€” fail on only 12% of sites. "Product Type" queries, like "running shoes," fail on 20%. Both are easy: the words in the query mostly match the words in the product data.

Then the failure rate roughly doubles or triples. "Feature" queries ("waterproof jacket under $200") fail on 39% of sites. "Symptom" queries ("cure for dry skin") fail on 37%. "Compatibility" queries ("case that fits iPhone 15 Pro") fail on 44% β€” the worst-performing query type with a clear commercial intent behind it. "Use Case" queries ("gift for someone who just moved") fail on 43%.

Every one of those four query types has the same thing in common: the words the shopper types don't appear in the product title or description. A keyword-matching search index β€” the kind still running underneath most Shopify and headless storefronts β€” can only find what it can string-match. It has no way to know that "cure for dry skin" should surface a ceramide moisturizer, or that "gift for someone who just moved" should surface a candle set and a doormat. The catalog has the right products. The search technology just can't get from the question to the answer.

Why This Is a Scoping Problem, Not a Platform Problem

Most teams that decide to "add AI search" treat it as a single switch: rip out the old search box, bolt on a vendor, done. That's expensive, disruptive to a working checkout funnel, and β€” based on the Baymard split β€” unnecessary for 80% of the traffic. Exact and Product Type queries already work. Rebuilding search from zero to fix a problem that's concentrated in four specific query types is solving the wrong scope at the wrong cost.

The more precise fix is a hybrid architecture: keep fast, cheap keyword/lexical matching for exact and product-type queries, and add a semantic layer β€” vector embeddings of product titles, descriptions, attributes, and reviews, matched against the meaning of the query rather than its literal words β€” specifically for feature, symptom, compatibility, and use-case queries. A reranking step then blends both result sets so the shopper never knows two different systems answered their question. This is the same architecture MnT Future runs on its own commerce platform, MnT Commerce, where semantic search sits alongside a shopping assistant and an ops agent rather than replacing the parts of search that already work.

In plain terms: on-site AI search means teaching your search index to match customer intent, not just customer keywords β€” for the specific query types where intent and keywords diverge, not for every query type equally.

Compatibility Queries Deserve Special Attention

Of the four hard query types, Compatibility is worth calling out on its own. A 44% failure rate on "does this fit my [X]" queries is a direct hit on purchase confidence at the exact moment a shopper is closest to buying. Someone asking a compatibility question already has a product in mind and money ready to spend; a bad answer here doesn't just lose a search session, it loses a near-certain conversion. For any Tier 1 D2C brand selling products with sizing, fitment, or compatibility constraints β€” apparel, electronics accessories, auto parts, home goods β€” this single query type is often the highest-leverage place to start a semantic search rollout, before touching Feature or Use Case queries at all.

What to Actually Measure

Before commissioning any AI search rebuild, pull your own site's search logs and bucket queries the same way Baymard does: Exact, Product Type, Feature, Symptom, Compatibility, Use Case, Abbreviation, Non-Product. The distribution will differ by category β€” a fashion brand sees more Use Case queries, an electronics brand sees more Compatibility queries β€” and that distribution should decide where the semantic layer gets built first. A search upgrade scoped against your own query mix, not a generic vendor pitch, is the difference between a project that moves conversion and one that just moves cost.

For a funded D2C brand already running paid acquisition, this matters more than it looks. Traffic that arrives from a paid campaign or an AI-referred session is expensive per visit, and every one of those visits that hits "search" and gets a bad answer on a Feature, Symptom, Compatibility, or Use Case query is a paid click that converts nowhere. Fixing the four hardest query types isn't a UX nicety β€” it's the cheapest lever most brands have left on traffic they've already paid to acquire, because the fix targets sessions that were already close enough to buy to bother searching in the first place.

There's also a sequencing question worth asking before any build starts: does the semantic layer need to run against the live catalog in real time, or can it work off a periodic index refresh? A flash-sale or limited-drop brand needs the former; a brand with a stable, slow-turning catalog can usually get away with the latter at a fraction of the engineering cost. That distinction alone often separates a two-week integration from a two-quarter one.

Ready to See Where Your Search Box Breaks?

Book a free strategy session and we'll pull a sample of your own search logs against this same query-type framework β€” no generic audit, just your actual data mapped against where semantic search will move the needle first.

Ecommerce search fails hardest on natural-language queries. A 2026 Baymard Institute benchmark of 170+ sites found Exact and Product Type searches fail on only 12-20% of sites, but Feature, Symptom, Compatibility, and Use Case queries β€” where shopper wording doesn't match product data β€” fail on 37-44%. The fix is semantic (vector) search layered onto existing keyword search, not a full rebuild.

Next step

Tell us what you're building. We'll show you how we'd build it.

A free strategy session with a senior consultant: data model, APIs, and a scalability plan. Or a free agent-readiness audit of your store.