Unified Search im E-Commerce: Content und Produkte in einem Index

Wenn der Kunde "Rückgabe Schuhe" sucht und Schuhe bekommt

Viele E-Commerce-Verantwortliche fragen sich: Warum landet eine Kundin bei einer klaren Service-Frage wie "Rückgabe Schuhe" trotzdem in endlosen Produktlisten? Weil Produkt-Suche und Hilfe-Suche in den meisten Shops auf getrennten Indizes laufen und die Kundin raten muss, welche Suche sie überhaupt öffnen soll. Genau dieses getrennte Index-Modell und seinen Ausweg, die Unified Search, nimmt dieser Artikel Schritt für Schritt auseinander.

Ein Dienstag um 21:14 Uhr, ein DACH-weiter Online-Shop für Schuhe und Sportbekleidung. Eine Kundin hat vor drei Tagen ein Paar Laufschuhe bestellt, die Schuhe sind zwei Nummern zu klein, sie sitzt vor dem Laptop, will den Rücksende-Schein ausdrucken. Sie tippt in die Suchleiste oben rechts "Rückgabe Schuhe" und drückt Enter. Die Ergebnisliste zeigt 248 Laufschuh-Produkte, sortiert nach Beliebtheit, jeder Treffer mit Preis und Verfügbarkeit. Keine Rücksende-Anleitung, keine FAQ-Seite, kein Hinweis auf das Retouren-Portal. Die Kundin scrollt zwei Bildschirmseiten, klickt entnervt auf "Hilfe" im Footer, landet in einer baumartigen Knowledge Base, sucht dort erneut "Rückgabe", findet nach drei Klicks die Anleitung, druckt den Schein und schickt das Paket zurück. Acht Minuten und zwei separate Such-Vorgänge, die in einer einzigen Such-Anfrage hätten enden können.

Das ist nicht ein Einzelfall, das ist die strukturelle Konsequenz eines getrennten Index-Modells, das in den meisten Shop-Systemen Standard ist. Die Produkt-Suche kennt nur Produkte. Die Hilfe-Suche kennt nur Hilfe-Artikel. Der Blog hat seine eigene WordPress-Suche, die FAQ-Seite eine eigene Volltext-Suche, das Service-Portal vielleicht eine dritte. Vier separate Such-Indizes, vier separate Ranking-Logiken, vier separate UX-Pfade. Die Kundin muss erraten, welche Suche sie nutzen soll, bevor sie überhaupt formuliert, was sie sucht.

Die Lösung ist nicht, die UX zu polieren oder Cross-Links zwischen Produkt- und Hilfe-Suche einzubauen. Die Lösung ist, dass die Such-Schicht von Anfang an einen einzigen Index pflegt, in dem Produkte, Kategorien, Blog-Posts, FAQs, Hilfe-Artikel und Service-Pages nebeneinander indiziert sind, jeder Inhaltstyp mit eigenem Schema und eigenen Ranking-Signalen, aber in einem gemeinsamen Suchraum. Diese Architektur heißt Unified Search.

Dieser Artikel beschreibt, was Unified Search im E-Commerce konkret bedeutet. Was im Index passiert, wenn ein Produkt und ein FAQ-Artikel im gleichen Treffer-Set landen. Wie type-aware Ranking funktioniert, ohne dass Inhalte sich gegenseitig verdrängen. Wann eine Tabbed View, eine gemischte Ergebnisliste oder ein Best-of-each-Block die richtige UX ist. Und wie die Hybrid LLM Search den Inhaltstyp aus der Anfrage erkennt und passend routet, statt dem Kunden die Routing-Entscheidung zu überlassen.

Was Unified Search ist und was sie von federierter Suche unterscheidet

Bedeuten Unified Search und federierte Suche nicht ohnehin dasselbe?

Die Begriffe Unified Search, federierte Suche, Site Search und Universal Search werden in der Praxis durcheinander geworfen. Die Unterscheidung ist nicht nur akademisch, sie hat handfeste Implikationen für Performance, Ranking und Pflege.

Die federierte Suche operiert auf mehreren getrennten Indizes parallel. Die Such-Anfrage wird an den Produkt-Index, an den Blog-Index, an den Knowledge-Base-Index gleichzeitig geschickt. Jede der drei Quellen liefert ein eigenes Ergebnis-Set zurück, die UI vereint die Ergebnisse in einer Anzeige, typisch in Tabs oder in nebeneinander dargestellten Spalten. Die Architektur ist relativ einfach umzusetzen, weil die bestehenden Such-Systeme unverändert bleiben. Der Preis ist, dass eine gemeinsame Relevanz-Bewertung über alle Quellen praktisch nicht möglich ist, weil die Such-Scores aus unterschiedlichen Ranking-Logiken stammen und nicht vergleichbar sind. Die UI muss die Tabs anbieten und dem Kunden die Routing-Entscheidung überlassen.

Die Unified Search operiert auf einem einzigen, gemeinsamen Index. Produkte, Blog-Posts, FAQs und Hilfe-Artikel werden mit jeweils eigenem Schema in den gleichen Suchraum indiziert. Die Such-Anfrage trifft den einen Index, das Ranking-System bewertet alle Treffer in einem gemeinsamen Bewertungs-Modell, das die Inhaltstyp-Unterschiede explizit kennt. Das Ergebnis ist eine einzige Treffer-Liste, die Produkte und Content sinnvoll mischen oder sortiert in Bereiche aufteilen kann, ohne dass die Treffer aus inkonsistenten Ranking-Welten stammen.

