Warum B2B-Suche eigene Spielregeln hat

B2B-Einkäufer wissen meist, was sie wollen. In B2B-Implementierungen bei foobar Agency sehen wir regelmäßig, dass ein erheblicher Teil der Suchanfragen nicht aus generischen Produktbegriffen besteht, sondern aus SKUs, Bestellnummern, Norm-Bezeichnungen oder technischen Maßen. Eine Suche nach „M8x40 verzinkt“ ist kein Browser-Verhalten — das ist der direkte Zugriff auf einen bekannten Artikel im Sortiment.

Das hat Konsequenzen für das Ranking: Im B2C ist Exact-Match nur eine Komponente neben Personalisierung, Verkaufsdaten und Trends. Im B2B muss eine eindeutige SKU- oder Bestellnummer-Suche praktisch immer den exakten Artikel ganz oben liefern — bevor Synonyme, Empfehlungen oder Personalisierungsmodelle eingreifen. Suchplattformen, die ihr Ranking primär auf Click-Through-Verhalten optimieren, treffen hier auf ein Verhalten, das sie selten gut bedienen: Profis klicken, weil sie müssen — nicht, weil das Ranking sie überzeugt hat.

Dazu kommt das Re-Order-Verhalten. Ein erheblicher Teil der B2B-Aufträge sind Wiederholungskäufe. Suche im B2B ist deshalb oft kein Discovery-Tool, sondern ein schneller Zugriffspfad auf bekannte Artikel — und sollte sich entsprechend verhalten. Was Ihre Such-Logs zeigen — welche Bestellnummern nicht treffen, welche Synonyme fehlen, welche Wiederholungs-Suchen scheitern — ist eines der präzisesten Datenfundamente, die ein B2B-Shop hat. Wer es nicht auswertet, lässt Umsatzpotenzial im Index liegen.

Im B2C bedeutet Personalisierung: Vorlieben, Empfehlungen, kuratierte Auswahl. Im B2B bedeutet sie etwas grundlegend anderes — sie ist eine Frage von Berechtigungen, nicht von Geschmack. Welche Artikel ein Einkäufer überhaupt sehen darf, ergibt sich aus dem Kundenvertrag, der Account-Konfiguration, regionalen Freigaben und manchmal sogar der Rolle des Mitarbeiters innerhalb des Kundenunternehmens.

Plattformen wie commercetools, OroCommerce und Spryker bilden diese Logik über Customer-Groups, Business Units beziehungsweise Company-Hierarchien und kontraktgebundene Preis- und Kataloglisten ab. Für die Suche heißt das: Sie muss das individuelle Sortiment des angemeldeten Einkäufers indizieren — nicht das Gesamtsortiment des Shops. Ein Artikel, den ein bestimmter Kunde nicht bestellen darf, hat in seiner Trefferliste nichts verloren. Auch nicht als ausgegrauter, „auf Anfrage verfügbarer“ Treffer — das produziert Reklamationen, keine Aufträge.

Architektonisch gibt es dafür drei gängige Muster: Multi-Tenant-Indizes (ein Index pro Kunden-Gruppe), gefilterte Indizes (ein gemeinsamer Index mit Sichtbarkeits-Filter zur Suchzeit) und serverseitiges Re-Ranking nach der Suche. Welches Muster trägt, hängt davon ab, wie groß Ihr Sortiment, wie viele Kunden-Sortimente und wie häufig Vertragsänderungen sind. Die Frage entscheidet sich an Skalierung und Performance — und sollte vor der Plattform-Wahl beantwortet sein.

Im B2B sehen verschiedene Kunden für denselben Artikel verschiedene Preise — und sie sehen sie nicht erst auf der Produktdetailseite, sondern in der Trefferliste. Sortier-Funktionen, Filter und Vergleiche der Kunden hängen an diesem Preis. Wer in der Trefferliste den Listenpreis zeigt und erst beim Klick den Kontraktpreis nachlädt, sortiert seine Trefferliste über alle Suchanfragen hinweg falsch.

Es gibt zwei Architektur-Optionen. Erstens: Der Kontraktpreis wird zur Suchzeit aus dem ERP, der Pricing-Engine oder einem Caching-Layer gezogen und in die Trefferliste eingespielt — was Latenz und Last bedeutet. Zweitens: Kontraktpreise werden vorberechnet in den Suchindex geschrieben, kunden- oder kunden-gruppen-spezifisch — was Index-Größe und Update-Frequenz bedeutet. Beide Wege haben Berechtigung. Welcher trägt, hängt an der Anzahl der Kunden, der Volatilität der Preise und der Anforderung an Echtzeit-Konsistenz.

Was nicht trägt, ist die dritte Option: nur Listenpreise zeigen und den Kunden bitten, „den finalen Preis im Warenkorb“ zu prüfen. Das ist in Live-Demos der Punkt, an dem CIOs aufhören mitzulesen.

B2B-Suche endet nicht an der Shop-Domain. Über cXML — 1999 von Ariba eingeführt, seit der SAP-Übernahme 2012 SAP-eigen — und OCI, einen SAP-Standard, der sich als De-facto-Norm im E-Procurement etabliert hat, landen Einkäufer aus ihrem ERP-Beschaffungstool im Lieferanten-Katalog. SAP Ariba unterstützt beide Protokolle; Coupa und Microsoft Dynamics 365 Supply Chain setzen primär auf cXML. Bei der Level-2-Variante von cXML laufen Suche und Trefferdarstellung direkt im Ariba-UI — Treffer aus dem Lieferantenkatalog werden in der Beschaffungsoberfläche gerendert, ohne dass der Einkäufer die Ariba-Session verlässt. Eine B2B-Suche muss dafür API-fähig sein und in fremden UI-Kontexten brauchbare Ergebnisse liefern — inklusive der korrekten Kontraktpreise.

Konfigurator-getriebene Produkte sind die zweite Sonderform. Ein Sortiment, in dem Varianten erst durch Auswahl entstehen — Längen, Materialien, Beschichtungen, Toleranzen — kann nicht mit klassischem SKU-Indexing arbeiten. Suche muss hier Konfiguratoren entweder umgehen (Basis-SKU als Treffer, Konfiguration im PDP) oder die häufigsten Konfigurations-Varianten als virtuelle SKUs in den Index aufnehmen.

Drittens: Lagerstand und Lieferzeit. Der Sana-Commerce-B2B-Buyer-Report 2025 nennt fehlende Transparenz zu Bestand und Lieferzeiten als wichtigste Frustration der Einkäufer — 40 Prozent der Befragten geben das als Top-Problem an. Suche-Ergebnisse ohne aktuelle Bestandsdaten erzeugen Aufträge, die in der Auftragsbestätigung kippen — und beschädigen das Vertrauen, das im B2B länger braucht als ein Klick.