Produktsuche in ein bestehendes PHP-Backend einbauen: Fehlertoleranz und Facetten ohne Eigenbau

Ein Kunde tippt „levis 501 blua" in das Suchfeld eines Mid-Enterprise-Shops. Im Hintergrund setzt das PHP-Backend ein SELECT ... WHERE name LIKE '%levis 501 blua%' ab. Die Ergebnisseite bleibt leer, obwohl über vierzig passende Artikel im Katalog liegen. Ein einziger vertauschter Buchstabe hat gereicht.

Dieses Bild kennt jedes Entwicklerteam, das eine gewachsene Shop-Suche betreut. Die Suche funktioniert, solange der Kunde exakt so tippt, wie das Produkt in der Datenbank steht. Sobald ein Tippfehler, eine andere Schreibweise oder eine unscharfe Anfrage dazukommt, bricht das Modell. Die Anforderung landet dann als Ticket beim technischen Leiter, meist mit zwei Vorschlägen im Gepäck. Entweder die Suche selbst um Fuzzy-Logik erweitern oder einen eigenen Elasticsearch-Cluster aufsetzen.

Beide Wege sind teurer, als sie auf den ersten Blick aussehen. Meist zu Unrecht. Dieser Artikel zeigt, was Fehlertoleranz (Typo-Tolerance) und Facettensuche (Faceted Search) technisch verlangen, und wie ein PHP-Team beide Fähigkeiten in ein bestehendes Backend nachrüstet, ohne die Suche von Grund auf neu zu bauen und ohne den Betrieb eines eigenen Suchclusters dauerhaft an sich zu binden.

Warum die LIKE-Suche im PHP-Backend an der Fehlertoleranz scheitert

Klassische Datenbanksuche im Shop-Backend arbeitet mit exaktem Substring-Matching. LIKE '%begriff%' findet genau die Zeilen, in denen die Zeichenkette so vorkommt. Für saubere Eingaben reicht das. Für echte Nutzereingaben nicht.

Reale Suchanfragen sind voller Abweichungen. Tippfehler, Zahlendreher in Artikelnummern, vermischte Singular- und Pluralformen, deutsche gegen englische Schreibweise, ein fehlendes Leerzeichen zwischen Marke und Modell. Eine Volltextsuche über MySQL-FULLTEXT-Indizes fängt einen Teil davon ab, kennt aber keine Editierdistanz. Sie versteht nicht, dass „blua" nur einen Handgriff von „blau" entfernt ist.

Am Ende steht eine leere Ergebnisseite dort, wo Umsatz möglich gewesen wäre. Ein Kunde, der nichts findet, sucht selten ein zweites Mal. Er wechselt den Shop. Fehlertoleranz ist deshalb kein Komfort-Feature. Sie ist die Grundschicht einer Suche, die im Alltag trägt. Wie sich eine leere Trefferliste auf die Conversion auswirkt, beschreibt der Beitrag zur Fehlertoleranz in der Shop-Suche ausführlicher.

Was Fehlertoleranz technisch bedeutet

Fehlertoleranz lässt sich messen. Die gängigste Grundlage ist die Editierdistanz, also die Zahl der Einzelschritte, die eine Zeichenkette von einer anderen trennt.

Am weitesten verbreitet ist die Levenshtein-Distanz. Sie zählt Einfügungen, Löschungen und Ersetzungen. „blua" zu „blau" ist genau eine Ersetzung, die Distanz beträgt eins. PHP bringt die Funktion levenshtein() sogar von Haus aus mit, wie die offizielle PHP-Dokumentation zeigt. Für den Vergleich zweier kurzer Strings ist das nützlich. Für einen Katalog mit 60.000 Artikeln nicht. Ein levenshtein()-Aufruf pro Zeile bei jeder Anfrage bringt jede Datenbank in die Knie.

Einen Schritt weiter geht die Damerau-Levenshtein-Distanz. Sie ergänzt den vierten Fall, die Vertauschung benachbarter Zeichen. Aus „artikel" wird so schnell „aritkel". Genau diese Dreher machen einen großen Teil der Fehleingaben aus, weil die Finger auf der Tastatur schneller sind als die Rechtschreibung. Im E-Commerce ist die Erweiterung damit alles andere als akademisch.

Auf der dritten Ebene steht die phonetische Suche. Sie vergleicht Begriffe nach ihrem Klang. „Reifen" und „Reiffen" klingen gleich, „Maier" und „Meyer" ebenfalls. PHP kennt dafür soundex() und metaphone(), beide sind allerdings auf das Englische ausgelegt. Für den deutschen Markt ist die Kölner Phonetik das passendere Verfahren. Die PHP-Referenz zu soundex() macht das Prinzip anschaulich, ersetzt aber keine produktive Suchmaschine.

