Magento 2 search not finding SKU: how to fix it

The problem

A typical case for a Magento 2.4.x online store with 1,000–5,000 products: Magento 2 search is not finding products by SKU, and it only works when the shopper types the product name character for character. "Gel polish 05" does not match "Gel-Polish Pastel Line 05" — the same product to a person, a total mismatch to the system. The SKU is filled in on the product page but is not searchable: "pl05" or just "05" returns nothing. The same happens with color, product line, spacing, Latin vs. Cyrillic spelling and the wrong keyboard layout.

Someone typing a SKU came from a price list or Instagram with a specific item in mind — and sees "no results". They do not open the chat, they close the tab, and the store never notices, because failed queries are not logged anywhere by default. The real share of sessions that use internal search is visible only in the GA4 site_search report, and in a 1,000–5,000 SKU catalog that is usually 15–30% of sessions with a conversion rate several times higher than browsing. Until the zero-result report exists, the volume of lost orders cannot be estimated at all.

What makes it hard

Native Magento 2 search compares the query with the name and description and handles partial matches and attributes poorly. Ticking "Use in Search" on an attribute is not enough: without its own weight a SKU match loses to a random match in the description, and the right product ends up tenth. The search engine itself depends on the release — Magento 2.4.0–2.4.3 runs on Elasticsearch 7, while 2.4.4 and newer support OpenSearch and make it the default from 2.4.6 — so the index, field weights and query parsing all have to change in the codebase. That is web development work. Part of the job can be done on a third-party module (Smile ElasticSuite, Mirasvit Search), part requires a custom analyzer; the choice depends on whether the store already runs patched core search templates.

The second constraint is another vendor: the website is usually maintained by a different team, work happens in their staging environment and repository, and the clock starts when access is granted. Reindexing also touches layered navigation, so SEO-friendly filter URLs have to be regression-tested before release. The third is data: the rebuild only works if SKU, color and product line are separate attributes. If they sit as text inside descriptions or are out of sync with the ERP or CRM that holds stock and prices, catalog cleanup comes first as a separate scope.

How we solve it

The fix is to rebuild online store search at the index and query-parsing level. The work runs in five steps:

1. 1. Weighted attribute indexing. SKU, color, product line and the Latin name become search fields with explicit boosts, so a SKU match outranks a description match. Partial matching is built on an edge n-gram analyzer in OpenSearch plus controlled fuzziness for typos: "05" shows every product with that number, "pl05" the exact one; word order does not matter. Where the catalog is standard, Smile ElasticSuite covers most of this out of the box; where it is not, the analyzer and boosts go into a custom module.
2. 2. Query normalisation. Wrong-layout correction, Latin ⇄ Cyrillic transliteration, joined and split spelling, hyphens, common typos, plus a synonym dictionary for colors and product lines in three languages.
3. 3. Handling empty results. Autocomplete from the third character with photo and price, a "no results" page with similar items from the same category, and a zero-result query report — a ready list of what the catalog or synonyms are missing, and useful input for SEO and paid search campaigns.
4. 4. Product feeds on the same attribute set. The cleaned SKU, color and line fields feed Google Shopping and marketplace exports (Rozetka, Prom.ua): feed generation, category mapping and scheduled price and stock updates, so the catalog, the search index and the ads see one source of truth.
5. 5. Sync and launch. Indexing rules target attributes, not a hand-picked product list, and stock and SKUs coming from the ERP or CRM arrive through automated integration rather than manual re-upload. Before release the build is checked on staging against a list of real queries and against existing filter URLs, then deployed in one step with a rollback plan.

What drives the price and timeline

Market range for Magento 2.4.x with a catalog of up to 2,000–3,000 products: a base search rebuild (attributes, partial matching, transliteration, keyboard layout, synonyms, autocomplete) is roughly $250–450 and 3–5 working days. With result control (synonyms editable in the admin, query report, manual pinning, a "no results" page) — $400–650 and 5–7 days. Together with Google Shopping and price-comparison feeds — $650–1,000 and 10–12 days.

The main price driver is not catalog size but attribute quality. If SKU, color and product line already live in separate fields, the job fits the low end of the range; if they are scattered across descriptions, catalog cleanup is added and the budget grows with the number of products. The second driver is how fast the vendor maintaining the website grants access. Payment is usually 50% upfront and 50% after verification on the live site, and the code stays in your repository. One honest note on our portfolio: we have no published Magento search project — the transferable mechanism here is attribute and reference-data synchronisation between a store and an accounting system, not search ranking itself.

Frequently asked questions