Magento search doesn't find products by SKU, colour or partial name

The problem

Out-of-the-box Magento 2 search in many stores effectively works only on a full match against the product name. A shopper types "sv01", "gel polish 01" or "pink gel polish" and gets "no results", even though the item is in the catalogue and in stock. Any small variation breaks it the same way: a hyphen instead of a space, words run together, Cyrillic instead of Latin, a typo, the wrong keyboard layout. To a human these are the same product; to the system they are different queries leading nowhere.

The expensive part is that this loses the hottest traffic. People use the search box when they already know what they want to buy: they came from a category page, an email campaign, or Instagram where they saw the SKU. An empty result page sends them to a competitor with purchase intent intact. With a catalogue of 1,500–3,000 SKUs, search is typically used in 10–30% of sessions, and those sessions convert 2–3 times better than the site average — so this is a noticeable share of revenue. A second problem: failed queries are logged nowhere, so the store owner never sees what the catalogue is missing.

What makes it hard

Several things prevent doing this head-on. The site is usually already live and maintained by another agency, so access to the repository and the staging environment goes through them — that is a separate step with its own lead time. The catalogue templates and the already configured layered navigation filters must stay untouched: they work and the client is happy with them, and any change to the results template means re-testing the whole catalogue.

The second constraint is data. SKU, colour, Latin-script name and product line are often already filled in as attributes, but they never reach the search index — or reach it with no weighting, so a match inside the description outranks a match on the SKU. If attributes are only partially filled or written in different formats, they have to be normalised first; otherwise the search configuration just cements the mess. Third: the solution has to be rules-based, not a hand-maintained list, because new products are added daily and nobody will reconfigure search for each new SKU.

How we solve it

First, indexing attributes with weights. SKU, colour, product line and the Latin-script name become full search fields, with a SKU match weighted higher than a match inside the description. The query "01" returns every item with that numbering; "sv01" returns the exact product card, even if the code does not appear in the product name. We add partial matching: search across word fragments and across several words in any order, so "gel polish 01" and "gelpolish 01" return the same results.

Second, query normalisation before the query hits the index. Keyboard layout correction (when someone types Latin characters instead of Cyrillic), two-way transliteration ("samer vayb" → Summer Vibe), joined and separated spellings, common typos. On top of that, a synonym dictionary built for the store's niche: spelling variants of category names, colour and product-line names in Ukrainian, Russian and Latin script.

Third, work on the results themselves. Autocomplete from the third character typed: photo, name, price, direct link to the product page. Instead of a dead-end "nothing found" page — similar items from the same category plus bestsellers. Separately, a search query report is collected: what people look for and what they fail to find — a ready-made list of gaps in the catalogue and in the synonym set. Everything is tested against the real catalogue using the client's own list of queries plus our own set of cases; work is done in staging and released to the live site in one step after verification. The extended option adds synonym editing from the admin panel without a developer, manual pinning of chosen products to the top for a given query, rules for seasonal queries and promotions — and, if needed, a marketplace feed built on the same normalised attributes.

What drives the price and timeline

Market range for Magento 2 with a catalogue of up to ~3,000 SKUs: a basic search rebuild (attributes in the index, query normalisation, partial matching, synonyms, autocomplete) — roughly USD 200–350, 3–5 working days. The version with merchandising control over results, a query report, self-service synonym editing and post-launch support — USD 300–500, 5–7 days. If a marketplace feed with category mapping and automatic stock and price updates is built in the same stage — USD 500–750, 10–12 days.

The main price driver is not the number of products but the state of the attributes. If SKU, colour and product line are already filled in consistently across all product cards, the work is exactly what is listed above. If they need to be normalised or extracted from descriptions, a separate data preparation stage is added and the budget grows by 1.5–2×. The second factor is how quickly the incumbent agency hands over access: the timeline should be counted from the day staging and the repository are available, not from the day the contract is signed.