Such-Infrastruktur statt Plugin: was Mid-Enterprise-Shops wirklich brauchen

Ein Head of E-Commerce steht vor einem Katalog mit 60.000 Artikeln, verteilt auf drei Länder-Shops. Die Produktsuche läuft über ein Modul, das nachts den kompletten Katalog neu indexiert. Um acht Uhr morgens, wenn der Traffic anzieht, wird der Shop spürbar langsamer. Der Reindex teilt sich dieselbe Datenbank mit dem Verkauf.

Die Lagerbestände liegen im ERP, die Attribute und Mediendaten im PIM, die Ratgebertexte im CMS. Das Suchmodul sieht davon nur, was das Shopsystem am Ende exportiert. Ein Artikel ist längst ausverkauft, die Suche zeigt ihn trotzdem noch als verfügbar an. Kommt ein vierter Markt dazu, kommt eine weitere Modul-Instanz dazu, die separat gepflegt werden will.

Das Modul funktioniert. Bis der Katalog, die Datenquellen und die Zahl der Märkte eine Schwelle überschreiten, ab der es das nicht mehr sauber tut.

Dann kippt die Rechnung.

Genau an dieser Schwelle trennt sich ein Suchmodul von einer echten Such-Infrastruktur. Der Unterschied ist ein Architekturthema. Die Funktionsliste im Datenblatt sagt darüber wenig aus. Dieser Text zeigt, woran Mid-Enterprise-Shops die Grenze erkennen und was auf der anderen Seite steht.

Wann ein Plugin an seine Grenzen stößt

Ein Suchmodul lebt im Shopsystem. Es spiegelt einen Index der Produktdaten, die der Shop bereitstellt, und beantwortet daraus die Anfragen der Kundschaft. Für einen überschaubaren Katalog in einem Markt reicht dieses Prinzip lange aus.

Die Produktsuche ist dabei kein Randfeature. Sie ist für viele Besucher der erste ernsthafte Kontakt mit dem Sortiment. Das Baymard Institute dokumentiert, wie viele verschiedene Anfragetypen eine E-Commerce-Suche in der Praxis abfangen muss, von der exakten Artikelnummer über Merkmalskombinationen bis zur vagen, umschreibenden Frage (Baymard Institute, abgerufen 10.09.2026). Ein rein regelbasierter Textabgleich deckt davon nur einen Teil ab.

Bei einem wachsenden Sortiment macht sich zuerst die Aktualität bemerkbar. Ein Modul indexiert typischerweise nach Zeitplan, oft einmal pro Nacht, während sich Preise und Bestände im Minutentakt ändern. Zwischen zwei Reindex-Läufen zeigt die Suche Artikel, die nicht mehr lieferbar sind, oder Preise von gestern. Bei einem kleinen Katalog fällt das kaum auf. Bei mehreren zehntausend Artikeln summiert sich der Fehler zu spürbar falschen Trefferlisten.

Der Reindex selbst belastet das Shopsystem zusätzlich. Er greift aus dem Shop heraus auf dieselbe Datenbank zu, die parallel den laufenden Verkauf bedient, und in Spitzenzeiten konkurrieren beide um dieselben Ressourcen. Die Antwortzeiten steigen ausgerechnet dann, wenn die meisten Menschen im Shop sind.

Schwer wiegt vor allem die eingeschränkte Datensicht. Das Modul kennt nur den Ausschnitt, den das Shopsystem exportiert, während sich der eigentliche Wissensbestand eines Mid-Enterprise-Händlers über ERP, PIM und CMS verteilt. Verfügbarkeiten, technische Attribute, redaktionelle Inhalte. Was in diesen Systemen liegt und nicht sauber in den Shop-Export gelangt, findet die Suche schlicht nicht.

Was Such-Infrastruktur von einem Plugin unterscheidet

Such-Infrastruktur kehrt das Prinzip um. Der Suchdienst läuft als eigener Dienst mit eigener Rechenkapazität neben dem Shop. Der Shop ruft Ergebnisse über eine Schnittstelle ab und liefert selbst keine Suchlast mehr aus.

Das klingt nach einem technischen Detail. Tatsächlich verändert es das Betriebsmodell der Suche grundlegend, weil Datenhaltung, Aktualisierung und Skalierung von diesem Moment an nicht mehr am Shop hängen.

Das ist der Kern der Entkoppelten Infrastruktur (Decoupled Architecture). Das Prinzip stammt aus dem Umfeld composabler, entkoppelter Commerce-Systeme, wie es etwa die MACH Alliance beschreibt (MACH Alliance, abgerufen 10.09.2026). Jeder Baustein, auch die Suche, ist ein austauschbarer Dienst mit klarer API. Er bleibt nicht im Shop-Monolithen verdrahtet.