Die Unterscheidung ist nicht akademisch, weil die federierte Suche an einer strukturellen Grenze scheitert: das Ranking kann nie wirklich konsistent sein. Wenn der Produkt-Index einen Treffer mit Score 0.87 zurückgibt und der Blog-Index einen Treffer mit Score 1.34, ist nicht entscheidbar, welcher Treffer für die Kundin relevanter ist, weil die Scores aus unterschiedlichen Welten kommen. Die Unified Search löst das, indem sie alle Treffer im gleichen Bewertungs-Modell scort, mit klaren Gewichten pro Inhaltstyp.

Eine vierte Variante, die manchmal als Unified Search verkauft wird, ist die Trefferlisten-Vermischung. Hier liegen die Inhalte weiter in getrennten Indizes, aber die Ergebnis-Listen werden nach einem regelbasierten Schema verschmolzen ("immer drei Produkte vorne, dann ein Hilfe-Artikel, dann wieder Produkte"). Das ist UX-Kosmetik ohne echte Ranking-Konsistenz. Im weiteren Verlauf dieses Artikels meinen wir mit Unified Search ausschließlich die Index-Vereinigung mit gemeinsamem Bewertungs-Modell.

Was im Index passiert: ein Schema, mehrere Inhaltstypen

Wie bringt ein einziger Index Produkte, FAQ, Blog und Hilfe-Artikel unter ein Dach?

Die zentrale Engineering-Frage der Unified Search ist, wie ein einzelner Index unterschiedliche Schemata sauber aufnimmt. Ein Produkt hat Felder wie Artikelnummer, Hersteller, Preis, Verfügbarkeit, Kategorie-Pfad, Bildschirmdiagonale, Material. Ein FAQ-Artikel hat Frage, Antwort, Kategorie, vielleicht Tags. Ein Blog-Post hat Titel, Lead-Absatz, Autor, Veröffentlichungsdatum, Kategorie, Body-Text. Ein Hilfe-Artikel hat Titel, Step-Liste, Screenshots, Kategorie-Pfad. Ein Suchindex, der alle vier aufnimmt, muss die unterschiedlichen Felder modellieren, ohne dass die fehlenden Felder eines Inhaltstyps die Treffer-Logik kippen.

Die saubere Lösung ist ein Index-Schema mit gemeinsamen Pflichtfeldern und typ-spezifischen optionalen Feldern. Gemeinsame Pflichtfelder sind in jedem Dokument vorhanden, unabhängig vom Typ: eine eindeutige ID, ein Inhaltstyp ("product", "faq", "blog", "help"), ein Titel, ein Volltext-Body, eine URL, ein Sprach-Code, ein Land-Code. Typ-spezifische Felder existieren nur dort, wo sie passen: ein Preis-Feld existiert nur für Produkte, ein Veröffentlichungs-Datum nur für Blog und Hilfe, ein Hersteller nur für Produkte, ein Autor nur für Blog.

Die Implementierung im modernen Such-Backend nutzt typisch ein Dokument-orientiertes Modell, etwa über Elasticsearch- oder OpenSearch-Indizes mit dynamischem Mapping. Die Pflichtfelder sind im Mapping fest definiert, die typ-spezifischen Felder werden per Convention angelegt, etwa über ein Präfix ("product_price", "blog_published_at", "help_step_count"). Das vermeidet Schema-Konflikte, hält die Pflege überschaubar und erlaubt der Ranking-Schicht, typ-spezifische Boost-Faktoren anzuwenden, ohne dass die Grund-Anfrage komplex wird.

Eine spezielle Herausforderung ist die Volltext-Strukturierung. Ein Produkt hat einen kurzen Titel und eine Produktbeschreibung. Ein Blog-Post hat einen langen Body mit Zwischenüberschriften und Beispielen. Wenn beide Inhaltstypen einen einzigen Volltext-Body-Field bekommen, dominiert der Blog-Post die TF-IDF-Statistik, weil er mehr Wörter enthält, und schlägt das Produkt bei jedem semantischen Match. Die saubere Lösung ist eine pro-Typ-Normalisierung der Volltext-Länge, die die längeren Content-Dokumente nicht durch reine Wort-Häufigkeit bevorteilt.

Die Pflicht eines konsistenten Sprach- und Land-Codes pro Dokument ist nicht trivial. Wenn die Produkt-Daten in zwölf Sprachen vorliegen und der Blog nur in vier, muss die Such-Schicht die Treffer-Menge sauber pro Sprach-Profil filtern, sonst zeigt sie der österreichischen Kundin französische Blog-Posts. Wir haben die Mehrsprachen-Logik im Beitrag zur Multi-Country-Search-Infrastruktur im Detail beschrieben. Im Unified-Search-Kontext ist die Sprach-Konsistenz die Grundbedingung, ohne die das gemeinsame Bewertungs-Modell falsche Treffer-Sets erzeugt.

Type-Aware Ranking: warum Produkte und Content unterschiedlich gewichtet werden

