Part Numbers and SKUs: Search for the Shopper Who Already Knows
Most site search is built for shoppers who describe what they want. A large share of B2B and parts buyers type a code instead, and a search engine that treats a SKU like a sentence fails them on the first keystroke.
A shopper who types a part number is not browsing. They know exactly what they want, they have the code from a manual, a previous order, or a label, and they expect the search box to return that one product. The engine that treats the code like a sentence, splitting it into tokens, stemming it, and matching it fuzzily against descriptions, will return a page of near misses and bury the exact product under them. The fix is exact-match priority: when a query matches a SKU, a part number, or a manufacturer code exactly, that product should rank first, ahead of every fuzzy match, and the result should say why it is first.
Why codes break a normal search engine
A normal search engine is built for words. It tokenizes the query, removes stop words, stems the terms, and ranks by relevance, which is the right behavior for a shopper who types wireless headphones. It is the wrong behavior for a shopper who types 8849-XT-2210, because the code is not a sentence and its tokens are meaningless apart. Stemming a part number destroys it. Splitting it on hyphens creates fragments that match other products. And a fuzzy match that tolerates a typo in a word is a disaster in a code, where one wrong character is a different part entirely.
The failure is silent. The shopper does not get an error. They get a results page full of products that look similar and a search that feels broken, and they conclude the store does not carry the part. In B2B, where the buyer often has a purchase order and a deadline, that conclusion sends them to a competitor's site or to a phone call, both of which cost the store more than the search ever did. The shopper who types a code is the highest-intent visitor the store gets, and the search engine is the one place that should never fail them.
The scale of the problem is larger than most stores realize. In industrial, automotive, and electronics catalogs, a substantial share of search traffic is code-based, and those searches convert at rates far above descriptive searches, because the shopper has already decided. A store that measures search by query volume will miss it. A store that measures search by revenue per query will see it immediately.
What exact-match priority looks like in practice
The first rule is to detect the code before the engine does anything else. A query that matches the pattern of a SKU, a part number, or a manufacturer code, alphanumeric with hyphens or a known prefix, should be checked against the product identifier fields first: SKU, part number, manufacturer part number, UPC, and any alias the store keeps. If there is an exact match, return it first, with a clear label that this is the exact part, and show the other matches below it, not instead of it.
The second rule is to protect the code from the engine's normal behavior. Do not stem it, do not split it on hyphens unless the split is also checked as an exact match, and do not apply typo tolerance to it unless the tolerance is one character and the suggestion is labeled as a possible match, not presented as the product. A shopper who types a code with a typo needs a did you mean, not a wrong product. The suggestion should show the code, the product name, and the reason it is a suggestion, so the shopper can judge whether it is the right one.
The third rule is to index the aliases. A part often has three names: the manufacturer's part number, the distributor's SKU, and the store's internal code, and the shopper may type any of them. The search index should carry all three, mapped to the same product, so that a query for any code returns the right product. This is the synonym problem in code form, and it is solved the same way: a curated mapping, maintained by the merchandising team, not a learned guess.
How to know whether code search is working
Measure it separately from descriptive search. Code searches should have a near-zero zero-results rate, a first-result click rate far above the site average, and a conversion rate that reflects the intent behind the query. A code search that returns zero results is a data problem, a missing alias or a missing product, and it should be fixed in the index, not in the ranking. A code search that returns the wrong product first is a ranking problem, and it should be fixed by the exact-match rule.
Read the search log for codes specifically. The queries that look like codes, the ones with hyphens, digits, and capital letters, are the ones to audit first, because they are the ones the engine is most likely to get wrong. And test the engine the way a buyer would: type the ten most-ordered part numbers into the search box and see what comes back first. If the right product is not first for all ten, the engine is failing the store's best customers, and the fix is not more relevance tuning. It is an exact-match rule that should have been there from the start.
Frequently asked questions
Why does site search fail on part numbers?
Because a normal search engine is built for words. It tokenizes the query, stems the terms, and matches fuzzily, which is right for wireless headphones and wrong for 8849-XT-2210, where one wrong character is a different part. The code should be checked against SKU and part-number fields before the engine does anything else.
Should a SKU search use typo tolerance?
Only with a label. A one-character typo in a code can be a different part, so the engine should show the suggestion as a possible match with the code and product name visible, not present it as the product. The shopper should judge whether it is the right one.
What product identifiers should search index?
SKU, part number, manufacturer part number, UPC, and any alias the store keeps. A part often has three names, the manufacturer's number, the distributor's SKU, and the store's internal code, and the shopper may type any of them.
How do I test whether code search works?
Type the ten most-ordered part numbers into the search box and see what comes back first. If the right product is not first for all ten, the engine is failing the store's best customers, and the fix is an exact-match rule, not more relevance tuning.