Suchrelevanz im Shop: Treffer statt Trefferflut

Der Suchschlitz ist die Strecke mit der höchsten Kaufabsicht im Shop und zugleich meist die am schlechtesten gepflegte. Wer tippt, will kaufen, nicht stöbern. Trotzdem decken 56% der Shops den Suchbedarf ihrer Nutzenden nicht ausreichend ab (Baymard Institute). Das Problem ist selten die Suchmaschine, sondern ihre Suchrelevanz-Konfiguration: Eine Mehrwort-Anfrage wie „blaue Laufschuhe“ liefert entweder tausende Treffer oder gar keine, deutsche Komposita zerfallen unkontrolliert, und Produktcodes verschwinden zwischen Ziffernfolgen. Dieser Leitfaden zeigt, wie Sie die OpenSearch-basierte Suche eines Online-Shops an den entscheidenden Stellschrauben justieren: minimum_should_match, Dekomposition, Synonyme, Gewichtung exakter Treffer, Sonderzeichen-Handling, Autocomplete und Variantensuche. Und wie Sie die Wirkung messen, statt sie zu behaupten.

Warum die interne Suche die wichtigste Strecke im Shop ist

Wer die Suche benutzt, hat sein Bedürfnis bereits in Worte gefasst. Das ist ein qualitativ anderer Zustand als das Durchklicken einer Kategorie. Entsprechend hoch ist der Anspruch an die Ergebnisliste, und entsprechend teuer ist jeder Fehlgriff. In den Nutzertests des Search-UX-Benchmarks 2026 bevorzugte rund die Hälfte der Teilnehmenden die Suche als bevorzugte Strategie zur Produktfindung (Baymard Institute). Der Benchmark umfasst über 10.000 Performance-Bewertungen über 170 Sites und Apps (Baymard Institute) und ist damit eine der breitesten öffentlich dokumentierten Datengrundlagen zum Thema.

Die Ergebnisse sind ernüchternd: 46% der Desktop-Shops, 58% der mobilen Shops und 64% der Apps erreichen bei der Such-UX nur eine mittelmäßige oder schlechtere Bewertung (Baymard Institute). Bemerkenswert ist außerdem, dass die Suche längst nicht nur für Produkte benutzt wird: 34% der Testpersonen suchten auch nach Nicht-Produkt-Inhalten wie Rückgabebedingungen (Baymard Institute). Eine Suche, die ausschließlich den Produktindex kennt, läuft bei einem Drittel der Anfragen ins Leere.

Noch aufschlussreicher ist die Aufschlüsselung nach Anfragetyp. Sie zeigt, dass die Suche nicht pauschal schlecht ist, sondern an bestimmten, klar benennbaren Klassen von Anfragen scheitert. Genau diese Klassen lassen sich mit Konfiguration adressieren.

Das Muster ist eindeutig: Je weiter sich eine Anfrage vom exakten Produktnamen entfernt, desto häufiger versagt die Suche. Exakte Suchen scheitern nur in 12% der Fälle, Abkürzungs- und Symbolsuchen dagegen in 54% (Baymard Institute). Der Bereich mit den größten Verlusten ist damit auch der, den eine saubere Analyzer- und Relevanz-Konfiguration am direktesten verbessert.

minimum_should_match: Wie viele Begriffe müssen treffen?

Die folgenreichste einzelne Einstellung einer Mehrwort-Suche ist minimum_should_match. Der Parameter legt fest, wie viele der optionalen Klauseln einer Suchanfrage ein Dokument mindestens erfüllen muss, um überhaupt in der Ergebnisliste zu erscheinen (OpenSearch-Dokumentation). Bei „blaue Laufschuhe“ entstehen drei Terme. Steht minimum_should_match auf 1, genügt ein einziger davon: Jedes blaue Produkt und jeder Schuh landen in der Liste. Das Ergebnis ist die klassische Trefferflut, in der die tatsächlich passenden Artikel untergehen.