Warum reicht es nicht, alle Treffer einfach nach demselben Relevanz-Score zu sortieren?

Sobald Produkte und Content in einem Index liegen, muss das Ranking-System wissen, wie es typ-übergreifend gewichtet. Ein reines TF-IDF-Modell, das alle Treffer gleich behandelt, produziert die typischen Pathologien: ein langer FAQ-Artikel, der "Schuhe" 17-mal erwähnt, schlägt jeden einzelnen Schuh-Treffer, weil seine Term-Häufigkeit höher ist. Oder umgekehrt: ein Produkt-Titel "Adidas Lauf-Schuh Pro" matcht so präzise auf "Schuhe", dass jeder relevante Blog-Post hinten landet, auch wenn die Such-Intention "Rückgabe Schuhe" eindeutig auf Content zielt.

Type-Aware Ranking löst das, indem es pro Inhaltstyp eigene Boost-Faktoren und Such-Signale anwendet. Die Mechanik hat vier Komponenten.

Erstens, Intent-Gewichtung. Die Such-Anfrage wird vor der Treffer-Berechnung klassifiziert. Eine Anfrage wie "Adidas Laufschuhe 42" hat hohe Produkt-Intent, eine Anfrage wie "Rückgabe Schuhe" hat hohe Content-Intent, eine Anfrage wie "passt der Lauf-Schuh in den Briefkasten" hat gemischte Intent. Die Klassifizierung kann regelbasiert (Modell-Wörter, Marken-Wörter, Größen-Angaben deuten auf Produkt-Intent, Begriffe wie "Rückgabe", "Lieferzeit", "Anleitung" deuten auf Content-Intent) oder ML-getrieben sein. Die Klassifizierung beeinflusst die Typ-Gewichte für die Treffer-Auswahl.

Zweitens, Typ-spezifische Felder-Gewichtung. Innerhalb eines Inhaltstyps bekommen unterschiedliche Felder unterschiedliche Gewichte. Bei Produkten wiegt ein Match im Titel und in der Artikelnummer schwerer als ein Match im Beschreibungs-Text. Bei FAQs wiegt ein Match in der Frage schwerer als in der Antwort. Bei Blog-Posts wiegt ein Match im Titel und in der H2-Struktur schwerer als im Body-Text. Die Feld-Gewichte werden pro Typ konfiguriert, sodass die Treffer-Logik typ-spezifisch greift.

Drittens, Listing-Score-Faktoren pro Typ. Produkte bekommen Boost-Signale aus Verkaufsdaten, Konversions-Rate, Marge, Lager-Status. Content bekommt Boost-Signale aus Aktualität, Click-Through-Rate auf der Treffer-Liste, Nutzungs-Häufigkeit im Hilfe-Center. Die Listing-Score-Mechanik haben wir im Beitrag zu Textscore und smarten Listings im Detail beschrieben. Im Unified-Search-Kontext ist sie typ-spezifisch konfiguriert: jeder Inhaltstyp hat sein eigenes Listing-Score-Profil.

Viertens, Cross-Type-Penalty bei niedriger Intent-Klarheit. Wenn die Anfrage klar Produkt-Intent hat ("Adidas 42"), werden Content-Treffer mit einem Penalty-Faktor gewichtet, der sie nach unten drückt, ohne sie ganz auszublenden. Wenn die Anfrage klar Content-Intent hat ("Wie lange dauert die Rückgabe"), werden Produkt-Treffer entsprechend gepenalisiert. Bei gemischter Intent ("passt der Lauf-Schuh in den Briefkasten") bleibt die Gewichtung neutral, beide Typen erscheinen ausgewogen.

Eine fünfte Komponente, die in der Praxis oft übersehen wird, ist die Treffer-Diversität. Wenn das Ranking ausschließlich nach Relevanz-Score sortiert, kann eine einzelne Inhaltstyp-Klasse die Top-10 dominieren, weil die Scores zufällig zusammenfallen. Eine Diversitäts-Logik sorgt dafür, dass die Top-Treffer mindestens einen Repräsentanten pro relevantem Inhaltstyp enthalten, sofern die Treffer-Menge das hergibt. Bei einer Anfrage "Schuhe pflegen" landen so nicht zehn Pflege-Tipps-Blog-Posts in den Top-10, sondern drei Pflege-Anleitungen und sieben passende Pflege-Produkte.

Tabbed View, Mixed List, Best-of-each: die drei UX-Pattern

Wie präsentiere ich Produkte und Content in einer Trefferliste, ohne die Kundin zu verwirren?

Die UX der Unified Search ist die zweite Hälfte der Architektur. Die saubere Index-Schicht und das type-aware Ranking liefern eine sortierte Treffer-Menge, aber die Frage bleibt, wie diese der Kundin präsentiert wird. Drei Pattern haben sich in der Praxis etabliert.

Das erste ist die Tabbed View. Die Treffer werden in Tabs nach Inhaltstyp aufgeteilt, typisch "Produkte", "Hilfe", "Blog", "FAQ". Der Standard-Tab ist meist "Produkte", weil die Mehrheit der Such-Anfragen Produkt-Intent hat. Die Kundin sieht in jedem Tab die Trefferzahl als Badge und kann zwischen den Tabs wechseln. Vorteil: klare Trennung, kein Mix-Up zwischen Produkten und Content. Nachteil: die Kundin muss raten, in welchem Tab das Gesuchte liegt, was das Anfangs-Problem nur verschiebt. Bei klar getrennter Such-Intent funktioniert die Tabbed View, bei gemischter Intent zwingt sie die Kundin zu mehreren Klicks.

