Magento Suche findet Artikelnummer nicht: Lösung

Das Problem

Ein typischer Fall für einen Onlineshop auf Magento 2.4.x mit 1.000–5.000 Artikeln: Die Magento-Suche findet die Artikelnummer nicht und greift nur, wenn der Kunde den Namen Zeichen für Zeichen eintippt. „Gel Lack 05“ passt nicht zu „Gel-Lack Pastel Line 05“ – für Menschen dasselbe Produkt, für das System kein Treffer. Die Artikelnummer ist gepflegt, aber nicht durchsuchbar: „pl05“ oder nur „05“ liefert eine leere Seite. Genauso bei Farbe, Produktlinie, Zusammen- und Getrenntschreibung, lateinischer und kyrillischer Schreibweise oder falschem Tastaturlayout.

Wer eine Artikelnummer eingibt, kommt aus Preisliste oder Instagram mit konkreter Kaufabsicht – und sieht „Keine Ergebnisse“. Er schreibt nicht in den Chat, er schließt den Tab, und der Shop erfährt davon nichts, weil erfolglose Suchen nicht protokolliert werden. Wie groß der Verlust ist, zeigen erst der Report „Search Terms“ im Magento-Backend und der Bericht site_search in GA4 – dort stehen in Shops dieser Größe in der Regel mehrere Dutzend Anfragen pro Woche mit null Treffern.

Warum es nicht einfach geht

Die Standardsuche von Magento 2.4.x vergleicht die Anfrage mit Name und Beschreibung und kann mit Teiltreffern und Attributen kaum umgehen. „Use in Search“ für ein Attribut zu aktivieren reicht nicht: Ohne eigenes Gewicht verliert ein Treffer bei der Artikelnummer gegen einen zufälligen Treffer in der Beschreibung, und das richtige Produkt landet auf Platz zehn. Geändert werden müssen Suchindex, Feldgewichte, Analyzer und Anfrageverarbeitung – teils über ein Modul wie Smile ElasticSuite oder Mirasvit Search, teils über eigenen Code im Repository. Welche Engine darunter liegt, hängt von der Minor-Version ab: Magento 2.4.0–2.4.3 arbeitet mit Elasticsearch 7.x, ab 2.4.4 ist OpenSearch 1.2+ die Standard-Engine, ab 2.4.6 wird OpenSearch 2.x unterstützt.

Die zweite Einschränkung ist die betreuende Agentur: Meist pflegt ein anderes Team den Shop, gearbeitet wird in dessen Staging und Repository, die Frist läuft ab Erhalt der Zugänge. Die dritte sind Daten: Der Umbau funktioniert nur, wenn Artikelnummer, Farbe und Produktlinie eigene Attribute sind. Stehen sie als Text in der Beschreibung oder sind nicht mit der Warenwirtschaft abgeglichen, ist zuerst eine Katalogbereinigung nötig – als eigener Umfang. Ein Hinweis zur Einordnung: Ein fertiges Magento-Suchprojekt zeigen wir im Portfolio nicht; übertragbar ist aus unseren Projekten der Mechanismus der Attribut- und Stammdatensynchronisation, nicht die Suche selbst.

So lösen wir es

Die Lösung ist ein Umbau der Onlineshop-Suche auf Ebene von Index und Anfrageverarbeitung. Die Arbeit läuft in fünf Schritten:

1. 1. Gewichtete Attributindexierung in OpenSearch bzw. Elasticsearch. Artikelnummer, Farbe, Produktlinie und lateinischer Name werden eigene Suchfelder mit Boost, ein Treffer bei der Artikelnummer zählt mehr als einer in der Beschreibung. Teiltreffer entstehen über einen Edge-n-gram-Analyzer (2–20 Zeichen) plus fuzziness AUTO für Tippfehler: „05“ zeigt alle Artikel mit dieser Nummer, „pl05“ genau einen; die Wortreihenfolge spielt keine Rolle. Ob dafür Smile ElasticSuite, Mirasvit Search oder eine eigene Erweiterung der Magento-Suche genutzt wird, entscheidet der Audit – bei bereits installiertem Modul bleibt es beim Modul.
2. 2. Normalisierung der Anfrage. Korrektur des Tastaturlayouts, Transliteration Latein ⇄ Kyrillisch, Zusammen- und Getrenntschreibung, Bindestriche, typische Tippfehler, dazu ein Synonymwörterbuch für Farben und Produktlinien in drei Sprachen.
3. 3. Umgang mit leeren Treffern. Suchvorschläge ab dem dritten Zeichen mit Foto und Preis, eine Seite „Keine Ergebnisse“ mit ähnlichen Artikeln derselben Kategorie und ein Report über Suchen ohne Treffer – eine fertige Liste dessen, was im Katalog oder bei den Synonymen fehlt. Diese Liste ist zugleich Material fürs SEO und für die Werbung: echte Formulierungen der Kunden.
4. 4. Produktfeeds aus denselben Attributen. Aus den bereinigten Feldern entsteht ein Export für Preisportale und Marktplätze: Feed-Generierung, Kategorie-Mapping, automatische Preis- und Bestandsaktualisierung aus CRM oder ERP – nach demselben Prinzip wie beim Onlineshop mit Katalog und CRM-Anbindung, wo Bestellungen und Bestände ohne manuelle Pflege laufen.
5. 5. Synchronisation und Start. Regeln gelten für Attribute, nicht für eine fixe Produktliste: Bestände, Artikelnummern und Attributwerte kommen per Automatisierung aus dem ERP oder CRM – über denselben Mechanismus wie bei Stammdaten und Mandanten in der Standard-ERP, wo Referenzdaten zentral gepflegt werden. Live gehen die Änderungen in einem Schritt nach dem Test mit einer Liste echter Suchanfragen; ein Rollback bleibt möglich.

Was Preis und Dauer bestimmt

Marktübliche Spanne für Magento 2.4.x mit bis zu 2.000–3.000 Artikeln: Basisumbau der Suche (Attribute, Teiltreffer, Transliteration, Tastaturlayout, Synonyme, Suchvorschläge) – etwa 800–1.400 € und 3–5 Arbeitstage. Mit Steuerung der Trefferliste (Synonympflege im Backend, Suchreport, manuelles Hochziehen, Seite „Keine Ergebnisse“) – 1.200–2.000 € und 5–7 Tage. Zusammen mit Produktfeeds – 2.000–3.000 € und 10–12 Tage.

Der Hauptpreisfaktor ist nicht die Kataloggröße, sondern die Qualität der Attribute. Liegen Artikelnummer, Farbe und Produktlinie schon in eigenen Feldern, bleibt der Aufwand an der Website am unteren Rand; stecken sie in Beschreibungen, kommt eine Katalogbereinigung hinzu, und das Budget wächst mit der Artikelzahl. Zweiter Faktor ist, wie schnell die betreuende Agentur Zugang gewährt – die Fristen zählen ab Erhalt der Zugänge. Üblich sind 50 % zum Start und 50 % nach Abnahme im Live-Shop; der Code bleibt in Ihrem Repository.

Häufige Fragen