Der Zugang für die Entwicklung läuft über eine Such-API (Search API) und fertige SDKs. Für BatteryIncluded sind das ein PHP-SDK, ein TypeScript-SDK sowie Integrationen für Sylius und ein Symfony-Bundle. Das PHP-SDK zieht man per Composer über composer require batteryincluded/batteryincluded-php-sdk und setzt mindestens PHP 8.2 voraus. Ein Go-SDK ist als Repository angelegt, aber noch in Vorbereitung. Die verfügbaren Endpunkte sind in einem öffentlichen Postman-Workspace dokumentiert.

Weil die Anbindung über die API läuft, ist die Suche vom Frontend entkoppelt. Ein Shopware-Shop, ein Headless-Setup mit React oder ein eigenes Portal greifen auf dieselbe Infrastruktur zu. Für Shopware gibt es dafür eine fertige Anbindung an Shopware 6, die die Infrastruktur an das Shopsystem koppelt, ohne die Suche selbst in den Shop zu verlagern.

Für Architekten ist diese Trennung der eigentliche Gewinn. Die Suche wird zu einem klar abgegrenzten Dienst mit definierter Schnittstelle, den man testen, versionieren und unabhängig vom Shop ausrollen kann. Ein Frontend-Wechsel oder ein Replatforming des Shops berührt die Suchlogik nicht, solange die API stabil bleibt. Das senkt die Kopplung zwischen Teams, die sonst bei jedem Shop-Release mitziehen müssten.

Beide Ansätze lassen sich entlang der Dimensionen gegenüberstellen, an denen ein Mid-Enterprise-Katalog die Entscheidung tatsächlich trifft.

Native Datenaggregation aus ERP, PIM, CMS und Shop

Welche Daten eine Suche überhaupt sieht, entscheidet mehr über die Ergebnisqualität als jeder Ranking-Algorithmus. Ein Modul im Shop sieht den Shop. Eine Such-Infrastruktur sieht die Quellsysteme direkt. So einfach ist der Kern.

BatteryIncluded aggregiert die Daten über Multi-Source Datenaggregation nativ aus ERP, PIM, CMS und Shopsystem. Jede dieser Quellen liefert genau die Werte, die sie führt, und die Suche greift sie direkt ab, ohne den Umweg über einen abgeleiteten Shop-Export. Das AI Data Discovery Framework führt diese Quellen zu einem gemeinsamen, durchsuchbaren Bestand zusammen, ohne dass die Redaktion Daten doppelt pflegt.

Praktisch heißt das, dass die Suche jedes Attribut aus dem System zieht, in dem es ohnehin gepflegt wird. Der Bestand bleibt im ERP führend, die Merkmale im PIM, die Inhalte im CMS. Niemand exportiert Daten in ein zweites Schema, das dann auseinanderläuft. Das senkt den Pflegeaufwand und hält die Trefferqualität hoch, weil die Suche mit denselben Daten arbeitet, auf die sich auch Einkauf und Redaktion verlassen.

Aktualisiert wird über Echtzeit-Synchronisation (Real-time Sync). Ändert sich ein Preis im ERP oder ein Attribut im PIM, wird der Suchindex zeitnah nachgezogen. Der Reindex ist damit kein nächtliches Großereignis mehr, das den Shop ausbremst.

Weil der Dienst entkoppelt läuft, entsteht im laufenden Betrieb keine zusätzliche Last auf der Shop-Datenbank. Die Suche skaliert unabhängig vom Shop, und die Antwortzeiten hängen nicht mehr davon ab, ob gerade ein Import läuft. Das ist der praktische Grund, warum ein großer Katalog von der Entkopplung profitiert. Ein Kunde mit über 50.000 Produkten beschreibt genau diese Kombination aus schneller Suche und Stabilität als Ausschlag für die Entscheidung (freigegebene Kundenstimme, Österreichischer Bundesverlag Schulbuch GmbH & Co. KG).

Skalierung über Länder, Shops und Sprachen

Für einen einzelnen Shop in einem Markt ist Skalierung selten das Thema. Für einen Mid-Enterprise-Händler mit mehreren Storefronts, Sprachen und Währungen ist sie oft der eigentliche Auslöser für den Wechsel.

Modulbasierte Ansätze lösen das meist über Vervielfachung. Jeder Shop bekommt seine eigene Instanz, seine eigene Konfiguration, seine eigene Pflege. Sprachbesonderheiten, etwa die Zerlegung zusammengesetzter Wörter oder länderspezifische Synonyme, gehören zu den klassischen Fallstricken bei mehrsprachigen Systemen. Das W3C fasst die typischen Internationalisierungsfragen zusammen, von der Zeichenkodierung bis zur sprachabhängigen Sortierung (W3C Internationalization, abgerufen 10.09.2026). Bei getrennten Instanzen wird jede dieser Fragen mehrfach beantwortet.

