Fixing misspelled Search queries using working queries

Every e-commerce search box eventually meets the same enemy: typos. A user types “runing shoes” or “bluetoth speaker”, and if your system can’t recover, that’s a lost sale. Most teams reach for one of a few standard fixes - each with real limitations.

Why the Usual Fixes Fall Short

Fuzzy matching against the catalog. The fuzziness parameter lets queries match product titles within an edit distance of 1 or 2. It’s easy to enable and catches obvious slips. But it optimises against the wrong corpus. Product titles are written by merchandisers, not shoppers — full of brand names, model numbers, and marketing phrasing that customers rarely type. “Sweter” may resolve to “sweater” or “sweeter”, won’t reliably resolve to the right item just because some listing happens to contain a nearby string; the catalog wasn’t built to model how people search, so fuzzy matches against it are essentially guesses dressed up as corrections.

The built-in suggester (e.g., phrase or term suggesters). These generate candidate corrections from the indexed terms themselves - meaning they inherit the same catalog-language bias, plus they tend to suggest whatever term is most frequent in the index, not whatever term shoppers actually intended.

Generic spelling dictionaries. Off-the-shelf dictionaries (aspell-style corpora, general English word lists) know that “recieve” should be “receive”, but they have no concept of product vocabulary, brand names, or category-specific slang. They’ll “correct” a legitimate product term into an unrelated dictionary word, or fail silently on domain-specific misspellings entirely.

The common thread: all three approaches try to infer intent from data that doesn’t represent the customer’s language. What’s missing is a model of how people actually search — which is sitting in your query logs the whole time.

Correct against queries, not products

A more reliable approach flips the source of truth from the catalog to real search behavior:

1. Select top-converting queries from logs. Pull queries that reliably lead to clicks, add-to-carts, or purchases — this is your “known good” query vocabulary.
2. Index those queries as keyword. Store them in a lightweight side index, separate from the product catalog, preserving exact strings.
3. On low or zero results, search this query index for low edit-distance matches and re-run the user’s search using the corrected query instead of the catalog.

The precision gain comes from matching against the right vocabulary.

A few examples

The german typo “wane” is matching “wand” (wall) instead of the likely more frequent “wanne” (tub):

But Germans are not alone, consider some english ambiguous cases:

• “sweter” is edit-distance 1 from both sweater and sweeter.
• “blendr” is edit-distance 1 from both blender and blander.
• “toastr” is edit-distance 1 from both toaster and toastier.

A catalog or dictionary has no way to break these ties — both candidates are equally plausible strings. But when you match against top-converting queries, the ambiguity mostly resolves itself: “sweater” appears constantly as a converting search term, while “sweeter” essentially never does, because nobody searches an e-commerce site for the word “sweeter” on its own. The frequency and conversion signal embedded in real query logs acts as a prior that pure string-distance math can’t provide.

This also means the correction candidate pool shrinks to queries people actually type with purchase intent, so a low-frequency edit-distance neighbor doesn’t get promoted over the obviously correct, converting query. The system isn’t just “spelling aware” — it’s shaped by demand.

On cases where no similar popular query is found, a catalog fallback can help.