Die Standardwerte sind dabei nicht intuitiv. Enthält eine Query eine must- oder filter-Klausel, ist der Default 0. Besteht eine Boolean-Query dagegen ausschließlich aus should-Klauseln, liegt der Default bei 1, es muss also mindestens eine Klausel treffen (OpenSearch-Dokumentation). Wer nichts konfiguriert, betreibt seine Suche faktisch mit ODER-Logik, und genau das erklärt die meisten Trefferfluten in der Praxis.

OpenSearch akzeptiert für den Parameter mehrere Wertformen, die sich in ihrer Wirkung deutlich unterscheiden:

Wichtig ist das Rundungsverhalten: Prozentwerte werden auf die nächste Ganzzahl abgerundet. Ergibt die Rechnung weniger als 1, wird 1 verwendet; liegt sie über der Zahl der optionalen Klauseln, wird auf diese Zahl begrenzt (OpenSearch-Dokumentation). Bei drei Termen und 75% ergibt sich also 3 × 0,75 = 2,25, abgerundet 2. Von „blaue Laufschuhe“ müssen damit zwei der drei Begriffe treffen: eng genug, um die Trefferflut zu beenden, weit genug, um bei einem Tippfehler oder einem ungewöhnlichen Attribut nicht sofort auf null zu fallen.

Genau deshalb ist die Kombinationsform der praxistauglichste Startwert. Ein Ausdruck im Format n<p% bedeutet: Ist die Zahl der optionalen Klauseln kleiner oder gleich n, müssen alle Klauseln treffen; liegt sie darüber, muss der Anteil p treffen (OpenSearch-Dokumentation). 2<75% verlangt bei ein- und zweiwortigen Anfragen also Vollständigkeit und lockert erst ab drei Termen. Das entspricht dem tatsächlichen Nutzerverhalten: Kurze Anfragen sind präzise gemeint, lange enthalten oft ein Attribut zu viel.

{
  "query": {
    "bool": {
      "should": [
        { "match": { "name": "blaue" } },
        { "match": { "name": "laufschuhe" } },
        { "match": { "properties.name": "blau" } }
      ],
      "minimum_should_match": "2<75%"
    }
  }
}

Shopware hat diese Stellschraube mit 6.7 in die Suchkonfiguration geholt. Seitdem lässt sich konfigurieren, wie viele Begriffe einer Suchanfrage treffen müssen, damit Mehrwort-Anfragen intelligenter bewertet werden. Als Beispiel nennt der Hersteller ausdrücklich Suchen wie „blaue Laufschuhe“, die dadurch relevantere Ergebnisse liefern und zu breite Treffermengen reduzieren (Shopware AG). Technisch arbeitet die Suchlogik mit einem Strictness-Wert auf einer Skala von 0,0 bis 1,0: 0,0 verlangt mindestens einen Term (ODER), 1,0 alle Terme (UND), Zwischenwerte fordern ceil(numberOfTerms × strictness) Treffer (Shopware Developer Documentation). In der Oberfläche stehen dafür fünf vordefinierte Strictness-Stufen bereit, die die frühere reine AND/OR-Umschaltung ablösen (Shopware AG).

Deutsche Komposita zerlegen jede naive Suche

Das Deutsche bildet Komposita, das Englische nicht. „Lederjacke“, „Fahrradschlauch“ oder „Edelstahlspüle“ sind ein einziges Token, und eine Suche nach „Jacke“ findet „Lederjacke“ ohne Zusatzarbeit schlicht nicht. Für Shops mit deutschsprachigem Katalog ist das kein Randthema, sondern der häufigste Grund für unerklärliche Null-Treffer bei eigentlich vorhandenen Produkten.

OpenSearch löst das mit Decompounder-Token-Filtern, die besonders für Sprachen mit häufigen Komposita wie Deutsch, Niederländisch und Schwedisch gedacht sind (OpenSearch-Dokumentation). Zur Wahl stehen zwei Verfahren, die sich in Geschwindigkeit und Genauigkeit unterscheiden:

Shopware setzt in seiner erweiterten Suchkonfiguration auf die Wörterbuch-Variante: Seit Commercial 7.12.0 zerlegt ein dictionary_decompounder zusammengesetzte Substantive wie „Lederjacke“ zur Indexzeit anhand pflegbarer Wörterbücher (Shopware Developer Documentation). Der entscheidende Punkt steht im Kleingedruckten: Der Filter greift ausschließlich im Index-Analyzer, nicht bei den Suchanfragen selbst (Shopware Developer Documentation). Wer das übersieht, sucht die Wirkung an der falschen Stelle.