Eine entkoppelte Infrastruktur trägt diese Logik zentral. Eine Instanz bedient viele Märkte, mit sprachabhängiger Analyse pro Land und gemeinsamem Relevanzmodell. Wie sich das über Länder und Sprachen aufspannt, vertieft der Beitrag zur Multi-Country Search-Infrastruktur.

Jede zusätzliche Modul-Instanz ist außerdem ein eigener Betriebsposten. Konfiguration, Synonymlisten und Relevanzregeln driften über die Instanzen auseinander, sobald sie getrennt gepflegt werden. Ein Kunde findet dieselbe Produktkategorie im deutschen Shop unter einem anderen Filter als im niederländischen. Eine zentrale Infrastruktur hält diese Regeln an einer Stelle und spielt sie konsistent in alle Märkte aus.

Auf dieser Basis greifen die Suchfunktionen, die eine moderne Produktsuche ausmachen, in allen Märkten gleich. Die Fehlertoleranz (Typo-Tolerance) fängt Tippfehler und Schreibvarianten ab. Die Facettensuche (Faceted Search) filtert große Trefferlisten nach Merkmalen, die aus den aggregierten Daten stammen. Die semantische Suche (semantic search) versteht die Absicht hinter einer Anfrage über den reinen Wortlaut hinaus. Und die hybride Suche (Hybrid Search) verbindet den exakten Treffer auf eine Artikelnummer mit dem semantischen Verständnis einer umschreibenden Frage in einer einzigen Abfrage. BatteryIncluded fasst diese Kombination unter Hybrid LLM Search zusammen, das Flaggschiff heißt Volt Search®.

Als Alternative zum entkoppelten Managed-Dienst bleibt der Eigenbetrieb einer Open-Source-Engine wie Elasticsearch, OpenSearch, Solr, Meilisearch oder Typesense. Diese Projekte skalieren technisch durchaus über mehrere Indizes und Mandanten, wie die Skalierungsdokumentation von Elastic zeigt (Elastic, abgerufen 10.09.2026). Der Preis dafür ist der Betrieb dieses Clusters mit eigener Mannschaft. Welche Kosten und welcher Betriebsaufwand daran hängen, gehört in die Betrachtung von Aufbau gegen Einkauf und ist im Beitrag zu SaaS oder Eigenentwicklung sowie in der Gegenüberstellung als Elasticsearch-Alternative aufgeschlüsselt.

Relevanz ohne Tracking

Personalisierung in der Suche kommt bei vielen Anbietern über das Verhalten einzelner Nutzer zustande. Das setzt Datensammlung und Einwilligung voraus.

BatteryIncluded arbeitet cookieless. Die Empfehlungen der AI Recommendations beruhen auf dem Kontext der Anfrage und den Produktdaten, nicht auf einem Verhaltensprofil einzelner Personen. Es gibt keine Kundenprofile, die über Sitzungen hinweg aufgebaut werden.

Für einen Betreiber im DACH-Raum ist das mehr als ein Compliance-Detail. Eine DSGVO-konforme KI ohne Consent-Abhängigkeit vereinfacht den Betrieb und senkt das rechtliche Risiko. Der Anbieter ist als GmbH in Freilassing ansässig, entwickelt in Deutschland und finanziert sich aus eigener Kraft.

Gerade bei der Personalisierung zeigt sich der Architekturunterschied noch einmal. Verhaltensbasierte Personalisierung braucht eine Datenschicht, die Nutzer über Sitzungen hinweg wiedererkennt. Eine kontextbasierte Empfehlung kommt ohne diese Schicht aus und lässt sich damit auch in einem Setup ohne Consent-Banner betreiben. Für internationale Shops mit unterschiedlichen Datenschutzanforderungen je Markt vereinfacht das die Architektur zusätzlich.

Wann ein Plugin genügt

Nicht für jeden Shop ist eine entkoppelte Infrastruktur die richtige Wahl. Wer ein Modul einsetzt und damit gut fährt, hat oft gute Gründe dafür.

Ausreichend ist ein Suchmodul in der Regel, wenn mehrere dieser Bedingungen zusammenkommen:

• Der Katalog umfasst einige hundert bis wenige tausend Artikel und wächst langsam.
• Der Shop bedient einen Markt in einer Sprache.
• Die Produktdaten liegen im Wesentlichen im Shop selbst, ohne komplexe ERP- oder PIM-Landschaft.
• Bestände und Preise ändern sich selten genug, dass ein täglicher Reindex genügt.

