Composable Search Layer als eigene Schicht: Warum Best-of-Breed-Discovery ein entkoppeltes Frontend braucht

Ein Composable Search Layer bedeutet, dass Produkt-Discovery, etwa mit Elasticsuite, Algolia oder Klevu, als eigenständiger Service läuft, den ein entkoppeltes Frontend per API anspricht, statt die Suchergebnisse direkt vom Commerce-Backend rendern zu lassen. Genau diese Trennung macht Best-of-Breed-Discovery austauschbar, testbar und schnell weiterentwickelbar, statt zu einer weiteren Abhängigkeit im Template-Layer deines Backends zu werden.

Was ist ein Composable Search Layer?

Composable Commerce teilt Commerce in unabhängige Services auf, die über APIs verbunden sind: Payment, PIM, Order-Management und Suche sind die klassischen Kandidaten. Suche und Discovery stehen dabei an einer eigenen Stelle. Fast jedes Commerce-Backend liefert ein natives Such-Modul mit, Magentos Catalog Search, Shopwares Standard-Suche, und fast jedes dieser nativen Module wird irgendwann zu klein, sobald Katalogumfang, Merchandising-Anspruch oder Traffic eine bestimmte Grenze überschreiten. Genau deshalb ist Suche zu einer der am weitesten entwickelten Best-of-Breed-Kategorien im Markt geworden, mit dedizierten Anbietern wie Elasticsuite, Algolia, Bloomreach Discovery, Klevu und Coveo, die Relevanz, Facetten und Ranking als eigenständigen Service betreiben.

Ein Composable Search Layer behandelt Discovery als eigene Service-Grenze: Index-Konfiguration, Ranking-Regeln, Synonyme und Merchandising-Logik bleiben im Such-Backend. Die einzige Aufgabe des Frontends ist es, Ergebnisse anzufragen und darzustellen. Sobald diese Grenze klar gezogen ist, wird das Such-Backend unabhängig vom Commerce-Backend austauschbar, und unabhängig vom Frontend, das es darstellt, ebenfalls.

Das Problem: Backend-gebundene Suche stößt an ihre Grenze

Wenn Suche weiterhin über den Render-Zyklus deines Commerce-Backends läuft, durchläuft jede Facetten-Änderung, jede Merchandising-Regel und jedes neue Ergebnis-Layout denselben Release-Prozess wie der Rest der Website, meist mit Developer-Ticket. Ein Growth- oder Merchandising-Team, das eine Promotion boosten oder eine ausgelaufene Produktlinie aus der Suche nehmen will, wartet auf demselben Backlog wie ein Checkout-Bugfix, weil Such-UI und Commerce-UI dieselbe Codebasis sind.

Teams, die ihren Storefront bereits entkoppelt haben, lassen Suche manchmal genau die eine Integration sein, die sie nie richtig fertig gebaut haben. Dieses Muster kennen wir bereits, und es ähnelt stark dem Reife-Kater, den mehrere Composable-Teams derzeit noch aufarbeiten: Der Storefront wurde schnell composable, aber einige Backend-gebundene Abhängigkeiten sind leise geblieben, und Suche ist eine der häufigeren davon.

Wie ein entkoppeltes Frontend ein Best-of-Breed-Such-Backend anspricht

Elasticsuite ist ein hilfreiches Beispiel, weil es Open Source ist und nativ auf Magento, Shopware, Sylius und OroCommerce aufsetzt: virtuelle Kategorien, AI-Vector-Search, Boost-and-Bury-Regeln und verhaltensbasiertes Ranking, ohne einen zusätzlichen SaaS-Suchindex auf einen bereits komplexen Stack zu setzen. In einem Composable-Setup behält Elasticsuite Indexierung, Relevanz und Merchandising-Konfiguration genau wie vorher. Das Frontend fragt Elasticsuites eigene API direkt an, parallel zu den Produkt- und Preisdaten aus dem Commerce-Backend, und rendert Facetten, Autocomplete, Ergebnis-Grids und Merchandising-Banner als eigenständige Frontend-Komponenten.

Genau für diese architektonische Verschiebung ist eine Composable Digital Experience Platform gebaut: Der Frontend-Layer kümmert sich nicht darum, welcher Service welche Daten besitzt, er komponiert die Seite aus dem jeweils zuständigen Backend, Commerce-Backend für Produkt und Preis, Such-Backend für Ranking und Discovery. Laioutr läuft genau als dieses Composable Headless Frontend, und der Standard-Integrationsweg für einen Such-Anbieter ist ein Connector, kein Custom-Engineering-Sprint pro Projekt.