Diese drei Ebenen fasst die folgende Tabelle zusammen.

In einer produktiven Suchmaschine steckt diese Logik in konfigurierbaren Parametern. Elasticsearch etwa steuert die erlaubte Editierdistanz über den fuzziness-Parameter der Fuzzy-Query, dokumentiert in der Elasticsearch-Referenz zur Fuzzy-Query. Wer Elasticsearch, OpenSearch oder Solr selbst betreibt, muss Analyzer und Tokenizer pro Feld einstellen und die Fuzziness austesten. Das ist möglich und gut dokumentiert. Es ist auch der Punkt, an dem aus „wir bauen mal schnell Fuzzy-Suche ein" ein eigenes Projekt wird.

Facettensuche: dynamische Facetten statt fest verdrahteter Filter

Der zweite Baustein einer brauchbaren Produktsuche ist die Facettensuche. Facetten sind die Filter, die sich am Rand der Ergebnisliste aufbauen. Marke, Größe, Farbe, Preisspanne, Verfügbarkeit. Der englische Begriff Faceted Search meint genau dasselbe.

Der Unterschied zu einer einfachen Filterleiste liegt in der Dynamik. Eine dynamische Facette berechnet sich aus dem aktuellen Ergebnis. Sucht der Kunde nach „Laufschuhe", zeigt die Facette „Größe" nur die Größen, die für Laufschuhe tatsächlich lieferbar sind, jeweils mit der Trefferzahl daneben. Fest verdrahtete Filterlisten im Shop-Template können das nicht. Sie zeigen immer alle Optionen, auch die mit null Treffern, und laufen bei jeder Sortimentsänderung aus dem Ruder.

Diese Aggregation in SQL selbst nachzubauen, ist aufwendig. Für jede Facette braucht es eine eigene GROUP BY-Abfrage über das gefilterte Ergebnis, und das bei jeder Anfrage und jeder Kombination von Filtern. Bei wenigen Attributen geht das. Bei einem breiten Sortiment mit vielen Attributen wächst die Last überproportional, und die Antwortzeiten steigen. Eine Suchmaschine liefert diese Aggregationen als Teil der Antwort gleich mit. Sie ist genau dafür gebaut.

Wie sich Facetten und Produktfilter aus Kundensicht unterscheiden und was gute Facettennavigation ausmacht, vertiefen die Beiträge zur Facettensuche im E-Commerce und zu Produktfiltern im Online-Shop.

Zwei Wege zur selben Anforderung

Steht die Anforderung fest, gibt es zwei realistische Wege. Entweder das Team baut die Suche selbst, auf Basis eines selbst betriebenen Elasticsearch-, OpenSearch- oder Solr-Clusters. Oder es rüstet die fehlenden Fähigkeiten über eine Such-API (Search API) mit fertigem SDK nach und lässt den Betrieb der Suchschicht außer Haus.

Selbst zu bauen gibt maximale Kontrolle und volle Freiheit beim Tuning. Der Preis dafür ist Betriebsverantwortung. Ein Suchcluster will überwacht und aktualisiert werden, und er muss gegen Ausfall abgesichert sein. Die Synchronisation aus ERP, PIM und Shopsystem in den Suchindex ist eine eigene Pipeline, die niemand pflegt, bis sie bricht. Relevanz und Fehlertoleranz sind kein einmaliges Setup, sie brauchen dauerhafte Betreuung durch Entwickler.

Nachrüsten dreht das Verhältnis um. Die Suche kommt als betriebene Infrastruktur, die Anbindung geschieht über ein SDK im vertrauten PHP-Stack.

Zeit ist dabei der stille Kostenfaktor. Ein Selbstbau bindet die stärksten Entwickler über Wochen, in denen sie keine Umsatzfeatures liefern. Läuft der Cluster dann, beginnt die Pflege erst richtig. Jeder neue Markt, jede Sortimentserweiterung, jedes ERP-Update kann die Sync-Pipeline berühren. Rechnet man die Personalkosten mehrerer Entwicklermonate, den laufenden Betriebsaufwand und die Ausfallsicherung über drei Jahre gegen eine betriebene Infrastruktur, kommt bei ehrlicher Buchführung oft ein anderes Ergebnis heraus, als das Bauchgefühl zunächst nahelegt. Nachrüsten verschiebt diesen Dauerbetrieb aus dem Team heraus. Der vorhandene Code bleibt unverändert.

Diesen zweiten Weg gehen im DACH-Raum bereits rund 50 namhafte Mid-Enterprise-Kunden mit BatteryIncluded. Darunter ein Katalog mit über 50.000 Produkten, den die Echtzeit-Synchronisation aktuell hält.

Nachrüsten in der Praxis: das SDK an das bestehende Backend anbinden