Das zweite Pattern ist die Mixed List. Alle Treffer erscheinen in einer einzigen, gemischten Liste, sortiert nach Relevanz-Score. Jeder Treffer ist durch ein Typ-Badge ("Produkt", "FAQ", "Anleitung") gekennzeichnet, sodass die Kundin auf einen Blick erkennt, was sie anklickt. Vorteil: die Such-Logik liefert die beste Antwort unabhängig vom Typ, die Kundin muss keine Routing-Entscheidung treffen. Nachteil: bei reinen Produkt-Intent-Anfragen wirken vereinzelte Content-Treffer wie Störung, die Conversion-Rate kann leiden, wenn Content-Treffer Click-Through abziehen.

Das dritte Pattern ist der Best-of-each-Block, manchmal auch "Top Result" oder "Featured Result" genannt. Die Treffer-Liste zeigt oben einen kompakten Block mit dem besten Treffer pro Inhaltstyp ("Beste Antwort", "Top-Produkt", "Passende Anleitung"), darunter folgt die gemischte Liste oder die Produkt-Liste als Standard. Vorteil: die Kundin sieht die typ-spezifischen Top-Antworten sofort, ohne Tab-Klicks oder Scroll-Wege. Nachteil: die UI ist komplexer, der Best-of-each-Block kostet vertikalen Raum, der Mobile-Bereich wird eng.

In der Praxis hat sich eine Hybrid-Variante als richtig erwiesen. Reine Produkt-Intent-Anfragen werden direkt in die Produkt-Liste geroutet, mit einem kompakten "Hilfe gesucht? Antwort hier" Cross-Type-Link am Seitenrand. Reine Content-Intent-Anfragen werden in eine Content-Tabbed-View mit FAQ-Tab als Standard geroutet. Gemischte Intent-Anfragen bekommen den Best-of-each-Block oben und darunter die gemischte Liste. Die Routing-Entscheidung trifft das System, nicht die Kundin.

Eine Geschäftsführung aus einem österreichischen B2C-Shop für Versicherungen mit Direkt-Verkaufs-Komponente beschreibt den Effekt einer sauberen Unified-Search-UX so:

"BatteryIncluded hat uns als kompetenter Sparringspartner geholfen, das Beste aus Volt zu machen, das uns als Lösung für unseren Direktversicherer überzeugt hat. Die Zusammenarbeit war produktiv, die Lösung greift im Live-Betrieb sauber und der Effekt auf unsere Kennzahlen ist messbar."

ÖBV Versicherung

Im Versicherungs-Kontext sind Produkt-Anfragen und Content-Anfragen besonders stark vermischt. Eine Kundin sucht "Hausratversicherung Wert berechnen", was sowohl auf ein Versicherungs-Produkt als auch auf einen Erklär-Artikel zielen kann. Eine sauber geroutete Unified Search liefert beides ohne Tab-Sprung, mit klarer Typ-Kennzeichnung und mit der Top-Antwort sichtbar im ersten Bildschirm.

Cross-Type-Suggestion: wenn eine Anfrage zwei Typen kombiniert

Was passiert, wenn eine Suchanfrage eigentlich zwei Inhaltstypen gleichzeitig meint?

Eine Sonderform der Unified Search ist die Cross-Type-Suggestion, die eine Anfrage proaktiv um den ergänzenden Inhaltstyp anreichert. Die Kundin tippt "Größentabelle", das System erkennt Content-Intent und liefert die Größentabellen-Seite. Gleichzeitig blendet das Autocomplete-Panel rechts daneben eine Liste der häufigsten Produkte in den nachgefragten Größen ein, sodass die Kundin nach Klick auf die Größe direkt die passenden Produkte sieht.

Die Mechanik nutzt die Anfrage-Klassifizierung und die ergänzende Beziehungs-Logik zwischen Inhaltstypen. Eine Größentabelle hat einen impliziten Bezug zu Produkten, weil sie typisch zum Größen-Vergleich vor dem Kauf konsultiert wird. Ein Rückgabe-FAQ hat einen impliziten Bezug zu jüngst gekauften Produkten, weil die Kundin meist ein konkretes Produkt zurückgeben will. Ein Wartungs-Hilfe-Artikel hat einen impliziten Bezug zum Ersatzteil-Sortiment. Diese Beziehungen werden im Index als typ-übergreifende Verknüpfungen modelliert.

Die UX hat zwei verbreitete Implementierungen. Die erste ist die Inline-Suggestion innerhalb des Autocomplete-Panels, das wir im Beitrag zu Autocomplete-Vorschlägen und Conversion im Detail beschrieben haben. Die Cross-Type-Suggestion erscheint dort als eigene Vorschlags-Klasse, kenntlich gemacht durch ein Typ-Icon. Die zweite Implementierung ist die seitliche Empfehlungs-Spalte auf der Treffer-Liste, die die ergänzenden Treffer aus dem anderen Inhaltstyp zeigt.