advanced_search:
    analysis:
        analyzer:
            sw_german_custom_analyzer:
                type: custom
                tokenizer: standard
                filter: ['lowercase', 'my_stopwords_filter', 'my_decompounder']
        filter:
            my_decompounder:
                type: dictionary_decompounder
                word_list: ['leder', 'jacke', 'fahrrad', 'schlauch']

Die Wörterbücher werden nicht in der YAML gepflegt, sondern über die Admin-API als Entitäten: advanced_search_compound_dictionary für die Grundwörter und advanced_search_stopword_dictionary für eigene Stoppwörter (Shopware Developer Documentation). Der Analyzer wird über den Parameter language_analyzer_mapping an den ISO-Sprachcode gebunden (Shopware Developer Documentation). Nach jeder Änderung an den Wörterbüchern ist ein bin/console es:index fällig, sonst bleibt der Index auf dem alten Stand (Shopware Developer Documentation).

Ergänzend hat Shopware mit 6.7.12.1 die Behandlung verketteter Wörter angeglichen: Zusammengeschriebene und getrennt geschriebene Varianten gelten seitdem als gleichwertig, sodass eine Suche nach „Jacke“ auch Produkte mit „Lederjacke“ oder „Leder Jacke“ findet (Shopware AG). Wichtig zu wissen ist außerdem, dass für als durchsuchbar markierte Felder mit aktivierter Option „Suchbegriff teilen“ ein n-Gram-Tokenizer greift; der zugehörige Filter ses_ngram arbeitet mit den Parametern 3 als Minimum und 27 als Maximum (Shopware Developer Documentation).

Synonyme: Was Kunden sagen, was der Katalog nennt

Zwischen der Sprache des Katalogs und der Sprache der Kundschaft liegt in der Regel eine Lücke. Der Katalog kennt „Notebook“, gesucht wird „Laptop“. Der Katalog führt „WLAN-Repeater“, getippt wird „Wifi Verstärker“. Diese Lücke schließen Synonymlisten, und zwar dort, wo sie am wenigsten Schaden anrichten: zur Suchzeit.

OpenSearch bietet dafür den synonym_graph-Token-Filter. Er behandelt mehrwortige Synonyme korrekt, indem er einen Token-Graphen erzeugt, der die Positionen über unterschiedlich lange Terme hinweg erhält (OpenSearch-Dokumentation). Genau das kann der ältere, einfache synonym-Filter nicht: Bei Regeln wie „w-lan, wlan, drahtloses netzwerk“ verschiebt er die Positionen und liefert falsche Phrasentreffer. Der Parameter expand steht standardmäßig auf true (OpenSearch-Dokumentation) und expandiert eine Regel in alle Richtungen.

In der Shopware-Suchkonfiguration stehen zwei Regeltypen zur Verfügung, deren Unterschied in der Praxis oft unterschätzt wird (Shopware Developer Documentation):

• Äquivalenz behandelt Begriffe als vollständig austauschbar, etwa wifi, wlan, w-lan. Jede Richtung gilt, jeder Begriff findet die Treffer aller anderen. Passend für echte Wortgleichheit.
• Explizites Mapping bildet einen Suchbegriff gerichtet auf andere Ergebnisse ab, etwa iPhone => Smartphone. Die Zuordnung gilt nur in eine Richtung. Passend für Marken, Kategorien und umgangssprachliche Kurzformen.
• Die Sprachauswahl ist bei beiden Typen optional, Synonymregeln sind auf 100 Zeichen begrenzt (Shopware Developer Documentation).

Der häufigste Fehler ist der Griff zur Äquivalenz, wo ein Mapping gehört. Wer iPhone und Smartphone als äquivalent hinterlegt, macht jedes Android-Gerät zu einem iPhone-Treffer und produziert damit exakt die Trefferflut, die minimum_should_match gerade beseitigt hat. Ebenso riskant sind zu großzügige Listen: Jede Synonymregel erhöht die Zahl der optionalen Klauseln und verwässert damit indirekt die Wirkung der Mindesttreffer-Regel.