In diesem Umfeld wäre eine entkoppelte Infrastruktur überdimensioniert. Der Nutzen der nativen Datenaggregation und der Echtzeit-Synchronisation entfaltet sich erst, wenn Datenquellen, Katalog oder Märkte über einen einzelnen Shop hinauswachsen.

Auch die Infrastruktur nimmt einem Team nicht jede Entscheidung ab. Welche Produkte in einer Kampagne oben stehen, welche Synonyme fachlich Sinn ergeben und welche Sortierung zur Marge passt, entscheidet ein Mensch. Die Suche liefert die Werkzeuge und die Daten, ein Merchandiser steuert die Strategie. Dieses Zusammenspiel aus automatisierter Relevanz und menschlicher Steuerung ist der Regelfall, kein Übergangszustand. Und der Wechsel selbst ist ein Projekt mit Migrationsaufwand, das eine ehrliche Aufwandsschätzung verdient, bevor die erste Zeile Code geschrieben wird.

Eine belastbare Entscheidung beginnt deshalb mit einer Bestandsaufnahme. Wie viele Artikel, wie viele Märkte, wie viele Datenquellen, und wie oft ändern sich die Daten. Fallen die Antworten klein und stabil aus, bleibt ein Modul die pragmatische Wahl. Wachsen sie, verschiebt sich der Aufwand vom laufenden Betrieb des Moduls hin zur einmaligen Migration auf eine Infrastruktur, die den Betrieb danach vereinfacht.

Häufige Fragen

Was unterscheidet Such-Infrastruktur von einem Plugin?
Ein Plugin läuft im Shopsystem und durchsucht einen Index der Daten, die der Shop bereitstellt. Eine Such-Infrastruktur läuft als eigener Dienst daneben, aggregiert Daten nativ aus ERP, PIM, CMS und Shop und wird über eine Such-API angebunden. Der Betrieb ist damit vom Shop entkoppelt.

Wann reicht ein Plugin für die Shop-Suche nicht mehr aus?
Die Grenze zeigt sich meist an drei Stellen. Der Katalog wird zu groß für einen nächtlichen Reindex, die relevanten Daten liegen verteilt in ERP und PIM, oder der Händler skaliert über mehrere Länder und Sprachen. Ab diesem Punkt bremst das im Shop laufende Modul den Betrieb aus.

Welche Suchfunktionen gehören zu einer modernen Produktsuche?
Dazu zählen Fehlertoleranz gegen Tippfehler, Facettensuche zum Filtern großer Trefferlisten, semantische Suche zum Verstehen der Absicht und hybride Suche, die exakte Artikelnummern und vage Anfragen in einer Abfrage verbindet. BatteryIncluded bündelt diese Logik unter Hybrid LLM Search.

Wie skaliert eine Suche über mehrere Shops oder Länder?
Eine entkoppelte Infrastruktur bedient mehrere Storefronts aus einer Instanz, mit sprachabhängiger Analyse je Markt und einem gemeinsamen Relevanzmodell. Das erspart die getrennte Pflege einer eigenen Modul-Instanz pro Shop und hält die Suchqualität über alle Märkte konsistent.

Kann ich meine Shop-Suche selbst hosten?
Der Eigenbetrieb einer Open-Source-Engine wie Elasticsearch, OpenSearch oder Solr ist technisch möglich und für Teams mit eigener Betriebsmannschaft ein gangbarer Weg. Die Kehrseite ist der laufende Aufwand für Cluster, Updates und Relevanzpflege. Ein Managed-Dienst nimmt diesen Betrieb ab, dafür gibt man ein Stück Kontrolle über die Infrastruktur ab.

Was bedeutet Mid-Enterprise im E-Commerce-Kontext?
Gemeint sind Händler zwischen kleinem Standard-Shop und Großkonzern, oft mit fünf- bis sechsstelligen Sortimenten, mehreren Vertriebskanälen und einer gewachsenen Systemlandschaft aus ERP, PIM und CMS. Genau diese Komplexität macht die Datenaggregation zum entscheidenden Kriterium.

Such-Infrastruktur am eigenen Katalog prüfen

BatteryIncluded ist Infrastruktur, kein Plugin. Ob Ihr Sortiment, Ihre Märkte und Ihre Datenquellen den Schritt von einem Modul zur entkoppelten Such-Infrastruktur rechtfertigen, zeigt sich am schnellsten an Ihren eigenen Daten.

In einer kostenlosen Demo sehen Sie Volt Search® an einem Beispiel aus Ihrem Katalog, samt Datenaggregation und Echtzeit-Synchronisation. Für konkrete Architekturfragen erreichen Sie das Team in Freilassing direkt über den Kontakt.