Shop Search That Finds: Enriching Catalog Data with AI

A customer types «cordless drill 18V» into your shop search and gets zero results. Not because your search engine is bad: the «voltage» attribute was simply never maintained in your catalog. The best search engine can only find what is in the index. No tool in the world compensates for missing attributes, empty descriptions, and inconsistent categories.

The Baymard Institute shows how big the problem is: 56 percent of the e-commerce sites examined do not adequately support their users' search needs (baymard.com, retrieved September 4, 2026). The breakdown is telling: 39 percent of sites struggle with feature searches like «waterproof», 43 percent with use-case searches like «drill for concrete», 54 percent with abbreviation searches. Exactly the query types that need maintained attributes and synonyms.

My observation from projects matches this: when a shop search disappoints, suspicion falls on the search engine first. A look into the index then often shows something else: half the products have no description, attributes are maintained sporadically, categories have grown historically. Swapping the tool alone changes none of that.

This is where AI enrichment comes in: a language model reads your existing product texts and data sheets and fills structured attribute fields, categories, and short descriptions from them. Not as an end in itself, but so search and facets have material to work with.

One distinction up front: how thin product data breaks AI agents and buyers alike is its own topic, covered in Agent-ready product data. Here we take the search perspective: which enrichment concretely improves your results, and how you turn it into a measurable loop.

Up front: «better data» is too abstract to work with. For search, four concrete levers count: attributes for facets, synonyms, consistent categories, and searchable short descriptions. I'll show them using Meilisearch as the example; what the tool can do and when it pays off is in the foundational article What is Meilisearch?. The principle applies to any search engine.

In Meilisearch, a field only becomes a filter once you declare it as a filterableAttribute (meilisearch.com/docs, retrieved September 4, 2026). The catch sits one level deeper: you can only declare what exists in the data. Without a maintained «voltage» field there is no 18-volt facet — no matter how good the search engine is.

Once the fields are filled, the facetDistribution returns the hit count per facet value: your customer sees «18 V (42 products)», clicks, and filters. Completeness matters: a facet that is maintained on only half the products effectively hides the other half of your range. Exactly these gaps are what an LLM fills from existing description texts.

An example from the tool trade: customers filter by voltage, chuck type, and weight. If those values only sit somewhere in the running text of the data sheet, they do not exist for facet navigation. Enrichment translates running text into structure — and only structure is filterable.

Your customers do not search with your terms. In B2B the gap is widest: the catalog says «angle grinder», the fitter searches «Flex» — a brand name turned everyday word for the tool. Meilisearch offers one-way synonyms («Flex» finds angle grinders, not the reverse) and mutual ones, with clear limits: at most 50 synonyms per term, and queries of four words or more no longer match synonyms (meilisearch.com/docs, retrieved September 4, 2026).

The synonym list itself is enrichment work: an LLM proposes candidates from product texts and search logs; you should approve them manually. How deep the language gap between part number and application term runs in B2B is covered in Semantic product search in B2B.

The third lever: consistent categories. If your category facet crumbles into «Drills», «Drill», and «Drills & Accessories», it is worthless to customers. An LLM classifies products against a fixed category list — with a good hit rate in our projects, as long as the list is unambiguous. You define the list, not the model.

The fourth lever: searchable short descriptions. A product whose index entry is nothing but a part number and a manufacturer name is invisible to search terms like «quiet» or «for outdoor use». Two or three generated sentences from the data sheet give full-text search material — often that is all it takes.

If you are thinking about semantic search, by the way, the same applies: embeddings are built from your product texts too, and an empty description field stays empty as a vector — more on that in Semantic search. Enrichment pays into both worlds.

The most common mistake I see in enrichment projects: trying to enrich everything at once. Forty attributes for the entire catalog, before the first search query has been analyzed. What works better is a loop that starts with your customers' real search queries — that is a lesson from our project work, not a law of nature.

Every search query without results is a documented disappointment — and your most precise requirements document. Meilisearch Cloud reports the no-result rate directly in its analytics: the share of searches with zero results, which makes gaps in your content and synonyms visible. How long this data is retained depends on your Cloud plan (meilisearch.com/docs, retrieved September 4, 2026).

Honestly: with self-hosting, you do not get this analysis for free. In that case you log search queries and hit counts yourself. That is a manageable effort of a few hours, and it pays off from day one.