Exakte Treffer höher gewichten als ähnlich aussehende

Ist die Treffermenge eingegrenzt, entscheidet die Sortierung. Und hier zeigt sich ein Klassiker der Shop-Suche: Ein Produkt, dessen Name exakt der Anfrage entspricht, landet auf Platz 7, während ein Artikel mit einer keyword-überladenen Beschreibung oben steht. Die Ursache ist selten Bosheit, sondern Scoring.

Shopware hat mit 6.7 an mehreren Stellen nachgeschärft. Die Suche wendet verbesserte Relevanzschwellen an, um Treffer geringer Qualität zu reduzieren; schwach verwandte Ergebnisse werden herausgefiltert, sodass Kundinnen und Kunden eher Produkte sehen, die ihrer Suchabsicht entsprechen (Shopware AG). Zudem erhalten keyword-lastige Produkte keinen unfairen Ranking-Vorteil mehr, nur weil sie besonders viele Keywords enthalten: Die Suche gewichtet die Qualität und Relevanz der treffenden Keywords stärker als deren Menge (Shopware AG). Und die Ranking-Logik priorisiert exakte Treffer deutlicher gegenüber ähnlich aussehenden Ergebnissen, während Produkte, die über mehrere Attribute treffen, höhere Relevanzwerte erhalten (Shopware AG).

Technisch besonders relevant ist eine Änderung an den dis_max-Queries: Sie enthalten nun einen tie_breaker-Parameter auf Feldebene, auf Ebene übersetzter Felder und auf Ebene der Token-Kombinationen. Zuvor berücksichtigte dis_max ausschließlich die einzelne bestpassende Klausel. Mit tie_breaker fließen die Scores der übrigen treffenden Klauseln anteilig in die Gesamtbewertung ein, was das Ranking für Dokumente verbessert, die über mehrere Felder oder Sprachvarianten hinweg treffen (Shopware AG).

Ergänzend steuert der Ranking-Score je durchsuchbarem Feld die Gewichtung: Je höher der Wert, desto mehr Gewicht bringt das Feld in die Ergebnisliste ein (Shopware Developer Documentation). Die Faustregel dazu ist unspektakulär, aber wirksam: Produktname und Produktnummer bekommen das höchste Gewicht, Kategorie und Hersteller ein mittleres, die Langbeschreibung ein niedriges. Wird die Beschreibung zu hoch gewichtet, gewinnt regelmäßig der Text, nicht das Produkt. Wer seine Produktdaten ohnehin überarbeitet, findet in der automatisierten Anreicherung von Produktdaten den passenden Unterbau, denn Relevanz lässt sich nur aus Feldern gewinnen, die auch gefüllt sind.

Produktcodes, Größen wie 32/34 und Einheiten sauber verarbeiten

Hier verliert die Suche in der Praxis am meisten Umsatz, und hier bestätigt die Forschung den Befund am deutlichsten: 54% der Shops haben Probleme mit Abkürzungs- und Symbolsuchen (Baymard Institute). Der Grund liegt in der Regel beim Tokenizer. Shopware erlaubt beim Tokenisieren standardmäßig nur einen definierten Satz an Sonderzeichen, um Index- und Suchprobleme zu vermeiden. Der Parameter shopware.search.preserved_chars steht per Default auf ['-', '_', '+', '.', '@'] (Shopware Developer Documentation).

Der Schrägstrich fehlt in dieser Liste. Genau das macht die Konfektionsgröße 32/34 zum Problemfall: Sie wird in 32 und 34 zerlegt und findet damit jede Hose, die irgendwo eine 32 oder eine 34 führt. Dasselbe Muster trifft Produktnummern. Die Dokumentation nennt als Beispiel die Nummer PT-64/515: Ist „Suchbegriff teilen“ aktiv, wird nach PT, 64 und 515 gesucht; ist die Option inaktiv, bleibt PT-64/515 als Ganzes erhalten (Shopware Developer Documentation). Wer Schrägstriche erhalten will, überschreibt den Parameter in einer eigenen config/packages/shopware.yaml (Shopware Developer Documentation).

