In short and in plain language
This post is about the search in your shop. Business buyers often type in a part number. They expect exactly one match.
If the search finds nothing, the buyer thinks you do not sell the item. Then he orders by email or somewhere else.
The search should treat numbers and words apart. It may forgive typos in words. With numbers this is risky.
Synonyms help. These are other words for the same thing.
Check searches with no results on a regular basis. We set up the search in your shop this way.
The B2B buyer does not search — he identifies. He knows what he needs, usually more precisely than the shop itself: he types a manufacturer or part number, an EAN or the internal label from the last delivery note into the field and expects exactly one hit. If the result list stays empty, he does not conclude that the search is weak. He concludes that the range is missing — and the order goes by email to inside sales or to a competitor. How often this happens in your own shop is shown not by industry figures but by your own search data. This article treats onsite search as what it is in B2B: a revenue channel with its own engineering, its own data maintenance and one of the hardest data sources a shop owns — the zero-results log.
Key takeaways
- A buyer who types a correct part number and lands on an empty result page reads it as a statement about your range and switches channel. Whether and how often this happens in your own shop can be read from the zero-results log.
- A B2B catalog serves six input types: your own item number, the manufacturer part number, the customer's own item number, EAN or GTIN, technical specs such as M8x40 A2, and shop-floor vernacular. Each has its own data source and needs its own index treatment.
- Numbers and words belong in separate index fields: the number field without tokenization or stemming, the full-text field analyzed. Shopware preserves five special characters by default (Shopware Developer Documentation); the slash is missing from that list.
- Typo tolerance belongs on words, not part numbers, where a single character encodes the variant. Search exactly first, then offer narrow tolerance as a question after a zero result. Only 23 percent (Nielsen Norman Group) of search suggestions get selected.
- Synonym lists close the language gap between catalog terms and shop-floor wording, regional variants and legacy order names. Zero results caused by permissions on blocked items should not pass silently but return an explicit note plus a route to the responsible contact.
- The zero-result log is the toughest demand data a shop owns: export it weekly, normalize spellings and sort every line into one of three categories — data gap for the data team, language gap for catalog editing, assortment signal for purchasing.
The buyer does not search, he identifies
Onsite search in B2B is not a discovery tool, it is an addressing tool. The buyer in technical trade, in maintenance or in goods receipt has a concrete requirement and a source next to it: a data sheet, a delivery note, an open ERP window. Out of that comes a string of characters. Nielsen Norman Group observes in its usability studies that more than half (Nielsen Norman Group) of users are search-dominant: they head straight for the search field after the page loads instead of working through the navigation. Only about one fifth (Nielsen Norman Group) are link-dominant, the rest show mixed behaviour. In a B2B catalogue full of known part numbers this ratio shifts even further towards the search field — there, search is the actual landing page.
This is precisely where, in our experience, many shops show weaknesses. Shop search is often tuned for consumer behaviour: it splits input into words, reduces terms to their stems and forgives typos. For terms such as "screw" or "glove" that helps; for a string such as HTG-4711/02 it can have the opposite effect. Whether your own search is affected can be settled without an industry comparison: with a handful of real part numbers from the catalogue, typed in exactly as they appear on delivery notes and data sheets.
The view by query type is revealing. Exact search is technically the easiest case, because the string is already in the catalogue. Abbreviation and symbol searches are more demanding, which is exactly the pattern of a part number with a hyphen, dot or slash. On top of that come compatibility searches ("fits model X") and feature searches, which require maintained attributes in the index. Those are exactly the query patterns that define a B2B range — and a B2B portal that does not serve them loses the buyer at the very first interaction.
Zero results is a statement about your range
The query types a B2B catalogue has to master
Before thinking about relevance tuning, a sober inventory pays off: what does the buyer actually type? In B2B those are rarely aspirational terms and almost consistently identifiers from different system worlds. Each type has its own data source, its own notation and its own technical treatment. A catalogue that only knows its own part number covers perhaps a third of real-world input.
Your own part number
The number from your ERP — with and without separators. If you maintain "HTG-4711/02", then "HTG471102" and "htg 4711 02" have to resolve to the same item, without the number falling apart in full text.
Manufacturer number
The MPN is printed on the component and in the data sheet, not in your catalogue. It is frequently the very first input and needs to be maintained per item as its own searchable field.
Customer part number
The number under which your customer carries the item in his own ERP. It is customer-specific, belongs in a customer-group or account-bound field, and is the strongest loyalty feature there is.
EAN and GTIN
From the scanner, from goods receipt, from catalogue exchange. Purely numeric, without separators, and as a rule unambiguous — the ideal candidate for jumping straight to the product page.
Technical attributes
"M8x40 A2", "DN50 PN16", "1.5 mm² H07V-K": dimension, material and standard in one string. These inputs need structured attributes in the index, not just running text in the description.
Everyday language
The shop-floor term instead of the catalogue term — "pipe wrench" instead of "corner pipe wrench", "grinder" instead of "angle grinder". No technology closes this gap, only a maintained synonym list.
The order of these types is no accident: it roughly matches hit precision. Numbers are unambiguous and demand a single hit, attribute searches expect a filtered list, everyday-language input a sorted selection. Sending all six types through the same full-text search inevitably means optimising against yourself — what helps number search hurts word search and vice versa. This is most visible in the spare parts business, where compatibility and number coincide; how to model that case cleanly is shown in the article on the digital spare parts catalogue in aftersales. In technical trade, all six types occur side by side in practice.
Separating number search from full-text search
The most important architectural step is unspectacular: numbers and words belong in separate index fields with separate analysis chains. A full-text field should split, normalise and be generous — it lowercases, removes stopwords, reduces word forms to their stem and tolerates typos. A number field should do the opposite: keep the string whole, not split it at separators, apply no stemming and rank exact hits above everything else. Uniting both goals in one field produces a compromise that disappoints both sides.
In Shopware the critical point can be named concretely. The platform maintains a list of special characters preserved during search in config/packages/shopware.yaml under shopware.search.preserved_chars; five characters are preset (Shopware Developer Documentation): hyphen, underscore, plus, dot and the at sign. The slash is not among them. A part number such as PT-64/515 is therefore split into PT, 64 and 515 when split search terms are active (Shopware Developer Documentation) — with the result that the search finds every item containing a 64 somewhere, and the item actually meant drowns in the list. With splitting disabled, PT-64/515 is searched as a whole. Anyone carrying slashes in part numbers has to extend the list:
shopware:
search:
# Default: ['-', '_', '+', '.', '@']
# Add the slash when part numbers contain it (PT-64/515)
preserved_chars: ['-', '_', '+', '.', '@', '/']
# Rebuild the index after every change to analysis or mapping:
# bin/console es:indexOn this basis the actual search logic emerges: an upstream query router checks the input against the known number patterns of the range. If it matches, the request first runs as an exact search against the number fields — own part number, manufacturer number, EAN, customer part number. If exactly one hit comes back, jumping straight to the product page is the right answer, not a list with one element. Only when no number pattern is detected, or the exact search stays empty, does full-text search with synonyms and tolerance take over. This separation is not a backend configuration task but Shopware development on the search index and the query logic.
The silent mode error
Typo tolerance: mandatory for words, risky for numbers
Fuzzy matching is the feature most often switched on across the board — and most often wrongly. For words it is indispensable: someone looking for "angle grinder" who types "angle grindr" should get the tool. For numbers the logic reverses. Part numbers differ systematically in exactly one character, because that character encodes the variant: length, thread, material, packaging unit. A tolerance of one character turns an unambiguous request into a list of sibling items — and in the worst case turns one hit into a wrong order that comes back as a return.
| Aspect | Number field (keyword) | Full-text field (analyzed) |
|---|---|---|
| Tokenisation | none — string stays whole | split into word tokens |
| Separators | preserved (preserved_chars) | treated as word boundary |
| Stemming | disabled | active, language-dependent |
| Stopwords | disabled | removed, language-dependent |
| Typo tolerance | off, or only as a second pass | active, one to two characters |
| Synonyms | genuine number aliases only | range language, regionalisms |
| Ranking | exact hit beats everything | relevance from field boosts |
| Goal on a single hit | jump straight to product page | result list with refinement |
The workable route is a two-stage approach instead of a global switch. Stage one searches the number exactly and without tolerance. If it stays empty, stage two runs with narrow tolerance — but with a different presentation: not as a hit, but as a query back ("Did you mean HTG-4711/03?"). That preserves unambiguity without leaving the buyer stranded on a genuine transposed digit. That suggestions are no free lunch is shown by Nielsen Norman Group: in their tests only 23 percent (Nielsen Norman Group) of the search suggestions offered were actually selected. Suggestions therefore do not replace working hit logic — they complement it.
Synonyms and the language of the range
The second large class of gaps is linguistic. The catalogue speaks manufacturer and standards language, the buyer speaks shop floor. Between "corner pipe wrench" and "pipe wrench", between "angle grinder" and "grinder", between "cable tie" and "zip tie" lies not a technical but a lexical problem. It cannot be solved by fuzzy matching or by better ranking, because the strings have nothing in common. The only robust answer is a maintained synonym list — and it does not emerge at the drawing board but from the real input of your customers.
- Shop-floor term versus catalogue term: colloquial and brand-derived generic terms that the range carries under a technical name. The richest source is the zero-results log.
- Regionalisms: "spanner" and "wrench", "hex key" and "Allen key", national variants in exporting ranges.
- Legacy order labels: terms and number ranges from the predecessor system that customers keep using after a migration — they belong in the index as aliases, not in the bin.
- Abbreviations and notation variants: "SS" and "stainless steel" and "A2", "1.5" and "1,5" — plus units with and without a space.
- Compounds: German compounds do not fall apart by themselves. "Edelstahlschraube" should find items maintained as "Schraube, Edelstahl" — decompounding in the index or a maintained alias helps here.
- Foreign-language input: in internationally used catalogues, English generic terms appear in the German shop and vice versa — a question of language configuration and per-language synonym maintenance.
This maintenance is range work, not an IT task — it belongs to the people who know the catalogue. It does, however, presuppose that the product data has a structure for synonyms to dock onto. Official statistics show that companies are moving here: in 2025, 26 percent of companies in Germany with at least 10 employees used artificial intelligence (Destatis), and 35 percent of them used it to generate natural language (Destatis) – the technology that makes automated product copy possible. Where AI was considered but not yet introduced, 45 percent cite incompatibility with existing equipment, software and systems as a reason and 44 percent cite difficulties with the availability or quality of the required data (Destatis). Where the data basis is sound, synonym maintenance is a matter of hours per month; where it is missing, a clean PIM integration comes first — the fundamentals are covered in the article on product data and data quality in B2B.
Synonyms are range knowledge, not a search feature
Customer groups, blocked items and the index
In B2B the catalogue is rarely the same for everyone. Customer groups see different ranges, individual items are blocked for certain customers, new products initially run for selected accounts only. For search this creates two separate questions that are readily conflated: what is in the index, and what may this user see? The clean answer: the index holds the entire range with its visibility attributes, and permission is applied as a filter at query time — not through separate indices per customer group, which get more expensive with every new group.
That carries an uncomfortable consequence which has to be decided deliberately: a blocked item produces a zero-results page for the affected customer — and that, as above, is a statement about your range. Here a silent zero-results page is the worst of all options. An explicit response is better: the item exists but is not released for this account, together with a route to the responsible contact. That turns a dead end into a touchpoint. Which role and permission structures this requires is described in the article on B2B customer groups, roles and permissions in Shopware.
A second group of restrictions is legal rather than commercial. Dual-use goods, hazardous substances or country-related restrictions must not be orderable for certain recipients — and wherever sanctions screening applies, search is the first place it becomes visible. The same rule holds: the check belongs in the index as an attribute and in the query as a filter, so that result list, product page and checkout make the same statement. How to model this operationally is covered in the article on sanctions screening and export control in the B2B shop.
A zero-results page caused by a permission is not a search problem but a communication problem. The buyer should learn that the item exists — and whom to ask.
The zero-results log as the hardest data source
No other instrument in the shop delivers demand data as undistorted as the list of search queries without results. Unlike surveys, personas or range planning, it contains exclusively real, purchase-driven input from paying customers — phrased in their own language, at the moment of need. Nielsen Norman Group observed in its studies that 27 percent (Nielsen Norman Group) of failed tasks were down to users being unable to locate suitable items although those items were available on the site. Those are exactly the cases sitting in the zero-results log. Every line in it belongs to one of three categories — and each category has a different addressee.
Data gap
The item is in the range, but the number entered is not in the index — manufacturer number missing, EAN not maintained, separator split it apart. Addressee: data maintenance and index mapping. This is the most frequent and fastest-fixed category.
Language gap
The item is there, the term is missing. The customer uses the shop-floor word, a legacy order label or a regionalism. Addressee: synonym list and range language. This is where next month's lexicon supply comes from.
Range signal
The item genuinely is not in the range — but it is being asked for, repeatedly, by paying customers. Addressee: purchasing and category management. This is the most valuable category, because it describes revenue that does not exist yet.
The value of this analysis lies in its frequency. A zero-results report published once a quarter is a report; one that lands on the desk every Monday is a working tool. The preparation should be sorted by frequency and normalise queries so that "htg 4711 02", "HTG-4711/02" and "HTG471102" appear as one entry. Splitting by customer group is also worthwhile: a zero-results page for an existing customer under an annual agreement weighs more than one for an anonymous visitor. It also pays to look at queries with hits but without clicks — they are the silent variant of the same problem.
A workflow that sustains itself
Search analytics: the metrics that explain revenue
Search is rarely measured because it is regarded as a control element rather than a channel. Treat it as a channel and the discussion changes: users who search are demand-driven and typically convert well above the visitor average. That makes the same set of metrics worthwhile that one would set up for any other channel as a matter of course. Five metrics are enough to start.
- Search share of revenue: what share of order value comes from sessions with at least one search? This number answers the budget question — and in B2B catalogues it regularly turns out higher than expected.
- Zero-results rate: share of searches without a result, separated into number and word searches. Number zero-results are almost consistently data gaps, word zero-results more often language gaps.
- Click position: at which rank do people click? Rank one on number searches is the target. A high average click position betrays the split part number that returns too many rather than too few hits.
- Refinement rate: how often does the same user rephrase the query? Every refinement is a failed first attempt — and rephrasing succeeds less often than one assumes.
- Search-to-order: share of searches that lead to an order in the same session. The metric everything else hangs on — and the only one that justifies the effort of synonym maintenance.
These metrics have a pleasant property: they are comparable over time and react quickly to interventions. Add a synonym group and the zero-results rate for those queries drops within days. That search UX can be improved overall is shown by Nielsen Norman Group's long-term observation: the measured success rate for shop search rose from 64 percent (Nielsen Norman Group) in 2000 via 74 percent (Nielsen Norman Group) in 2011 to 92 percent (Nielsen Norman Group) in 2017 — the result of continuous work, not of a single tool. How these values fit into a bigger picture is covered in the article on B2B shop analytics and KPIs. Anyone also watching how AI assistants read catalogues will find the context in the article on product search and AI research in B2B procurement.
Building the index for large catalogues
Beyond a certain catalogue depth, search becomes an infrastructure question. A database-backed search works reliably at a few thousand items; at six-figure item counts with variants, customer-specific prices and several number ranges per item it hits limits — both in response time and in the expressiveness of the query. Shopware integrates OpenSearch for this; the platform treats both systems the same way (Shopware Developer Documentation). The gain lies less in speed than in control: custom analyzers per field, field boosts, synonym filters and the clean separation of number and full-text fields only become configurable with it.
Two settings deserve particular attention. The first is n-gram splitting, which enables partial word search: the presets are a minimum length of four and a maximum length of five characters (Shopware Developer Documentation), adjustable via SHOPWARE_ES_NGRAM_MIN_GRAM and SHOPWARE_ES_NGRAM_MAX_GRAM. Values that are too small bloat the index and produce accidental hits, values that are too large prevent partial word search. The second is language analysis: stopwords, stemming and the decompounding of German compounds are configured per language and decide whether "Edelstahlschrauben" finds the item "Schraube, Edelstahl". Both settings only take effect after a full rebuild of the index via bin/console es:index (Shopware Developer Documentation).
From this follows the operational requirement: rebuilding the index is a plannable, repeatable procedure and belongs in the same operating routine as deployments and updates. Changing analyzers in live operation without rebuilding the index produces a search that answers according to old rules — a fault pattern that is hard to reproduce. The same discipline applies to platform upgrades, where mapping or analysis chain may change; the context is provided in the article on upgrade and maintenance strategy for B2B shops. And because the number fields come from ERP and PIM, the quality of the index hangs directly on the integrations that deliver this data.
Search relevance is engineering work
Onsite search cannot be bought in and cannot be set up once. It consists of three parts that have to be maintained separately: the catalogue with its numbers and attributes, the index with its fields and analyzers, and the query logic that decides when to search exactly and when to search tolerantly. No part works without the others — a perfect synonym list is useless if the part number falls apart in full text, and the best index stays ineffective if the manufacturer number is not maintained in the ERP at all. Where a shop search fails to cover its users' needs, in our experience this is rarely down to missing technology and mostly down to missing ownership.
The entry point is smaller than the task sounds. It starts with one week of the zero-results log, an honest classification of the entries into data gap, language gap and range signal, and a check of one single technical question: what happens to a part number containing a hyphen and a slash? As a rule the answers produce a manageable list of concrete interventions — add fields, separate the analysis chain, put a router in front, maintain synonyms. Which of them make the difference in your range is what we clarify in an e-commerce consulting engagement; the implementation on index and query logic is Shopware development against a concrete, measurable goal: that the number typed in returns exactly one hit.
PT-64/515 into its components and looks for PT, 64 and 515 — the item meant then drowns in a long list. On top of that, Shopware preserves only five special characters by default (Shopware Developer Documentation): hyphen, underscore, plus, dot and the at sign. The slash has to be added via preserved_chars. The robust solution is a dedicated number field without tokenisation, queried exactly and ahead of full-text search.Related Articles
Ordering on Behalf of Customers: Inside Sales in B2B Shops
Since Shopware 6.6.5.0, inside sales can order in the customer account. How permissions, logging, privacy and the order channel work for phone and fax orders.
Where Order Documents Live and How Long They Stay
Order confirmation, delivery note, invoice and price list in the customer account: which retention period applies, when it starts and where the files may sit.
Showing Declarations of Performance Before Checkout
Regulation (EU) 2024/3110: how the declaration of performance and conformity, CE details and safety information become visible in the shop before the contract binds.