Ecommerce Site Search: What "Red Dress" Actually Means

The search box is the most used and least maintained part of most online stores. A visitor browsing your menu is still deciding. A visitor typing into the search box has already decided and is only looking for the product. So the person you lose there is not a browser. It is a buyer.

Take a concrete query. A shopper types "red dress". Behind those two words sit four separate expectations: a category (dress), a color filter (red), an implied stock condition (available in her size), and an unstated context (probably a wedding, a party, an evening out). A keyword engine sees only the first one and returns everything containing both words: red handbags, dress hangers, a collection themed around red carpets.

This guide covers how site search actually works, what AI-powered semantic search fixes and what it quietly does not, and how to decide whether your store needs it at all.

What does a shopper typing "red dress" actually expect?

Shoppers do not search for words. They search for outcomes. The correct answer to "red dress" is not a list of products containing those two words. It is a storefront of red dresses available in that shopper's size. The job of the search box is not to match text but to read intent and build a small store around it.

In practice this creates a specific difference. Good search does not consider itself finished once results load. It converts the color in the query into an applied filter, narrows the category, and pushes sold-out sizes down. It performs the three clicks the shopper would otherwise have to make.

The most common mistake we see is exactly here: merchants treat the results page as a list, while shoppers treat it as a storefront. If there are no filters on the results page, and sorting is by date added rather than relevance, shoppers spend a few seconds there and bounce.

What is the difference between keyword and semantic search?

Keyword search matches words. Semantic search matches meaning. A keyword engine splits every product into words and keeps an index; if the query word is not in that index, the product does not exist. Semantic search converts both products and queries into strings of numbers, and things that mean similar things land close together in that number space.

An analogy helps. Keyword search is the index at the back of a book: you have to know the exact word. Semantic search is an experienced sales associate on the floor; say "I have a summer wedding, what should I wear" and they understand you anyway.

This also explains why a product catalogued as "burgundy evening gown" never appears for "red dress". Word overlap is zero. Meaning overlap is high. If you want the mechanics of that number space, our piece on whether you actually need a vector database goes through it in detail.

One correction worth making: the industry did not move to pure semantic search. It moved to hybrid. The reason is simple. Semantic search is bad at exact matches. When a customer types a SKU, a brand name, or "size XL", keyword matching is more accurate. Every major search engine on the market now ships a hybrid mode, which tells you the industry itself rejects the claim that AI replaced keyword search.

Why is search harder for non-English catalogs?

If your catalog is in a language with heavy inflection, compound words, or accented characters, an out-of-the-box search configuration will underperform in ways that are hard to notice. English is unusually forgiving here, and most default settings were tuned for it.

Three problems come up repeatedly. The first is word endings. In agglutinative and heavily inflected languages, a single noun appears in a dozen surface forms with the same root. The simple stemming built for English, which mostly strips plural and gerund endings, does nothing useful. If the language analyzer is not switched on, a shopper searching the plural form will not see the singular product.

The second is case conversion. Some languages have letter pairs that do not map onto the universal uppercase and lowercase rules, Turkish dotted and dotless i being the textbook example. Software applies the default rule, and some queries silently stop matching. Search engines ship language-specific lowercase filters for exactly this, and they are not on by default.

The third is accent stripping. Customers type without accents, especially on mobile. Both the product names and the query need to be folded down to their plain forms before comparison, or the two strings are simply different.

The interesting part: semantic search sidesteps the first of these problems for free. Because it works on meaning, it does not care which ending a word arrived with. In non-English markets this is the strongest and least discussed argument for going semantic.

Does site search really lift conversion?

The honest answer: probably yes, but most of the numbers circulating are not trustworthy. Nearly every statistic in this space originates from the blog of a company selling search software. The evidence that "site search is extremely valuable" is being produced by people who sell site search.

A specific example. The line "92% of people who search go on to buy" appears uncited across dozens of sites. A 92% purchase rate is not physically plausible for an online store; that figure is almost certainly an add-to-cart or click metric that turned into a purchase metric somewhere along the way. Similarly, "searchers convert six times better on Amazon" has been copied for years, but Amazon does not publish that breakdown.

When a number appears on dozens of sites in the same sentence, that is evidence of copying, not evidence of accuracy.

There is also a classic reasoning error buried in these figures. People who use search already have high intent. The search box may not be creating conversion at all; it may simply be making intent visible. That distinction matters, because a merchant who budgets on the assumption that fixing search will multiply conversion sixfold is going to be disappointed.

Stop looking for industry averages and measure your own. Your store's zero-result rate is worth far more than any benchmark, and it costs nothing to pull.

The zero-results problem: what happens when nothing is found?

Zero results is the most expensive failure in search. In that moment the shopper does not conclude that they searched badly. They conclude that you do not sell the thing. In most cases the product is sitting in stock, catalogued under a different word.