shopware:
    search:
        preserved_chars: ['-', '_', '+', '.', '@', '/', ',']
        term_max_length: 255

Analog verhält es sich mit Dezimalwerten und Einheiten. „1,5 l“ zerfällt ohne erhaltenes Komma in 1 und 5, „0.5" Gewinde“ ohne erhaltenen Punkt in unbrauchbare Fragmente. Wer Komma und Punkt als Trennzeichen zulässt, macht jede Maßangabe unsuchbar. Zu beachten ist zugleich die Länge: Die Mindestlänge eines Suchbegriffs beträgt 2 Zeichen, per Default sind 3 eingestellt, das Maximum liegt bei 255 Zeichen (Shopware Developer Documentation). Steht der Default auf 3, ist eine Suche nach XL oder M technisch nicht möglich, obwohl sie in Mode-Shops zu den häufigsten Anfragen gehört.

Wie fein diese Mechanik ist, zeigt eine Korrektur aus 6.7.12.0: Das n-Gram-Subfeld wurde aus den text- und textBoosted-Feldern entfernt, damit Bezeichner wie EANs und Produktnummern das n-Gram-Scoring nicht künstlich aufblähen. Behoben wurde damit eine Regression, bei der eine vollständige GTIN-Suche von unverwandten Produkten mit überlappenden Ziffernfolgen überholt werden konnte (Shopware AG). Genau dieser Fall ist im B2B teuer: Wer eine 13-stellige GTIN eintippt, erwartet exakt einen Treffer.

Autocomplete und Variantensuche konfigurieren

Autocomplete ist die Stelle, an der Relevanz sichtbar wird, bevor überhaupt gesucht wurde. Verbreitet ist die Funktion auf rund 80% der Shops, doch nur 19% setzen sämtliche Gestaltungsmuster korrekt um (Baymard Institute). Häufig scheitert es an der Menge: Für Desktop-Nutzende sollte die Zahl der Vorschläge 10 nicht überschreiten, für die meisten mobilen Nutzenden funktionieren 4 bis 8 Vorschläge (Baymard Institute).

Technisch gehört Autocomplete auf ein eigenes Feld, nicht auf den Volltextindex. Shopware ist mit 6.7.12.0 genau diesen Weg gegangen: Die Autovervollständigung der Admin-Suche nutzt ein neues, n-Gram-indiziertes completion-Feld, das je Entität mit namensförmigen Werten befüllt wird (Shopware AG). Der Nebeneffekt ist der eigentliche Gewinn: Weil das n-Gram-Subfeld aus den Textfeldern verschwindet, konkurrieren Bezeichner und Fließtext nicht mehr im selben Scoring.

Bei der Umstellung ist die Reihenfolge entscheidend. Nach dem Deployment muss bin/console es:admin:index ausgeführt werden, um die Indizes zu aktualisieren. Bezeichner-Suchen funktionieren zwar sofort auch auf älteren Indizes, die Substring-Autovervollständigung arbeitet bis zum abgeschlossenen Reindex jedoch nur eingeschränkt im Prefix-Modus (Shopware AG). Ein Deployment ohne anschließenden Reindex sieht also aus wie ein Feature-Bug.

Für Shops mit Varianten kommt eine zweite Neuerung hinzu. Das Suchfeld parent.name erlaubt, Varianten über den Namen des Hauptprodukts zu finden und sie unabhängig vom eigenen name der Variante zu ranken. Das Feld ist standardmäßig deaktiviert und muss in der Produktsuchkonfiguration aktiviert werden, wo sich auch sein Ranking justieren lässt (Shopware AG). Der Effekt ist erheblich: Heißt das Hauptprodukt „Pegasus Trail“ und die Variante nur „42 / Blau“, war die Variante zuvor über den Produktnamen praktisch unauffindbar.

• parent.name aktivieren, aber niedriger gewichten als den eigenen Variantennamen, sonst verdrängen Varianten das Hauptprodukt
• Autocomplete auf ein dediziertes completion-Feld legen statt auf den Volltextindex
• Vorschlagszahl auf maximal 10 (Desktop) beziehungsweise 4 bis 8 (Mobil) begrenzen (Baymard Institute)
• Nach jeder Feld- oder Analyzer-Änderung vollständig reindexieren