In beiden Fällen entscheidet die Such-Schicht aktiv, welche typ-übergreifende Suggestion sinnvoll ist. Eine reine Produkt-Anfrage muss nicht automatisch Hilfe-Artikel anziehen, eine reine FAQ-Anfrage muss nicht automatisch Produkte anbieten. Die Cross-Type-Suggestion ist eine ergänzende Schicht, die dort greift, wo die Beziehung zwischen Typen empirisch nachweisbar zu höherer Conversion oder höherer Self-Service-Rate führt.

Schema, Indexierung und WordPress-Anbindung in der Praxis

Die Unified Search ist nicht nur ein Backend-Konzept, sie hat eine konkrete Indexierungs-Pflicht. Welche Inhalte lohnen sich tatsächlich, in den gemeinsamen Index aufzunehmen? Die Faustregel folgt der Such-Intent. Inhalte, die regelmäßig in Such-Anfragen auftauchen, gehören in den Index. Inhalte, die nie gesucht werden, sind Index-Ballast.

Typische lohnenswerte Inhaltstypen für DACH-E-Commerce-Shops sind: Produkte und Produkt-Kategorien (Pflicht), FAQs und Hilfe-Center-Artikel (hoher Self-Service-Wert), Blog-Posts mit Ratgeber-Charakter (Content-Marketing-Wert plus Self-Service), Service-Pages wie Versand, Rückgabe, Garantie (Vertragspflicht-Inhalte), Anleitungen und Tutorials (Post-Sale-Self-Service), Marken- und Hersteller-Seiten (Trust-Signale). Eher unverzichtbar im Index sind Allgemeine Geschäftsbedingungen, Impressum, Datenschutz, weil sie kaum gesucht und meist über Footer-Links erreicht werden.

Die Schema-Modellierung erfolgt typ-spezifisch. Produkte folgen typisch Schema.org/Product mit GTIN, Marke, Angebot, Bestand. FAQs folgen Schema.org/FAQPage mit Frage-Antwort-Paaren. Blog-Posts folgen Schema.org/Article mit Autor, Datum, Headline. Hilfe-Artikel folgen Schema.org/HowTo mit Step-Liste, Materialien, geschätzter Zeit. Im Index werden diese Schemata als typ-spezifische Felder abgebildet, ohne dass die Schema-Struktur die Such-Logik beeinflusst.

Die WordPress-Anbindung ist hier eine besonders relevante Praxis-Frage. Viele DACH-Shops fahren ihre Produkt-Schicht auf Shopware oder Magento, der Content-Bereich (Blog, Service-Pages, Knowledge Base) läuft aber auf WordPress, oft als headless Setup mit eigenem Theme. Die Unified Search muss beide Quellen sauber indizieren. In der Praxis erfolgt das über zwei parallele Indexierungs-Pipelines: eine, die das Produkt-System per Webhook oder periodischem Sync indiziert, und eine, die WordPress über die REST-API oder den WP-CLI-Export indiziert.

Die WordPress-Indexierung deckt Posts, Pages und Custom-Post-Types ab. Wir indizieren typisch FAQs, Glossar-Einträge, Anleitungen und Service-Pages als eigene Custom-Post-Types, weil sie eigene Schema-Felder benötigen. Das standard-WordPress-Suchsystem wird damit überflüssig, die WordPress-eigenen Suche-Endpoints können stillgelegt werden, weil die Unified Search alle WordPress-Inhalte sauber bedient. Die Pflege bleibt im WordPress-Backend, die Indexierung läuft automatisch im Hintergrund, der Editor merkt nichts vom Such-Index.

Eine Geschäftsführung aus einem deutschen Großhandel für Werkzeug und Industriebedarf beschreibt den operativen Effekt der CMS-Anbindung so:

"Die Suche ist bei uns ein entscheidender Faktor für Conversion. BatteryIncluded liefert die Qualität und die Geschwindigkeit, die ein professioneller Großhandel braucht, und das Team versteht unser Geschäft."

G. Wurm GmbH & Co. KG

Im B2B-Großhandel sind Content-Inhalte (Anwendungs-Anleitungen, Sicherheits-Hinweise, Branchen-Hintergründe) ein eigener Conversion-Treiber neben den Produkten. Eine Unified Search, die Anleitungen und Produkte gleichwertig findet, macht den Unterschied zwischen einer abgebrochenen Recherche und einem abgeschlossenen Kauf.

Hybrid LLM Search, Cookieless und Performance bei einem großen Index

Eine Schicht, die die deterministische Index- und Ranking-Logik der Unified Search ergänzt, ist die natürlich-sprachliche Anfrage-Verarbeitung. Die Kundin tippt nicht "type:faq Rückgabe Schuhe", sondern formuliert frei: "Wie kann ich meine Laufschuhe zurückschicken, die zu klein sind?". Die Hybrid LLM Search interpretiert diese Anfrage, erkennt die Content-Intent ("zurückschicken"), erkennt das Produkt-Subjekt ("Laufschuhe"), erkennt die Größen-Problematik ("zu klein") und routet die Anfrage entsprechend: primär in die Hilfe-Artikel zur Rückgabe-Abwicklung, sekundär in die Hilfe-Artikel zur Größen-Beratung, mit einem Cross-Type-Block zu den eigenen jüngst gekauften Laufschuhen, sofern Session-Kontext ohne Tracking verfügbar ist.