There is a trap to avoid here. "Semantic search eliminates zero results" is technically true and practically misleading. Vector search returns something for every query, because there is always a nearest neighbour in the number space. Zero results is not solved so much as converted into irrelevant results. The metric improves while the experience does not.

The right move is unglamorous: read your zero-result logs once a week. The top fifty terms your customers typed and found nothing for will tell you both which products you are missing and which words you are missing. No software you can buy will hand you that list, and pulling it costs nothing.

Should search result pages be indexed by Google?

Short answer: no. Internal search result pages should be blocked from crawlers. They generate a separate URL for every query, their content is volatile, and they are largely duplicates of each other. Letting them be indexed creates thousands of thin pages on your domain.

That does not mean site search has no SEO value. The value is indirect and arrives through two channels. First, your search logs tell you exactly which words your customers use for your products. That is the most honest keyword source you have when writing category pages and product copy, because unlike anything from a keyword planner, a real customer typed it.

Second, search that works keeps visitors on site longer and deeper. Those are not ranking factors directly, but they shape the signals about whether people arriving from search left satisfied.

How the math works for a 3,000-product store

The value of a search investment is calculated from your own traffic, not from benchmarks. The example below borrows nothing from outside; it uses four numbers you can pull from your own analytics: monthly visitors, share who use search, zero-result rate, and the conversion rate of people who search.

Say you run a 3,000-product clothing store with 40,000 monthly visitors. Analytics shows 15% of them use the search box, so 6,000 search sessions a month. Your logs put the zero-result rate at 14%, which is 840 sessions ending with nothing.

Those 840 sessions convert at zero by definition. Assume synonym management and typo tolerance recover half of them, so 420 sessions. If searchers convert at 4%, that is roughly 17 additional orders a month. At a $60 average order value, about $1,000 a month, or $12,000 a year.

The point of the exercise is the structure, not the total. Filling in the same table with your own four numbers tells you directly how much budget the problem deserves. A store where the answer comes out at $12,000 a year can stop debating a $30 per month search plan. A store where it comes out at $800 should write the synonym list by hand and stop there.

What does smart search cost?

Cost has two parts: the search engine itself, and the ongoing expense of the semantic layer. Hosted services start somewhere in the $20 to $45 per month range for entry plans (as of August 2026; pricing in this category changes often, so check current rates). With open-source versions the software is free and the server plus maintenance burden moves to you.

The second part is the one people miss. Semantic search requires every product and every query to be sent to a model and converted into numbers. As the catalog changes, that work repeats. Keyword search has no equivalent line item. This is why "AI-powered search" tends to become a permanent subscription.

The options break down roughly like this:

• Hosted services (Algolia, Typesense Cloud, Meilisearch Cloud): fast to set up, no maintenance, and a bill tied to search volume and record count, which means it grows with your traffic.
• Open source, self-hosted (Typesense, Meilisearch, OpenSearch): no licence fee, but servers and outages are yours. On a small team this can cost more than the hosted option, not less.
• pgvector: if you already run PostgreSQL, you can add vector search inside your existing database with no extra licence. You will have to combine the keyword side yourself.

If you are on a closed hosted commerce platform, whether you can attach an external search engine depends on your plan. Open ecosystems such as WooCommerce, Shopify and Magento generally make integration easier. Check your own platform's integration list before budgeting for anything.

Does a small store need AI search at all?

Usually not. In a 500-product store, semantic search introduces more cost and complexity than the problem it solves. At that scale most of the gain comes from three much cheaper jobs.

Turn on typo tolerance. Write a synonym dictionary: map the informal words your customers use onto the formal names in your catalog, the way "jumper" maps to "sweater" or "phone case" maps to "cover". Then search your own top fifty terms by hand and look at what comes back.

All three fit in a day and none of them involve AI. A semantic layer makes sense after those are done and you can still see queries being missed. Improving the words in your product copy helps here too, since those are the words the engine has to match against; our guide to AI product descriptions covers how to write them without turning the catalog into noise.

Three numbers are enough to know whether search is working: zero-result rate, click-through rate on search results, and the gap between the conversion rate of visitors who search and those who do not. All three can be set up in standard analytics tools.

Where to start

• Measure before you spend. Pull the last thirty days of zero-result queries. Make the budget decision from that list, not from industry averages.
• Test your own language edge cases. Search the singular and plural of a common noun, an accented and unaccented version of the same word, and one of your SKUs. Every pair that returns different results is a setting to fix.
• Exhaust the free wins first. Typo tolerance, a synonym dictionary, and filters on the results page. Do not fund a semantic layer until these are done.
• Never leave the zero-results page empty. Show bestsellers, related categories, or a way to contact you. An empty page is a closed door.
• Go hybrid, not pure semantic. Confirm that SKU and brand lookups still work by exact match after the change.

The search box is the one place in your store where customers tell you what they want in their own words. Most merchants never read those sentences. Reading them will do more for you than whichever engine you end up installing.