Warum die integrierte Solr-Suche der SAP Commerce Cloud oft zur Bremse wird – und wie es besser geht

Die Suche ist ein zentrales Element im digitalen Handel. Sie entscheidet darüber, ob Nutzer:innen finden, was sie suchen – oder den Shop frustriert verlassen. In der Realität sehen wir jedoch oft: Die standardmäßige Solr-Suche in SAP Commerce Cloud wird nicht zum Erfolgsfaktor, sondern zum Engpass.

Warum? Weil sie stark vorstrukturiert ist, sich nur schwer anpassen lässt und moderne Features meist fehlen. Was als solide Basis beginnt, entwickelt sich schnell zu einem schwer wartbaren Monolithen. Darüber hinaus fehlen häufig die Werkzeuge, um das Suchverhalten granular auszuwerten oder iterativ zu optimieren.

Solr ist als Open-Source-Suchtechnologie grundsätzlich sehr leistungsfähig – doch im SAP-Commerce-Kontext ist sie tief in das Framework eingebettet. In der Praxis führt das zu einer Reihe struktureller und funktionaler Herausforderungen, die sich in vielen Projekten wiederholen:

• Limitierte Konfigurierbarkeit: Anpassungen der Relevanzlogik oder Filterregeln sind nur mit erheblichem Entwicklungsaufwand möglich. Einfache Regelwerke, wie sie aus modernen Suchlösungen bekannt sind, fehlen. Die Synonymbehandlung ist nur rudimentär implementiert und nicht flexibel genug pflegbar.
• Eingeschränkte Boosting-Optionen: Out-of-the-box stehen nur einfache Boosting-Mechanismen zur Verfügung. Wer differenzierte Modelle wie lineares oder logarithmisches Boosting nutzen möchte, muss diese per Customization selbst implementieren.
• Enge Kopplung ans System: Die Suchlogik ist stark an das SAP-Backend gekoppelt. Commerce Updates und Vorgaben zum Solr-Versionswechsel, können zu Kompatibilitätsproblemen mit bestehenden Customizations oder Drittanbieter-Plugins führen.
• Unübersichtliche Pflege im SAP Backoffice: Die Sucheinstellungen sind auf mehrere Bereiche im Backoffice verteilt. Neben Grundeinstellungen existieren zusätzlich zwei Ebenen an Such-Profilen deren Einstellungen innerhalb einer vorgegebenen Hierarchie greifen. Das macht es schwer, die Auswirkungen einzelner Änderungen nachzuvollziehen – besonders für nicht-technische User.
• Komplexe Konfiguration: Es gibt zwar die Möglichkeit pro Kategorie individuelle Boostings und Facetten zu hinterlegen, in der Praxis kommt es jedoch häufig zu Konflikten zwischen neuen und bereits exisitierenden Konfigurationen. Änderungen, etwa an globalen Filter-Namen, greifen nicht konsistent in bereits existierenden Kategorie-Ausnahmen – was zu Intransparenz und hohem Pflegeaufwand führt.
• Mangelnde Transparenz und Vorschau: Die Adaptive Search Vorschau zeigt keine Details zu den Such-Treffern – z. B. in welchen Feldern Treffer zustande kommen oder wie die Gewichtung sich auf das Scoring auswirkt. Gleichzeitig ist die Vorschau bei großen Kategoriebäumen und umfangreichen Filterwerten nicht performant.
• Wartungsintensität
  Jede Erweiterung erhöht die Komplexität der Sucharchitektur. Gerade bei größeren Updates entstehen hohe Aufwände, da häufig auch die Customizations angepasst werden müssen.
• Abhängigkeit von Entwicklern
  Fachabteilungen haben kaum Möglichkeiten, eigenständig Einfluss auf die Suche und die Suchergebnisse zu nehmen. Anpassungen benötigen technisches Know-how – schnelle Reaktionen auf Markt- oder Kampagnenanforderungen sind dadurch kaum möglich.

Die Lösung liegt in der konsequenten Trennung von Shop- und Suchlogik. Denn nur wenn die Suche als eigenständige Komponente gedacht und betrieben wird, kann sie ihr volles Potenzial entfalten. Eine spezialisierte, externe Suche – losgelöst vom Core-System – bringt klare technologische und geschäftliche Vorteile mit sich:

• Mehr Flexibilität: Ob neue Filterlogiken, individuelle Gewichtungsregeln oder spezifische Facettenstrukturen – mit einer dedizierten Suche lassen sich Anforderungen wesentlich schneller und granularer umsetzen. Dabei ist es egal, ob für einzelne Kampagnen, Sortimente oder Zielgruppen.
• Unabhängige Entwicklungszyklen: Änderungen an der Suchfunktionalität müssen nicht mehr mit Core-Releases oder anderen Systementwicklungen abgestimmt werden. Die Suche kann eigenständig weiterentwickelt, getestet und deployed werden – agil, iterativ und ohne Risiko für den Shopbetrieb.
• Moderne Features out-of-the-box: Während Standardlösungen oft an ihre Grenzen stoßen, ermöglichen spezialisierte Suchtechnologien Funktionen wie KI-gestütztes Ranking, semantische Analyse, fachlich korrekte Synonymverarbeitung oder dynamisches Re-Ranking – sofort und ohne langwierige Eigenentwicklungen.
• Bessere Nutzererfahrung: Eine optimierte Suche sorgt für präzisere Ergebnisse, klare Strukturen und eine deutlich intuitivere Bedienung. Nutzer:innen werden schneller fündig, interagieren häufiger mit den Inhalten – und brechen seltener ab. Das steigert nicht nur die Zufriedenheit, sondern auch die Conversion.
• Skalierbarkeit & Performance: Moderne Sucharchitekturen sind darauf ausgelegt, große Kataloge, vielfältige Attribute und hohe Zugriffszahlen zuverlässig zu bewältigen. Durch intelligente Caching-Mechanismen, horizontale Skalierung und Monitoring lassen sich Suchzeiten drastisch reduzieren – selbst bei komplexen Abfragen.

Ein zusätzlicher Mehrwert: Die Einführung einer dedizierten Suche eröffnet die Möglichkeit, das gesamte Sucherlebnis strategisch zu überarbeiten. Dabei geht es nicht nur um Technik, sondern auch um Relevanzlogiken, UX-Konzepte und redaktionelle Steuerung. Ob Zero-Result-Handling, intelligente Vorschläge oder kontextabhängige Sortierungen – wer die Suche als Conversion-Treiber versteht, denkt weiter als bis zur Ergebnisliste.

Unsere Antwort auf die Herausforderungen der integrierten Solr-Suche: Holmes, der modular einsetzbare Search-Accelerator für E-Commerce Plattformen. Holmes entkoppelt die Suche vollständig vom Shop-System und ermöglicht so maximale Flexibilität bei der Weiterentwicklung und Steuerung der Sucherfahrung. Als technische Basis dienen bewährte Open-Source-Suchtechnologien wie Solr, Elasticsearch oder OpenSearch – je nach Anforderung und bestehender Systemlandschaft. Holmes ist vollständig Headless und API-first gedacht und lässt sich damit optimal in moderne Commerce-Architekturen wie SAP Commerce Cloud integrieren.

Darum Holmes:

• Nahtlose Integration: Über offene Schnittstellen an SAP Commerce, Middleware oder CMS andockbar – auf Wunsch auch parallel zur bestehenden Suche.
• Schneller Start: Vorgefertigte Konnektoren und Setups ermöglichen einen zügigen Go-Live – mit klar definierten Meilensteinen.
• Optimiert für UX und Conversion: Mit Suggest, Autocomplete, Boosting, No-Result-Handling, Fehlerkorrektur, Synonymlogik und mehr.
• Für Fachbereiche nutzbar: Inhalte, Regeln und Gewichtungen können ohne Entwickler gesteuert werden – direkt über ein intuitives Backend.
• Zukunftssicher: Headless, API-first und kontinuierlich erweiterbar – ohne Core-Hacks, Vendor-Lock-ins oder technische Altlasten.

Holmes ist nicht nur ein technisches Framework, sondern ein methodischer Beschleuniger für deine Suchstrategie. In Kombination mit unserem Experience Layer ermöglicht Holmes eine zielgerichtete Steuerung der Suchergebnisse – bis auf Kategorie-, Kampagnen- oder User-Segment-Ebene.

Mit Holmes wird die Suche von einer technischen Hürde zu einem leistungsfähigen Werkzeug, das Nutzer:innen schneller ans Ziel bringt, interne Teams entlastet und Conversion-Potenziale messbar ausschöpft.

SAP Commerce Cloud ist ein mächtiges System – aber bei der Suche lohnt es sich, eigene Wege zu gehen. Die integrierte Solr-Suche ist solide, aber in der Praxis oft zu starr. Wer eine performante, skalierbare und individuell steuerbare Suche möchte, kommt um eine dedizierte Lösung nicht herum.

Unser Search-Accelerator bietet genau das – pragmatisch, performant und mit einem schnellen Start in die individuelle Suchoptimierung. Holmes ist der passende Einstiegspunkt für Unternehmen, die Sucherlebnisse nicht dem Zufall überlassen wollen.