Die Mechanik nutzt drei Schichten parallel. Die Keyword-Schicht identifiziert die exakten Treffer im Index. Die Vektor-Schicht findet semantisch ähnliche Treffer, auch wenn die exakten Worte nicht im Index stehen ("zurückschicken" matcht auf "Retoure" und "Rückgabe"). Die LLM-Schicht interpretiert die Anfrage als ganzes und entscheidet das Routing, ohne dass sie selbst die Treffer erzeugt. Die Treffer kommen weiterhin aus dem deterministischen Index, das LLM ordnet sie ein und gewichtet sie. Eine reine LLM-Antwort ohne Index-Treffer würde halluzinieren, das ist hier ausgeschlossen.

Diese Architektur ist vollständig cookieless. Die Such-Schicht baut keine User-Profile, sie speichert keine Sitzungs-Daten in einer Form, die Personen identifiziert, sie ist auf Aggregat-Ebene des Sortiments und der typischen Such-Muster operativ. Das macht sie DSGVO-konforme KI, ohne dass der Shop-Betreiber Cookie-Banner für die Such-Schicht erweitern oder Tracking-Pixel pflegen muss. Die Cohort-Auswertung der Such-Muster liefert dem Betreiber die Optimierungs-Signale für die Type-Ranking-Gewichte und die Cross-Type-Suggestion-Logik, ohne dass eine personenbezogene Datenspur entsteht.

Die Performance-Frage bei einem einzigen, großen Index ist die letzte Architektur-Komponente. Ein gemeinsamer Index ist potenziell größer als die getrennten Einzel-Indizes zusammen, weil pro Dokument zusätzliche typ-übergreifende Felder gehalten werden. Die Lese-Performance hängt an drei Stellschrauben: einer sauberen Mapping-Struktur, die typ-spezifische Filter direkt im Such-Pfad erlaubt, einem Caching-Layer für die häufigen Anfragen, und einem Replica-Setup, das die Suchlast horizontal skaliert.

In der Praxis sind moderne Such-Backends (Elasticsearch, OpenSearch, Typesense, Meilisearch) für Indizes mit mehreren Millionen Dokumenten ausgelegt. Die typische DACH-E-Commerce-Größenordnung von 50.000 Produkten plus 5.000 Blog-Posts plus 800 FAQs ist für ein modernes Such-Backend keine Last-Frage, sondern eine Konfigurations-Frage. Die Unified Search ist ein architektonischer Schritt, kein Performance-Risiko.

Diese Architektur ist die Auspraegung der entkoppelten Infrastruktur, die wir als BatteryIncluded propagieren. Die Such-Schicht ist eigenständig, sie operiert unabhängig vom Shop-Backend und vom CMS, sie vereint Produkte und Content in einem zentralen Layer. Made in Germany als Hosting-Standort komplettiert das DACH-Vertrauens-Argument. Eine Sonderform, die wir in einem späteren Beitrag zu Similar Search vertiefen, ist die typ-übergreifende Ähnlichkeits-Logik, die für ein angesehenes Produkt die thematisch passenden Hilfe-Artikel und Blog-Beiträge mit vorschlägt.

Was Sie diese Woche tun können

Wo fange ich an, wenn ich Produkte und Content zusammenführen will?

Wenn Sie heute getrennte Such-Systeme für Produkte und Content betreiben, ist die folgende Reihenfolge der pragmatische Einstieg.

Schritt eins ist die Inhaltstyp-Inventur. Listen Sie auf, welche Inhalts-Quellen in Ihrem Shop heute eine eigene Suche haben: Produkt-Suche, Hilfe-Center, Blog, FAQ, Service-Bereich. Erheben Sie pro Quelle das ungefähre Dokument-Volumen und die Such-Anfragen-Zahl pro Monat. Diese Inventur zeigt, welche Quellen tatsächlich Such-Last erzeugen und welche stillgelegt werden können.

Schritt zwei ist die Such-Intent-Analyse. Werten Sie aus, welche Such-Anfragen in Ihrer aktuellen Produkt-Suche zu Null-Treffer oder zu Klicks auf den Hilfe-Bereich führen, und welche Such-Anfragen in Ihrer Hilfe-Suche typischerweise auf Produkte zielen. Diese Doppel-Such-Pfade sind die quantitative Begründung für die Unified Search, weil sie zeigen, wo die Kundin heute zwischen Systemen wechseln muss.

Schritt drei ist die Schema-Definition. Modellieren Sie die gemeinsamen Pflichtfelder (ID, Typ, Titel, Body, URL, Sprache, Land) und die typ-spezifischen Felder pro Inhaltstyp. Halten Sie das Schema schlank, beginnen Sie mit den zwei wichtigsten Typen (Produkt plus FAQ) und erweitern Sie schrittweise auf Blog, Hilfe und Service-Pages.

Schritt vier ist die Indexierungs-Pipeline. Verbinden Sie Ihr Produkt-System und Ihr CMS an die gemeinsame Indexierungs-Schicht, typisch über Webhooks (Live-Updates) plus periodischen Voll-Sync (Konsistenz-Sicherung). Die Pipeline muss Lösch-Events sauber behandeln, sonst sammeln sich verwaiste Treffer im Index, die zu toten Links führen.

