Magento-Suche findet Artikel nicht nach SKU, Farbe oder Namensteil

The problem

Die Standardsuche von Magento 2 arbeitet in vielen Shops faktisch nur bei einer vollständigen Übereinstimmung mit dem Produktnamen. Der Kunde tippt „sv01“, „gel lack 01“ oder „rosa Gel-Lack“ — und bekommt „Keine Ergebnisse gefunden“, obwohl der Artikel im Katalog und auf Lager ist. Dieselbe Wirkung hat jede Kleinigkeit: Bindestrich statt Leerzeichen, zusammengeschriebene Wörter, „ue“ statt „ü“, ein Tippfehler, eine andere Tastaturbelegung. Für den Menschen ist das ein und dasselbe Produkt, für das System sind es verschiedene Anfragen ins Leere.

Am teuersten ist dabei, dass genau der heißeste Traffic verloren geht. In das Suchfeld tippt jemand, der bereits weiß, was er kaufen will: aus dem Katalog, aus dem Newsletter, aus Instagram, wo er die Artikelnummer gesehen hat. Eine leere Ergebnisseite schickt diesen Kunden mit fertiger Kaufabsicht zum Wettbewerb. Bei einem Katalog von 1.500–3.000 Positionen liegt der Anteil der Sessions mit Suche üblicherweise bei 10–30 %, und die Conversion solcher Sessions ist zwei- bis dreimal höher als der Website-Durchschnitt — es geht also um einen spürbaren Umsatzanteil. Zusätzlicher Nachteil: erfolglose Suchanfragen werden nirgends protokolliert, der Shopbetreiber sieht also nicht einmal, was den Kunden im Sortiment fehlt.

What makes it hard

Ein Vorgehen „auf die harte Tour“ scheitert an mehreren Punkten. Der Shop läuft in der Regel bereits produktiv, betreut wird er von einem externen Dienstleister, Zugänge zu Repository und Testumgebung laufen über ihn — das ist ein eigener Schritt mit eigener Wartezeit. Das Katalog-Template und die bereits konfigurierten Filter dürfen nicht angefasst werden: sie funktionieren und der Auftraggeber ist zufrieden, jeder Eingriff in das Layout der Ergebnisseite zieht ein erneutes Testen des gesamten Katalogs nach sich.

Die zweite Einschränkung sind die Daten. SKU, Farbe, lateinischer Produktname und Serie sind oft bereits als Attribute in den Produktkarten gepflegt, landen aber nicht im Suchindex oder landen dort ohne Gewichtung — dadurch schlägt ein Treffer in der Beschreibung den Treffer in der Artikelnummer. Sind die Attribute nur teilweise oder in unterschiedlichen Formaten gefüllt, müssen sie zuerst vereinheitlicht werden, sonst zementiert die Suchkonfiguration das Chaos. Und drittens: Die Lösung muss aus Regeln bestehen, nicht aus einer manuellen Liste, denn täglich kommen neue Artikel hinzu und niemand konfiguriert die Suche für jede einzelne Position neu.

How we solve it

Erstens: Indexierung der Attribute mit Gewichtungen. SKU, Farbe, Serie und lateinischer Name werden zu vollwertigen Suchfeldern, wobei ein Treffer in der Artikelnummer stärker wiegt als ein Treffer innerhalb der Beschreibung. Die Anfrage „01“ zeigt alle Positionen mit dieser Nummerierung, „sv01“ die konkrete Produktkarte — auch wenn dieser Code im Namen gar nicht vorkommt. Dazu kommen Teiltreffer: Suche nach Wortbestandteilen und nach mehreren Wörtern in beliebiger Reihenfolge, sodass „gel lack 01“ und „gellack 01“ dieselbe Ergebnisliste liefern.

Zweitens: Normalisierung der Anfrage, bevor sie in den Index geht. Korrektur der Tastaturbelegung (wenn jemand in der falschen Sprache getippt hat), Transliteration in beide Richtungen („samer waib“ → Summer Vibe), Umlaut- und ß-Varianten (ue/ü, ss/ß), zusammen- und getrenntgeschriebene Komposita, typische Tippfehler. Darüber liegt ein Synonymwörterbuch für die Shop-Thematik: Schreibvarianten der Kategorien, Farb- und Serienbezeichnungen auf Deutsch, Englisch und in lateinischer Umschrift.

Drittens: Arbeit an der Ausgabe. Vorschläge ab dem dritten eingegebenen Zeichen: Foto, Name, Preis, direkter Sprung in die Produktkarte. Statt der Sackgasse „Nichts gefunden“ — ähnliche Positionen aus derselben Kategorie und die meistverkauften Artikel. Separat entsteht ein Report über Suchanfragen: was gesucht und was nicht gefunden wird — eine fertige Liste der Lücken im Sortiment und im Synonymwörterbuch. Getestet wird am realen Katalog anhand der Anfrageliste des Auftraggebers plus eigenem Set an Testfällen; gearbeitet wird in der Testumgebung, auf den Live-Shop gehen die Änderungen nach der Prüfung in einem Schritt. Die erweiterte Variante ergänzt das Bearbeiten von Synonymen im Admin-Backend ohne Entwickler, das manuelle Hochstufen bestimmter Positionen für definierte Anfragen, Regeln für saisonale Suchanfragen und Aktionen — und bei Bedarf einen Produktfeed für Marktplätze auf Basis derselben normalisierten Attribute.

What drives the price and timeline

Marktübliche Spanne für Magento 2 bei einem Katalog bis ca. 3.000 Positionen: Basis-Umbau der Suche (Attribute im Index, Anfragenormalisierung, Teiltreffer, Synonyme, Autosuggest) — etwa 1.200–2.200 € und 3–5 Arbeitstage. Die Variante mit Steuerung der Ergebnisreihenfolge, Report über Suchanfragen, eigenständiger Synonympflege und Support nach dem Launch — 1.800–3.200 €, 5–7 Tage. Wird im selben Schritt ein Feed für Marktplätze (Amazon, eBay, Idealo/Google Shopping) mit Kategorie-Mapping und automatischer Aktualisierung von Beständen und Preisen gebaut — 3.000–4.800 € und 10–12 Tage.

Der wichtigste Preisfaktor ist nicht die Anzahl der Produkte, sondern der Zustand der Attribute. Sind SKU, Farbe und Serie bereits in allen Produktkarten einheitlich gepflegt, ist genau so viel Arbeit zu tun, wie in der Liste steht. Müssen sie normalisiert oder aus Beschreibungen herausgelöst werden, kommt eine separate Phase der Datenaufbereitung hinzu und das Budget steigt um das Anderthalb- bis Zweifache. Der zweite Faktor ist die Geschwindigkeit, mit der der externe Dienstleister die Zugänge herausgibt: die Laufzeit zählt korrekterweise ab dem Tag, an dem Testumgebung und Repository bereitstehen — nicht ab dem Tag der Unterschrift.