Wirkung messen statt behaupten

Jede Relevanz-Änderung ist eine Hypothese. Ob sie stimmt, entscheidet nicht das Bauchgefühl der Beteiligten, sondern eine Handvoll Kennzahlen, die vor und nach der Änderung erhoben werden. Ohne diese Messung ist Suchtuning Geschmackssache, und Geschmack lässt sich nicht gegen Umsatz verrechnen.

Ergänzend lohnt der Blick auf die Verfeinerungsrate, also den Anteil der Sitzungen, in denen die Anfrage umformuliert wird. Sie ist der empfindlichste Frühindikator: Wer nachtippt, hat die erste Liste als unbrauchbar empfunden, auch wenn sie Treffer enthielt. Und sie ist die beste Quelle für Synonymkandidaten, weil die Umformulierung meist genau das Wort enthält, das im Katalog steht.

Der Umgang mit Null-Treffern verdient dabei besondere Aufmerksamkeit, denn hier verschenken Shops systematisch Kaufabsicht: Nach dem Search-UX-Benchmark bieten nahezu 50% der Shops keine wirksame Möglichkeit, sich von einer ergebnislosen Suche zu erholen (Baymard Institute). Eine ältere Auswertung beziffert den Anteil der Shops, deren Null-Treffer-Seite eine reine Sackgasse ist, sogar auf 68% (Baymard Institute). Eine Null-Treffer-Seite ist an sich kein Fehler; zum Fehler wird sie, wenn sie keinen Weg zurück in den Katalog anbietet.

Eine Suchänderung ohne Vorher-Nachher-Messung ist keine Optimierung, sondern eine Meinung mit Deployment.

XICTRON Entwicklungsteam

Für die Bewertung gilt derselbe Grundsatz wie bei der datenbasierten Optimierung im Shop: Eine Änderung pro Runde, ein definierter Beobachtungszeitraum, und ein fester Satz an Referenzanfragen, der vor jedem Deployment durchläuft. Dieser Satz aus 30 bis 50 realen Anfragen, gemischt aus Produktnamen, Produktcodes, Komposita und Attributsuchen, ist die günstigste Absicherung gegen Relevanz-Regressionen (Projekterfahrung).

Die Relevanz-Konfiguration in der Praxis

Bevor überhaupt konfiguriert wird, gehört die Vorfrage geklärt: Lohnt sich der Suchindex? Die Hersteller-Dokumentation formuliert es zurückhaltend, aber klar: Sobald ein Projekt mehrere tausend Datensätze umfasst, ist die Integration von OpenSearch sinnvoll (Shopware Developer Documentation). OpenSearch steht dabei unter der Apache-2.0-Lizenz und wird von Shopware gleichwertig unterstützt; die Anbindung erfolgt über dieselben Konfigurationsvariablen.

Ein Detail wird dabei regelmäßig übersehen und kostet Stunden: Die reguläre Suchkonfiguration von Shopware hat keine Wirkung, sobald OpenSearch aktiv ist (Shopware Developer Documentation). Wer im Adminbereich Gewichtungen verstellt und sich über ausbleibende Effekte wundert, sucht an der falschen Stelle; die durchsuchbaren Felder und ihre Gewichte werden dann über die erweiterte Suchkonfiguration gesteuert.

Die relevanten Umgebungsvariablen sind OPENSEARCH_URL für die Hosts, SHOPWARE_ES_ENABLED zum Aktivieren der Suche, SHOPWARE_ES_INDEXING_ENABLED für die Indizierung und SHOPWARE_ES_INDEX_PREFIX für die Index-Benennung; für die Admin-Suche kommen ADMIN_OPENSEARCH_URL und SHOPWARE_ADMIN_ES_ENABLED hinzu (Shopware Developer Documentation). Für die Fehlersuche ist SHOPWARE_ES_THROW_EXCEPTION hilfreich, weil Relevanzprobleme sonst still als leere Ergebnismenge erscheinen.

Die Reihenfolge der Arbeitsschritte ist entscheidend, weil jede Analyzer-Änderung einen Reindex erzwingt und damit ein Zeitfenster braucht:

1. Suchprotokolle auswerten: Top-Anfragen, Null-Treffer-Anfragen und Anfragen mit hoher Verfeinerungsrate exportieren. Ohne echte Daten ist jede Konfiguration geraten.
2. Referenzanfragen definieren: 30 bis 50 reale Anfragen als Regressionsschutz festschreiben, inklusive erwarteter Top-Treffer.
3. Tokenizer und Sonderzeichen klären: preserved_chars am Katalog ausrichten, Mindestlänge prüfen, Produktnummern und Größen testen.
4. Dekomposition aufsetzen: Wörterbücher für die häufigsten Komposita des Sortiments pflegen, danach reindexieren.
5. minimum_should_match justieren: Mit 2<75% beziehungsweise einer mittleren Strictness-Stufe starten und gegen die Null-Treffer-Quote nachziehen.
6. Gewichte und Synonyme setzen: Ranking-Scores je Feld verteilen, Synonyme aus den Null-Treffer-Anfragen ableiten statt erfinden.
7. Autocomplete und Varianten aktivieren: completion-Feld und parent.name konfigurieren, Vorschlagszahl begrenzen.
8. Messen und nachsteuern: Null-Treffer-Quote, Suchausstiegsrate und Conversion nach Suche über einen definierten Zeitraum vergleichen.

Dieser Ablauf ist bewusst iterativ. Suchrelevanz ist kein Projekt mit Abnahmedatum, sondern eine Regelaufgabe: Jede neue Kollektion, jede Sortimentserweiterung und jede Saison erzeugt neue Suchbegriffe und damit neue Null-Treffer. Wer die Konfiguration einmalig setzt und dann liegen lässt, verliert die gewonnene Relevanz typischerweise innerhalb weniger Sortimentszyklen wieder (Projekterfahrung). Ergänzend gilt: Filter und Suche greifen ineinander, und die SEO-sichere Steuerung von Filter-URLs entscheidet mit darüber, ob verfeinerte Ergebnislisten überhaupt indexierbar bleiben.

Suchrelevanz ist ein Umsatzhebel, kein Nice-to-have

Die interne Suche verbindet die höchste Kaufabsicht im Shop mit der niedrigsten Pflegeintensität. Das ist eine ungewöhnliche Kombination, und sie erklärt, warum hier vergleichsweise kleine Eingriffe große Wirkung entfalten. minimum_should_match auf einen tragfähigen Wert zu setzen, Komposita zu zerlegen, Synonyme aus echten Protokollen abzuleiten, exakte Treffer sauber zu gewichten und Produktcodes nicht am Tokenizer zu zerschellen: Das sind Konfigurationsarbeiten, keine Neuentwicklungen. Sie brauchen allerdings Daten, Messung und Wiederholung.

Wenn die Relevanz-Konfiguration ausgereizt ist, beginnt die nächste Ebene. Wo Nutzende in Bedeutungen statt in Begriffen suchen, ergänzt Semantic Product Search mit Vektorsuche das lexikalische Fundament, und eine KI-gestützte Produktsuche legt eine weitere Schicht darüber. Beides ersetzt die saubere Grundkonfiguration jedoch nicht, sondern setzt sie voraus: Ein Hybrid-Stack auf einem falsch tokenisierten Index erbt dessen Fehler. Wer parallel an der Preisdarstellung arbeitet, sollte die rechtssichere Gestaltung von Streichpreisen mitdenken, denn Ergebnislisten zeigen Preise, und was in der Liste steht, muss der PAngV genügen.

XICTRON tunt Shop-Suchen auf Basis echter Suchprotokolle. Wir werten Ihre Anfragen, Null-Treffer und Abbrüche aus, leiten daraus die Relevanz-Konfiguration ab und belegen die Wirkung mit Vorher-Nachher-Zahlen statt mit Behauptungen. Als Shopware-Agentur übernehmen wir Analyzer, Gewichtung, Synonyme und Reindex-Strategie, und über unsere Entwicklungsleistungen auch die Anbindung an Ihre bestehende Infrastruktur. Sprechen Sie uns über das Kontaktformular an, wenn Ihre Suche mehr Trefferflut als Treffer produziert.