Schritt fünf ist das Type-Aware Ranking. Definieren Sie die Intent-Klassifizierung (regelbasiert reicht für den Start), die typ-spezifischen Feld-Gewichte und die Cross-Type-Penalty bei klarer Intent. Testen Sie auf Ihren häufigsten 50 Such-Anfragen, ob die Treffer-Reihenfolge der Kunden-Erwartung entspricht.

Schritt sechs ist die UX-Entscheidung. Wählen Sie das Pattern (Tabbed View, Mixed List, Best-of-each), das zu Ihrem Inhalts-Mix passt. Im Zweifel beginnen Sie mit der Mixed List plus Typ-Badges, weil sie die Routing-Entscheidung vom Kunden weg in die Such-Schicht verlagert.

Diese sechs Schritte sind in jedem Fall sinnvoll, unabhängig davon, ob Sie später auf eine spezialisierte Such-Infrastruktur wechseln oder Ihre vorhandene Lösung optimieren. Was sie nicht ersetzen können, ist die operative Reife einer Such-Plattform, die die Unified-Search-Schicht out of the box mitbringt, die WordPress-Anbindung über REST-API und Custom-Post-Type-Support standardisiert, die Hybrid LLM Search als Intent-Router integriert und die Cohort-Auswertung zur kontinuierlichen Optimierung der Type-Ranking-Gewichte bereitstellt.

Häufige Fragen (FAQ)

Was ist Unified Search im E-Commerce?

Unified Search bezeichnet eine Such-Architektur, bei der Produkte, Kategorien, FAQs, Blog-Posts, Hilfe-Artikel und Service-Pages in einem einzigen Suchindex liegen und mit einem gemeinsamen Bewertungs-Modell gerankt werden. Die Kundin sieht alle relevanten Treffer in einer Antwort, ohne zwischen Produkt-Suche, Hilfe-Suche und Blog-Suche wechseln zu müssen. Im Gegensatz zur federierten Suche, die mehrere getrennte Indizes parallel abfragt und die Ergebnisse in einer UI vereint, operiert die Unified Search auf einem gemeinsamen Index mit type-aware Ranking. Die Treffer sind über alle Inhaltstypen hinweg im gleichen Score-Modell vergleichbar.

Was ist der Unterschied zwischen Unified Search und federierter Suche?

Federierte Suche operiert auf mehreren getrennten Indizes parallel. Die Anfrage wird an Produkt-Index, Blog-Index und Knowledge-Base-Index gleichzeitig geschickt, jede Quelle liefert ein eigenes Ergebnis-Set zurück, die UI vereint die Ergebnisse meist in Tabs. Das Ranking über alle Quellen ist nicht konsistent, weil die Scores aus unterschiedlichen Such-Welten stammen. Unified Search operiert auf einem einzigen, gemeinsamen Index mit type-aware Ranking, das alle Treffer im gleichen Bewertungs-Modell scort. Die Treffer-Liste ist konsistent gerankt, die Kundin muss keine Routing-Entscheidung zwischen Tabs treffen.

Welche Inhaltstypen gehören in den Unified-Search-Index?

Die Faustregel folgt der Such-Intent. Inhalte, die regelmäßig in Such-Anfragen auftauchen, gehören in den Index. Typische lohnenswerte Inhaltstypen für DACH-E-Commerce-Shops sind Produkte und Produkt-Kategorien (Pflicht), FAQs und Hilfe-Center-Artikel (hoher Self-Service-Wert), Blog-Posts mit Ratgeber-Charakter (Content-Marketing-Wert), Service-Pages wie Versand, Rückgabe, Garantie (Vertragspflicht-Inhalte), Anleitungen und Tutorials (Post-Sale-Self-Service) und Marken- oder Hersteller-Seiten (Trust-Signale). Eher unverzichtbar im Index sind AGB, Impressum und Datenschutz, weil sie selten gesucht und meist über Footer-Links erreicht werden.

Wie funktioniert type-aware Ranking?

Type-aware Ranking gewichtet Treffer pro Inhaltstyp mit eigenen Boost-Faktoren und Ranking-Signalen. Die Such-Anfrage wird vor der Treffer-Berechnung klassifiziert, ob sie Produkt-Intent, Content-Intent oder gemischte Intent hat. Innerhalb eines Typs werden die einzelnen Felder unterschiedlich gewichtet, etwa Titel und Artikelnummer schwerer als Beschreibungs-Text bei Produkten, Frage schwerer als Antwort bei FAQs, Titel und H2-Struktur schwerer als Body-Text bei Blog-Posts. Pro Typ greifen eigene Listing-Score-Faktoren, etwa Konversions-Rate für Produkte und Aktualität für Blog-Posts. Bei klarer Intent werden Treffer des nicht passenden Typs mit einem Penalty-Faktor nach unten gewichtet, ohne sie ganz auszublenden.

Tabbed View oder gemischte Liste, was ist besser?