Für ein PHP-Team fängt der Nachrüst-Weg mit einer einzigen Composer-Zeile an. Das offizielle PHP-SDK von BatteryIncluded liegt als Paket auf Packagist:

composer require batteryincluded/batteryincluded-php-sdk

Das SDK setzt PHP 8.2 oder höher voraus und benötigt die Erweiterungen ext-curl und ext-mbstring. Es steht unter der MIT-Lizenz. Wer mit Symfony arbeitet, bindet stattdessen das Bundle batteryincluded/batteryincluded-bundle ein, das intern auf demselben PHP-SDK aufsetzt und die Symfony-Komponenten der Reihen 7 und 8 unterstützt. Für Sylius-Shops steht ein eigenes Plugin bereit, ebenfalls ab PHP 8.2 und Sylius 2.0. Auf der Frontend-Seite gibt es ein TypeScript-SDK. Ein Go-SDK ist in Vorbereitung.

Alle verfügbaren Endpunkte sind in einem öffentlichen Postman-Workspace dokumentiert, den das Team ohne Login einsehen kann. Damit lässt sich die API prüfen, bevor eine Zeile Code entsteht.

Wichtiger als die Composer-Zeile ist die Ebene darunter. BatteryIncluded ist eine entkoppelte Such-Infrastruktur (Decoupled Architecture), kein Aufsatz auf der Shop-Datenbank. Die Suche zieht ihre Daten über das AI Data Discovery Framework nativ aus den Quellsystemen zusammen, aus ERP, PIM, CMS und Shopsystem. Diese Multi-Source Datenaggregation hält den Index per Echtzeit-Synchronisation (Real-time Sync) aktuell, ohne dass jede Suchanfrage die Shop-Datenbank belastet. Das Backend bleibt frei für Warenkorb und Checkout.

Auf der Fehlertoleranz-Schicht setzt die semantische Ebene auf. Semantische Suche (semantic search) versteht die Absicht hinter einer Anfrage, nicht nur ihre Zeichen. Die hybride Suche (Hybrid Search) verbindet dieses semantische Verständnis mit dem exakten Abgleich von Artikelnummern und Attributen. In der Produktlinie heißt dieser Ansatz Hybrid LLM Search, das zugehörige Suchprodukt trägt den Namen Volt Search®. Wie exakter Artikelnummern-Match und unscharfe Freitext-Anfrage in einer einzigen Suche zusammenkommen, hängt eng an der Tokenisierung von EAN- und Artikelnummern. Der Beitrag zu Tokenseparatoren in der Shop-Suche geht darauf im Detail ein.

Im DACH-Markt zählt ein weiterer Punkt. Die Infrastruktur arbeitet 100 Prozent cookieless und verlangt keine Consent-Abfrage über ein CMP. Relevanz entsteht aus dem Kontext der Anfrage, nicht aus einem Nutzerprofil. Das ist DSGVO-konforme KI im Wortsinn.

Grenzen: was Fehlertoleranz nicht repariert

Beide Bausteine heben die Suche auf ein anderes Niveau. Sie sind aber kein Ersatz für saubere Produktdaten, und diese Grenze sollte ein Team offen benennen.

Fehlertolerante Verfahren korrigieren die Eingabe des Kunden. Sie korrigieren nicht den Katalog. Wo Attribute fehlen, Kategorien uneinheitlich vergeben sind oder eine Farbe im PIM „marine" und im Shop „dunkelblau" heißt, kann keine Editierdistanz das ausgleichen. Fehlt einem Artikel die EAN, findet ihn auch die beste Tokenisierung nicht über die EAN. Standardisierte Produktkennzeichnungen sind hier die Basis, wie sie etwa die Standardisierungsorganisation GS1 Germany für Artikelnummern und Identifikatoren definiert.

Konkret bleiben drei Aufgaben beim Menschen:

• Datenqualität im PIM. Vollständige Attribute, konsistente Werte und gepflegte Kennzeichnungen sind die Voraussetzung, auf der jede Suche aufbaut.
• Synonyme und Fachbegriffe. Dass „Pulli" und „Pullover" dasselbe meinen oder ein Händler-Kürzel für ein bestimmtes Bauteil steht, entscheidet ein Mensch mit Sortimentskenntnis.
• Relevanz und Merchandising. Welches Produkt bei mehrdeutigen Anfragen oben steht, ist eine kommerzielle Entscheidung. Ein Verfahren liefert Kandidaten, die Reihenfolge kuratiert das Marketing.