Sort the zero-result queries into three piles. Synonym case: the product exists, your customer just calls it something else — «Flex» instead of «angle grinder». Missing-attribute case: the customer searches for a property like «18V» that was never maintained as a field. Assortment gap: the product genuinely does not exist; that is valuable information for purchasing, but not a search task.

The first two piles are your work backlog: synonyms go into the index settings, missing attributes get filled by the LLM run. Set up as a recurring workflow, this runs weekly without anyone having to remember it — I show what such workflows look like under process automation.

Measure the same metrics before and after every enrichment round: no-result rate, click-through rate on results, facet usage. If the no-result rate does not drop after a synonym round, the pile was sorted wrong — that too is a result. In my experience, a simple dashboard with weekly values is entirely sufficient.

The one thing that matters is measuring before the first round: without a baseline, you cannot later prove what the enrichment achieved. Not to yourself, and not to your management.

This is how the loop closes: the log reveals new gaps, the next run fills them. What belongs to a good search beyond the data (placement, speed, typo tolerance) is in the article A search function for your website.

For context: a fixed number for AI enrichment would be dishonest, because the cost depends on catalog size and text volume. The calculation path, however, is simple: tokens per product times number of products times model price. You can run it for your own catalog in five minutes.

An example with prices from September 4, 2026: gpt-5-mini costs $0.25 per million input tokens and $2.00 per million output tokens (developers.openai.com, retrieved September 4, 2026). For 50,000 products with roughly 1,000 input tokens each (product text plus prompt) and 300 output tokens (structured attributes), that comes to about $12.50 for input and $30 for output: around $42.50 for the complete catalog.

Via the Batch API that halves to a good $21, because OpenAI grants a flat 50 percent discount there. Enrichment is rarely time-critical, so the longer processing time does not hurt. The smaller gpt-5-nano ($0.05 input, $0.40 output per million tokens) pushes the bill down further — in our experience it is good enough for categorization; for attribute extraction I reach for the larger model.

Calculate with your own factors: a long data sheet can run to 3,000 tokens, a terse ERP record to 200. The calculation path stays the same, only the numbers change. That is why I deliberately do not quote a flat rate.

The honest punchline: the API costs are the smallest item in the project. The real effort sits in the attribute model (which fields, which units, which required values) and in quality assurance. Both are person-days, not API cents — that too is a lesson from our projects.

An LLM that cannot find a voltage in the source text can still deliver one: a guessed 230 volts on a 400-volt device. That is worse than an empty field. The empty field makes the product invisible in one facet; the invented value makes it visible in the wrong facet. Your customer filters on 230 V, orders — and the return shipment is guaranteed.

This risk is no edge case: language models are trained to give plausible answers. For product data, plausible means: a common voltage, a typical weight, a standard material. That is exactly why invented values often only surface when someone checks them against the original source.

Put differently: an empty field is a known gap, an invented value is a hidden false promise. Facets only work if your customers can trust them.

Three rules have proven themselves in our projects. Allow empty fields: the prompt explicitly instructs the model to leave a field empty when the value is not in the source — guessing is forbidden. Use confidence thresholds: confident values go into the catalog automatically, uncertain ones land in a review queue. Spot checks by experts: for each run, someone with product knowledge checks a random sample against the original source.

How strictly you set the thresholds depends on the possible damage: with a color, an error is annoying; with an electrical rating, it is dangerous. So set the auto-approve threshold per attribute, not globally — safety-relevant fields always go through the review queue.

The last point is non-negotiable: without spot checks you train errors into your catalog, and every later run builds on them. Also define required fields per category — a cordless drill without a voltage does not count as «enriched»; it stays on the rework list.

Something similar holds for generated description texts: your brand voice needs defined boundaries too, or after the third run every product sounds like the same generic LLM prose. That is a topic of its own in the PIM world — best set the framework before the first run.

You do not need a big project to get started. My suggestion for week one: record your search log and pull the zero-result queries. Sort the top 20 into the three piles: synonym, missing attribute, assortment gap. Then you know whether your problem lies in the data, the assortment, or the search engine itself — for the latter, What is Meilisearch? is your starting point. It costs you nothing but a week of patience.

For the first enrichment run: start small. One attribute, one category, a hundred products — then a spot check, then measure. That gives you a feel for your setup's error rate before you push the whole catalog through the model.

If you want support along the way, from the attribute model to the LLM workflow to the search integration: I am happy to look at your search log and your catalog together with you. Book a free intro call — in 30 minutes we will work out which of the three piles is biggest for you, and whether an enrichment run pays off.