Dieselbe Logik gilt für Teams, die Elasticsuite konkret auf Magento betreiben. Wenn dein Storefront bereits entkoppelt von Magento 2 läuft, berührt das Hinzufügen oder Austauschen eines Best-of-Breed-Such-Layers den Rendering-Code des Storefronts gar nicht, sondern nur den Connector.

Für welches Team sich welche Option lohnt

• Backend-gebundene native Suche: passt bei kleinem Katalog, niedriger SKU-Zahl und ohne dedizierte Merchandising-Rolle, wo Relevanz-Tuning selten passiert und wenig Iteration braucht.
• Eigenbau-Frontend auf einem Best-of-Breed-Such-Backend: passt bei Teams mit genug Engineering-Kapazität, um Facetten-UI, Autocomplete und Ranking-Dashboards dauerhaft selbst zu bauen und zu pflegen, im eigenen Release-Rhythmus.
• Composable Search Layer auf einem Managed Frontend: passt bei Mid-Market- und größeren Katalogen, einer dedizierten Merchandising- oder Growth-Funktion, und Multi-Brand- oder Multi-Locale-Suchverhalten, das ohne Developer-Ticket pro Markt konsistent bleiben muss.

Genau hier zahlt sich eine Agentic Frontend Management Platform speziell für Suche aus: Ein SEO/GEO-Agent kann strukturierte Daten auf Facetten- und Kategorieseiten mit dem synchron halten, was das Such-Backend aktuell rankt, ohne manuelle Übergabe zwischen Merchandising-Team und Engineering. Und wer das gesamte Setup als Frontend as a Service betreibt, verlagert Betriebsmodell, Connector-Pflege, Uptime und Updates für die Such-Integration auf die Plattform statt auf das eigene Backlog.

Was Du gewinnst

• Dimension | Backend-gebundene Suche | Eigenbau-Frontend | Mit Laioutr + Best-of-Breed-Suche
• Neue Facette oder Merchandising-Regel | Dev-Ticket, Wochen | Dev-Ticket, Tage | Merchandiser, Stunden
• Relevanz- und Ranking-Tuning | Backend-Release-Zyklus | eigenes Dashboard nötig | nativ im Such-Backend
• A/B-Test auf Ergebnis-Layout | selten, Backend-gerendert | Dev-gebunden | im Editor, ohne Ticket
• Backend-Wechsel (z. B. weg von Magento) | Such-Logik wird mit umgebaut | Such-Logik wird mit umgebaut | Such-Layer bleibt unberührt

FAQ

Muss ich die native Suche meines Backends ersetzen, um das umzusetzen? Nein. Elasticsuite und vergleichbare Best-of-Breed-Such-Backends laufen meist parallel oder statt des nativen Moduls, und der Wechsel passiert auf Connector-Ebene, nicht im Storefront-Code.

Funktioniert das konkret mit Elasticsuite? Ja. Elasticsuite, und sein Next-Gen-Pendant Gally, ist Open Source und nativ kompatibel mit Magento, Shopware, Sylius und OroCommerce. Index-, Ranking- und Merchandising-Konfiguration bleiben in Elasticsuite, das entkoppelte Frontend fragt Ergebnisse nur an und rendert sie.

Was kostet das? Die Tarife hängen von deinem bestehenden Such-Backend, deiner Katalog-Größe und deinem aktuellen Frontend-Setup ab, kalkulierbar auf laioutr.com/pricing. Der Vergleich, der wirklich zählt, ist nicht gegen "nichts tun", sondern gegen die laufenden Kosten einer selbst gebauten Facetten-UI und eines Ranking-Dashboards.

Wie lange dauert es, einen Composable Search Layer einzuführen? Weil Such-Backend und Commerce-Backend unverändert bleiben und nur die Frontend-Integration neu ist, reden wir über Wochen, nicht über ein Replatforming-Projekt. Typischer Rahmen: 4 bis 6 Wochen bis zur ersten Live-Composable-Search-Erfahrung.

Nächste Schritte

Egal ob du Elasticsuite, Algolia oder Klevu einsetzt oder noch auf das native Such-Modul deines Backends setzt: Buch dir einen Frontend-Architektur-Review für deinen Such-Stack, und wir gehen gemeinsam durch, was die Verlagerung von Discovery in eine eigene Composable-Schicht für dein Team konkret verändert.

Über den Autor: Das Laioutr Team arbeitet täglich mit Enterprise-Dev-Teams daran, Best-of-Breed-Such- und Discovery-Backends wie Elasticsuite mit einem unabhängig betriebenen Composable Frontend zu verbinden, ohne Replatforming-Risiko.