Genau dafür braucht es einen Human-in-the-Loop. Die Infrastruktur nimmt dem Team die mechanische Arbeit ab, vom Berechnen der Editierdistanzen bis zum laufenden Synchronisieren der Daten. Die inhaltlichen Entscheidungen bleiben steuerbar. Im Idealfall geschieht das im Backend, ohne dass für jede Synonym-Regel ein Entwickler ein Deployment fahren muss. Die Pflege von Synonymen und Boosts wandert damit von der IT ins Marketing, wo das Sortimentswissen sitzt.

Zur Einordnung ein Beispiel aus dem Kundenkreis. B&W Handelsgesellschaft mbH berichtet: „Bereits nach zwei Monaten stieg unsere Conversion Rate um 10 Prozent, und nach vier Monaten konnten wir einen Zuwachs von 19 Prozent verzeichnen." Solche Zahlen hängen immer am konkreten Shop und Sortiment. Konkrete Zielwerte für ein neues Projekt gehören in den gemeinsamen Termin, nicht in eine pauschale Zusage.

Häufige Fragen

Was bedeutet Fehlertoleranz in der Produktsuche?
Fehlertoleranz, englisch Typo-Tolerance, beschreibt die Fähigkeit einer Suche, trotz Tippfehlern, Zahlendrehern oder abweichender Schreibweise die richtigen Treffer zu liefern. Technisch stützt sie sich auf Editierdistanzen wie Levenshtein und Damerau-Levenshtein sowie auf phonetische Verfahren.

Was ist der Unterschied zwischen Fuzzy-Suche und Facettensuche?
Fuzzy-Suche arbeitet auf der Ebene der Eingabe und gleicht unscharfe oder fehlerhafte Suchbegriffe gegen den Katalog ab. Facettensuche arbeitet auf der Ebene des Ergebnisses und bietet dynamische Filter wie Marke, Größe oder Preis an. Beide ergänzen sich und lösen verschiedene Probleme.

Brauche ich einen eigenen Elasticsearch-Cluster für fehlertolerante, facettierte Suche?
Ein selbst betriebener Cluster aus Elasticsearch, OpenSearch oder Solr ist ein möglicher Weg, bringt aber dauerhafte Betriebsverantwortung mit. Über eine Such-API mit SDK lassen sich Fehlertoleranz und Facetten nachrüsten, ohne einen eigenen Cluster zu betreiben oder eine Sync-Pipeline selbst zu pflegen.

Wie erweitere ich ein bestehendes PHP-Backend, ohne die Suche neu zu bauen?
Über das PHP-SDK per Composer entsteht die Anbindung an die Suchschicht. Diese bleibt entkoppelt und läuft als eigene Infrastruktur, während das SDK die Kommunikation übernimmt. Der bestehende Shop und sein Backend bleiben unverändert, es kommt eine Schnittstelle dazu.

Welche PHP-Version brauche ich für das SDK?
Das PHP-SDK setzt PHP 8.2 oder höher voraus und benötigt die Erweiterungen ext-curl und ext-mbstring. Für Symfony gibt es ein Bundle, für Sylius ein eigenes Plugin, jeweils ab PHP 8.2.

Was ist Facettennavigation und welche Filtertypen gibt es?
Facettennavigation bietet dem Kunden Filter, die sich aus dem aktuellen Suchergebnis berechnen. Typische Typen sind Auswahlfacetten wie Marke oder Farbe, numerische Bereiche wie Preisspannen, hierarchische Kategorien und Verfügbarkeitsfilter. Dynamische Facetten zeigen nur Optionen mit echten Treffern samt Trefferzahl.

Bleiben die Daten dabei DSGVO-konform?
Personenbezogene Profile spielen keine Rolle. Ausschlaggebend ist der Kontext der jeweiligen Anfrage, den die Suche ohne getrackte Personendaten auswertet. Eine Consent-Abfrage über ein CMP ist für den Betrieb der Suche nicht nötig.

Fehlertoleranz und Facetten als betriebene Infrastruktur

Eine Suche, die Tippfehler verzeiht und mit dynamischen Facetten führt, ist für einen Mid-Enterprise-Shop kein Luxus. Sie entscheidet, ob aus einer Anfrage ein Kauf wird oder eine leere Ergebnisseite. Der Weg dorthin muss aber kein Eigenbau sein, der ein Entwicklerteam über Monate bindet und danach dauerhaft in Betrieb hält.

BatteryIncluded stellt diese Schicht als betriebene Infrastruktur bereit, Made in Germany aus Freilassing, seit dem ersten Tag bootstrapped und profitabel. Die Anbindung an ein bestehendes PHP-Backend läuft über ein SDK im gewohnten Stack. Finden statt Suchen, ohne die eigene Suche neu zu erfinden.

Sehen Sie sich in einer kostenlosen Demo an, wie Fehlertoleranz, Facetten und hybride Suche an Ihrem Katalog wirken. Für technische Rückfragen zur Integration erreichen Sie das Team direkt über die Kontaktseite.