Die richtige UX hängt vom Inhalts-Mix und der typischen Such-Intent ab. Eine Tabbed View trennt die Treffer in Tabs nach Inhaltstyp und funktioniert bei klar getrennter Intent, zwingt die Kundin bei gemischter Intent aber zu mehreren Klicks. Eine Mixed List zeigt alle Treffer in einer Liste mit Typ-Badges und überlässt das Routing dem Ranking-System, was bei gemischter Intent besser greift, bei reinen Produkt-Anfragen aber Content-Treffer als Störung wirken können. Ein Best-of-each-Block oben in der Treffer-Liste plus eine Mixed List darunter ist die Hybrid-Variante, die in den meisten Fällen die richtige Antwort liefert. In der Praxis wählt das System das Pattern dynamisch nach der erkannten Intent.

Funktioniert Unified Search mit WordPress?

Ja, die WordPress-Anbindung ist ein Standard-Anwendungsfall der Unified Search. Die Indexierung läuft typisch über die WordPress-REST-API oder einen WP-CLI-Export und deckt Posts, Pages und Custom-Post-Types ab. FAQs, Glossar-Einträge, Anleitungen und Service-Pages werden als eigene Custom-Post-Types modelliert, weil sie eigene Schema-Felder benötigen. Das standard-WordPress-Suchsystem wird damit überflüssig, die WordPress-eigenen Such-Endpoints können stillgelegt werden, weil die Unified Search alle WordPress-Inhalte sauber bedient. Die Pflege bleibt im WordPress-Backend, die Indexierung läuft automatisch im Hintergrund, der Redakteur merkt nichts vom Such-Index.

Wie schnell ist Unified Search bei einem großen Index?

Ein gemeinsamer Index ist potenziell größer als die getrennten Einzel-Indizes zusammen, weil pro Dokument zusätzliche typ-übergreifende Felder gehalten werden. Moderne Such-Backends wie Elasticsearch, OpenSearch, Typesense oder Meilisearch sind für Indizes mit mehreren Millionen Dokumenten ausgelegt. Die typische DACH-E-Commerce-Größenordnung von 50.000 Produkten plus 5.000 Blog-Posts plus 800 FAQs ist für ein modernes Such-Backend keine Last-Frage, sondern eine Konfigurations-Frage. Die Lese-Performance hängt an einer sauberen Mapping-Struktur, einem Caching-Layer für häufige Anfragen und einem Replica-Setup für horizontale Skalierung. Die Antwort-Zeit pro Suche liegt im Bereich weniger zehn Millisekunden.

Ist Unified Search DSGVO-konform?

Eine sauber gebaute Unified Search ist vollständig cookieless und DSGVO-konform, weil sie keine personenbezogenen Sitzungs-Daten speichert und keine User-Profile aufbaut. Die Such-Schicht operiert auf Aggregat-Ebene der Sortiments- und Such-Muster. Die Cohort-Auswertung liefert Optimierungs-Signale ohne personenbezogene Datenspur. Der Shop-Betreiber muss seinen Cookie-Banner nicht um die Such-Schicht erweitern und keine Tracking-Pixel pflegen. Wenn die Such-Plattform Made in Germany gehostet wird, kommt die räumliche DSGVO-Sicherheit als zusätzliches Vertrauens-Argument dazu, das im DACH-Markt besonders relevant ist.

Bereit für eine Suche, die Produkte und Content in einer Antwort liefert?

Unified Search ist kein UX-Polish, sondern eine strukturelle Entscheidung über die Architektur der Such-Schicht. Wer Produkte und Content in einem Index vereint, gewinnt Self-Service-Rate, Click-Through-Rate auf den Treffern und Conversion-Rate über das gesamte Sortiment, weil die Kundin nicht mehr zwischen Produkt-Suche und Hilfe-Suche wechseln muss, sondern in einer Anfrage die passende Antwort findet. Volt Search® von BatteryIncluded ist als entkoppelte Infrastruktur konzipiert, die die Unified-Search-Schicht out of the box mitbringt, die WordPress-Anbindung über REST-API und Custom-Post-Type-Support standardisiert, das type-aware Ranking pro Inhaltstyp konfigurierbar macht und die UX-Pattern (Tabbed View, Mixed List, Best-of-each) dynamisch nach erkannter Such-Intent routet. Hybrid LLM Search ergänzt die Intent-Klassifizierung um eine natürlich-sprachliche Schicht und mappt Anfragen wie "Wie kann ich meine Laufschuhe zurückschicken" auf die deterministischen Treffer aus dem gemeinsamen Index. Cookieless, DSGVO-konforme KI, Made in Germany, ohne dass Sie eigene Schema-Modelle bauen, eigene Indexierungs-Pipelines pflegen oder die typ-übergreifende UX aus Standard-Komponenten zusammensetzen müssen.

Zu Ihrer kostenlosen Demo und erleben Sie live an Ihren eigenen Produkt- und Content-Daten, wie Volt Search® Produkte und FAQs in einer Anfrage findet, wie das type-aware Ranking Produkt- und Content-Treffer pro Such-Intent gewichtet, wie die WordPress-Anbindung Ihre vorhandenen Blog-Posts und Hilfe-Artikel sauber indiziert und wie die Hybrid LLM Search natürlich-sprachliche Kunden-Anfragen auf die richtigen Treffer routet. Ohne eigene Index-Pipelines, ohne Schema-Pflege pro Inhaltstyp, ohne lange Setup-Phase.