How the Shopware default search really works

The same questions come up again and again in the Shopware forums: Why does the search return products that don't contain the search term at all? Why does a single "e" decide whether a product is found? And why does AND search find more than OR search? The answers are in the source code. We took a close look and explain here what happens, without requiring any coding knowledge, but with enough detail that you can understand how your shop behaves.

This applies to the Shopware 6 default search (MySQL-based, without Elasticsearch/OpenSearch). We read the code of version 6.7.13.0 (the logic is unchanged up to 6.7.14.1) and tested every example below on a Shopware 6.7.14.1 shop.

Step 1: Indexing builds a dictionary

Shopware doesn't scan your product texts on every search. Instead, when indexing, it builds a keyword dictionary from all fields marked as searchable under Settings → Search. The texts are split into words⁴:

• everything is lowercased,
• words are split at spaces and punctuation,
• hyphens, underscores, dots, "+" and "@" are kept ("Montage-Feinstrickhandschuhe" stays one word),
• compound words are not split. For Shopware, "Arbeitshandschuhe" is a single word.

Every word is stored twice: once as is and once reversed ("arbeitshandschuhe" and "ehuhcsdnahstiebra"). Step 3 shows why.

Step 2: The search term becomes patterns

When a customer types "stuhl", Shopware doesn't just look for that exact word. It generates several search patterns with wildcards, where single letters may be missing or arbitrary. For "stuhl", these include¹:

This is Shopware's form of typo tolerance, and it explains why "Stuhl" also finds "Stahl". It isn't "real" fuzzy search, but it isn't zero tolerance either. The same tolerance works on word endings: in our test shop, a search for "stuhl" also returned products with the English word "steel" in their names, because "steel" ends like "stuhl" with two letters swapped ("st", any two characters, "l").

Two special cases:

• Words with digits (e.g. "m12") are searched without wildcards, but anywhere in the word: "m12" also finds "din-m12" and "m12x40".
• Very short words (up to 2 characters) are only matched as the beginning of a word.

Step 3: Beginning or end, never the middle

The patterns are checked against the dictionary twice: against the normal words and against the reversed ones². The normal patterns find words that start this way. The reversed check finds words that end this way.

What is never found: a search term that only appears in the middle of a longer word. This is exactly the case from a much-discussed forum thread:

In German, with its many compound words (Holzschrauben, Bürostuhl, Edelstahlspüle: wood screws, office chair, stainless steel sink), this is the most common reason behind "The product is there, so why doesn't the search find it?".

Step 4: Only the best 8 words count

Often many words from the dictionary match the patterns. Shopware then scores them, mainly by how similar they are to the search term (Levenshtein distance: how many letters do you have to change?). "stahl" is only one letter away from "stuhl" and therefore scores well.

Important: for OR search, Shopware then uses only the 8 best-scoring words¹. If many words score the same, which happens a lot with compound words, the alphabetical order effectively decides which 8 make it. Products that would only match through the ninth or tenth word drop out.

AND vs. OR search: the opposite of what you'd expect

Under Settings → Search you can choose whether all search words (AND) or any one of them (OR) must match. You would expect OR to always find more. In fact, the two modes also differ in how many matching words they consider³:

A merchant reported in the forum that a search for "mull" (gauze) found 34 products with OR search and 846 with AND search. That's exactly this effect.

Practical tip: if your customers often type just one word and you have many compound product names, test AND search.

Why products show up that don't contain the word

• Invisible fields: the word is in a searchable field that the storefront doesn't show, such as tags, additional search keywords, category names, properties or the manufacturer.
• Wildcard matches: a pattern like stu… matches a completely different word in one of these fields.
• Outdated index: the dictionary is written during indexing. Rebuild the search index after changing products or the search configuration.

You can see which word found a product in the live search under Settings → Search, together with the ranking points.

What changed in 6.7.14, and what didn't

• 6.7.14.0: the release notes mention better ranking when the whole search phrase appears in the product. This applies only to the Elasticsearch/OpenSearch search, not to the default search⁵.
• Variant scoring: until now, the scores of all variants of a product were added up, so products with many variants always ended up on top. This has been fixed (pull request #19139)⁶ and, according to Shopware, ships with one of the next versions. It changes the order, not which products are found.

So the beginning/end logic, the 8-word limit and the AND/OR behaviour remain.

What you can configure

Without development, under Settings → Search:

1. Searchable fields and ranking points: check which fields are searched. Invisible fields with lots of words (long descriptions, tags) often cause unexpected matches.
2. AND/OR search: try both with your most frequent search terms.
3. Minimum search term length: at 3, terms like "xl" are ignored.
4. Excluded terms: filler words that only add noise.
5. Additional search keywords per product: add important word parts, e.g. "handschuh" for "Arbeitshandschuhe". This is the most effective lever against the compound-word problem, but a lot of upkeep for large catalogues.
6. Rebuild the search index after every change.

With development: the pattern logic can be adjusted through service decoration. That touches the core flow and has to be checked with every update.

When the default search reaches its limits

For smaller catalogues with clear product names, the default search with good upkeep is often enough. It gets hard with many compound words, technical terms, product numbers and variants. Then there are three ways forward:

• Connect Elasticsearch/OpenSearch and configure the analysis yourself (e.g. decompounding, n-grams). Powerful, but it needs know-how and operations.
• Maintain search keywords systematically, e.g. via import. Helps, but scales poorly.
• Use a specialised search.

The last one is what we do with Eywora: German compound words are split using a dictionary and reduced to their word stem, so "handschuh" also finds "Arbeitshandschuhe". On top of that come semantic search for queries in customers' own words and dedicated handling of product numbers. We've written down honestly when switching pays off and when it doesn't in Default search vs. AI search. Why searches without results are so expensive is covered in The zero-results problem.

← Back to blog