Shopware 6 Suche konfigurieren: native Einstellungen, Advanced Search 2.0 und die besten Plugins im Vergleich

von | Aug. 10, 2026 | Alle | 0 Kommentare

Wer Shopware 6 Suche konfigurieren möchte, landet meist zuerst im Admin unter Einstellungen → Allgemein → Suche – und ist überrascht, wie viele Stellschrauben dort schon ohne ein einziges Plugin zur Verfügung stehen. Gleichzeitig kursieren im Netz veraltete Befehle und vermischte Begriffe (native Suche vs. Advanced Search vs. Elasticsearch/OpenSearch), die bei der Konfiguration eher verwirren als helfen. Wer aus einer älteren Shopware-Welt kommt oder Tutorials aus 2020/2021 gelesen hat, stolpert zusätzlich über Befehle und Einstellungen, die es in dieser Form nicht mehr gibt – ein Grund mehr, hier ausschließlich mit aktuell verifizierten Quellen zu arbeiten. Dieser Artikel räumt auf: Wir zeigen, welche Regler die Bordmittel wirklich bieten, wie der Suchindex per CLI korrekt neu aufgebaut wird, welche Fehlerbilder in der Community dokumentiert sind, wo Advanced Search 2.0 anfängt, welche Store-Plugins mit echten Preisen infrage kommen – und wo eine eigene Ergänzung wie FlexSearch sinnvoll andocken kann.

Shopware 6 Suche konfigurieren: native Sucheinstellungen im Admin (Lösung A)

Die Grundkonfiguration der Storefront-Suche liegt in der Administration unter Einstellungen → Allgemein → Suche. Technisch stehen dahinter zwei Entitäten: product_search_config (globale Logik wie UND/ODER-Verknüpfung, Mindest-Suchbegriffslänge und ausgeschlossene Begriffe) und product_search_config_field (pro Feld: durchsuchbar ja/nein, Tokenisierung, Rangpunkte).

UND- vs. ODER-Suche

Der erste Schalter entscheidet, ob bei mehreren Suchbegriffen alle Wörter in einem Treffer vorkommen müssen (UND) oder ob ein Treffer schon reicht (ODER). UND liefert präzisere, aber weniger Ergebnisse; ODER liefert mehr Treffer, dafür oft mit geringerer Relevanz. Für die meisten Shops mit klar strukturiertem Katalog ist UND die bessere Grundeinstellung, weil Kunden meist mehrere Begriffe kombinieren, um einzugrenzen (z. B. „rote Sneaker Damen“).

Admin-Einstellung UND/ODER-Suche im Bereich Einstellungen > Allgemein > Suche“ loading=“lazy“ style=“max-width:100%;height:auto;“ /></p>
<h3>Minimale Suchbegriffslänge</h3>
<p>Dieser Wert lässt sich zwischen 2 und 255 Zeichen konfigurieren und bestimmt, ab welcher Zeichenlänge ein eingegebenes Wort überhaupt in die Suche einfließt. Zu niedrig eingestellt, produziert das System bei kurzen Wörtern (Artikelnummern, Abkürzungen) viel Rauschen; zu hoch eingestellt, blendet es kurze, aber relevante Begriffe komplett aus.</p>
<h3>Durchsuchbare Inhalte und Rangpunkte</h3>
<p>Hier legt man fest, welche Produktfelder (Name, Beschreibung, Herstellernummer, benutzerdefinierte Felder etc.) überhaupt in den Suchindex einfließen, und vergibt für jedes Feld einen Rangpunkt-Wert. Ein Treffer im Produktnamen sollte in aller Regel höher gewichtet sein als ein Treffer irgendwo im Fließtext der Beschreibung. Zusätzlich gibt es die Option „Suchbegriffe trennen“ (Tokenizing), die zusammengesetzte Begriffe in Einzelteile zerlegt. Ein häufiger Praxis-Fehler ist es, nahezu alle verfügbaren Felder mit maximalen Rangpunkten zu versehen – das Ergebnis ist dann keine echte Priorisierung mehr, sondern eine gleichverteilte Unschärfe, die die Trefferliste eher verwässert als schärft.</p>
<ul>
<li>Produktname und Hersteller meist mit den höchsten Rangpunkten versehen</li>
<li>Beschreibungstexte und Freitextfelder niedriger gewichten, damit sie Treffer nicht verwässern</li>
</ul>
<p>Ein Blick nach vorn: Seit Shopware 6.7.12.0 (Release 07.07.2026) gibt es auf Feldebene zusätzlich ein internes <code>use_exact_subfield</code>-Flag (Spalte in <code>product_search_config_field</code>), das für ausgewählte Felder wie Name, Artikelnummer, EAN und Herstellernummer exakte, nicht sprachanalysierte Tokentreffer erzwingt – das verhindert beispielsweise, dass eine Suche nach „5,5″ fälschlich Artikel mit „55″ in der Artikelnummer trifft. Ein eigenes Admin-UI-Feld gibt es dafür nicht, und in 6.7.9.0, dem in diesem Artikel referenzierten Stand, existiert das Flag noch nicht.</p>
<p><img decoding=
Hinzufügen eines benutzerdefinierten Zusatzfelds zur durchsuchbaren Feldliste

Ausgeschlossene Suchbegriffe

Über eine einfache Liste lassen sich Füllwörter oder Begriffe definieren, die bei der Suche ignoriert werden sollen – etwa „und“, „für“ oder shop-spezifische Stoppwörter, die sonst jede Anfrage verwässern.

Verwaltung der ausgeschlossenen Suchbegriffe

Such-Index neu erstellen

Nach jeder Änderung an den Sucheinstellungen bietet die Administration einen Button, um den Suchindex neu aufzubauen. Die konkrete interne Umsetzung dieses Buttons (direkter Aufruf vs. Queue-Nachricht) ist öffentlich nicht im Detail dokumentiert – belegt ist nur, dass serverseitig dieselbe Indexierungslogik greift wie beim CLI-Befehl aus dem nächsten Abschnitt.

In der Praxis hat es sich bewährt, mehrere Einstellungsänderungen zu bündeln und den Index erst danach einmal komplett neu aufzubauen, statt nach jeder einzelnen Anpassung zu reindexieren – gerade bei großen Katalogen kann das spürbar Zeit sparen. Wer unsicher ist, ob eine Änderung tatsächlich gegriffen hat, sollte zusätzlich zum Admin-Button den CLI-Befehl aus dem nächsten Abschnitt in einer SSH-Session ausführen und die Ausgabe beobachten, statt sich allein auf die Fortschrittsanzeige im Backend zu verlassen.

Button

Zurück zur Übersicht

Shopware 6 Suche konfigurieren: Suchindex per CLI korrekt neu aufbauen

Ein häufiger Fehler in älteren Anleitungen ist ein pauschaler, angeblich einheitlicher Reindex-Befehl. Tatsächlich gibt es in Shopware 6 zwei getrennte Befehlsfamilien, die nicht verwechselt werden sollten:

  • Regulärer DAL/MySQL-Reindex: bin/console dal:refresh:index --use-queue baut den generischen Datenbank-Suchindex neu auf. Mit --only=product.search-keyword oder --only=product.indexer lässt sich der Lauf auf einzelne Indexer eingrenzen, --skip schließt Indexer aus, --no-progress unterdrückt die Fortschrittsanzeige.
  • Elasticsearch/OpenSearch-spezifisch: es:index, es:status, es:reset, es:mapping:update und es:test:analyzer steuern ausschließlich den Such-Cluster. Daneben existieren laut Commands-Referenz die getrennten Befehle es:admin:index und es:admin:reset für die separate Admin-eigene Suche sowie es:create:alias und es:index:cleanup für Alias-Verwaltung und das Aufräumen veralteter Indizes.

Wer OpenSearch oder Elasticsearch produktiv betreibt, aktiviert das über die Umgebungsvariablen OPENSEARCH_URL, SHOPWARE_ES_ENABLED, SHOPWARE_ES_INDEXING_ENABLED und SHOPWARE_ES_INDEX_PREFIX; die Shard-Konfiguration läuft laut Dokumentation seit Version 6.4.12.0 über config/packages/elasticsearch.yml. Für einen reinen MySQL-Betrieb ohne Suchcluster reicht in der Praxis der dal:refresh:index-Befehl vollständig aus.

Zurück zur Übersicht

Shopware 6 Suche konfigurieren: typische Fehlerbilder aus der Praxis

Bevor man an den Reglern dreht, lohnt sich ein Blick in Community-Threads und das offizielle Issue-Tracking – dort sind einige Muster wiederkehrend dokumentiert:

  • UND-Suche verhält sich wie ODER-Suche: In einem Forumsthread vom 01.07.2024 (Shopware 6.6.3.1) wurde vermutet, dass die Kombination aus deaktivierten Standardfeldern und benutzerdefinierten Textfeldern mit Leerzeichen (z. B. „A4 Quattro Avant“) das Verhalten verfälscht. Eine offizielle Bestätigung oder Ticket-Verknüpfung dazu ist nicht auffindbar – im Zweifel die Feldkonfiguration einzeln testen.
  • Mehrwort-Suche liefert nach Index-Rebuild keine Treffer mehr: Threads vom 19.06. und 13.09.2024 beschreiben, dass nach Anpassung der Rangpunkte und der „Suchbegriffe trennen“-Option selbst mehrfacher Reindex sowie das Leeren der Tabellen search_keywords und keyword_dictionary das Problem nicht lösten. Der Thread blieb ohne offizielle Auflösung.
  • Lange Indexierungszeiten mit „Lock wait timeout exceeded“: GitHub-Issue #7398 (Shopware 6.6.10.1, PHP 8.3.17) beschreibt 10 bis 60 Minuten Laufzeit in der SearchKeywordUpdater-Klasse, besonders bei aktiver Advanced Search und großen Produktmengen. Der Bug war als High-Priority eingestuft und wurde inzwischen geschlossen.
  • Langsame Sortierung „Name A–Z/Z–A“ bei Millionen Produkten mit OpenSearch: Issue #11130 (Juli 2025) wurde über Pull-Request #11342 behoben, eine konkrete Versionsnummer für den Fix ist öffentlich nicht dokumentiert.
  • Admin-Keyword-Feld zeigt nicht alle Keywords nach dem Speichern: Issue #13081 (Shopware 6.7.3.0, Oktober 2025) beschreibt einen defekten „+2″-Button als Regression gegenüber 6.6, behoben über Pull-Request #13698.

Ein oft zitierter Hinweis aus 2021, wonach die Backend-Einstellung zur Mindest-Suchbegriffslänge wegen eines hartkodierten Werts (searchWidgetMinChars: 3) im Storefront-JS wirkungslos blieb, lässt sich für 6.7.9.0 nicht mehr verifizieren – hier sollte man im eigenen Shop einfach selbst mit unterschiedlichen Längen testen, statt sich auf den alten Bericht zu verlassen.

Zurück zur Übersicht

Shopware 6 Suche konfigurieren: Advanced Search 2.0 und OpenSearch im Überblick

Sobald Boostings, Synonyme oder Weiterleitungs-Actions bei bestimmten Suchbegriffen gewünscht sind, verlässt man die kostenlosen Bordmittel: Diese Funktionen sind laut Dokumentation Teil des kommerziellen Advanced Search 2.0, verfügbar ab dem Evolve-Plan und pro Sales Channel unter Einstellungen → Allgemein → Suche → „Enable Advanced Search“ zuschaltbar. Wichtig für die technische Planung: Laut Dokumentation basiert Advanced Search 2.0 seit Version 6.5.6.0 ausschließlich auf OpenSearch – Elasticsearch wird dafür nicht mehr unterstützt, auch wenn es als reine Infrastruktur-Komponente für andere Zwecke weiterhin existiert. Seit dem Changelog zu Release 6.7.0.0 (13.03.2025) ist zudem die Präfixsuche für Synonyme bewusst deaktiviert, um irrelevante Treffer zu vermeiden.

  • Boostings: dynamische Produktgruppen bzw. Regeln, die bestimmte Produkte in der Trefferliste nach oben ziehen
  • Actions: Weiterleitungen, wenn Kunden nach bestimmten Begriffen suchen
  • Synonyme: Laut Dokumentation zwei Regeltypen – Äquivalenz (z. B. „wifi“, „wlan“ und „wireless network“ als gleichwertig behandelt) und explizite Zuordnung (z. B. „iPhone“ wird zusätzlich unter „Smartphone“ gefunden)
  • Optionaler AI-Copilot mit kontextbasierter Suche und Bildsuche, der laut Dokumentation zusätzlich mindestens den Rise-Plan voraussetzt

Aktivierung von Advanced Search pro Sales Channel
Boosting-Liste mit angelegten Boosting-Regeln
Auswahl-Dialog beim Anlegen eines neuen Boostings

Echtzeitsuche-Vorschau während der Konfiguration
Suchergebnisse-Vorschau mit angewendeten Boostings

Konkrete Preise oder Konditionen des Evolve-Plans lassen sich an dieser Stelle nicht seriös nennen, da wir keine eigene Preisprüfung dafür vorliegen haben. Wer den technischen Unterbau (OpenSearch/Elasticsearch als reine Infrastruktur, unabhängig vom kommerziellen Advanced-Search-Produkt) im Detail einrichten möchte, findet dazu bereits einen ausführlichen eigenen Artikel: Bessere Shopware Suche mit OpenSearch (Elasticsearch). Wir wiederholen den Setup-Teil hier bewusst nicht, sondern konzentrieren uns in diesem Artikel auf die native Konfiguration und die Plugin-Alternativen.

Zurück zur Übersicht

Shopware 6 Suche konfigurieren: die besten Store-Plugins im Vergleich (Lösung B)

Wer keine eigene OpenSearch-Infrastruktur betreiben oder das Advanced-Search-Produkt lizenzieren möchte, aber trotzdem eine leistungsfähigere Suche braucht, findet im Shopware Store fertige Plugins. Direkt auf den jeweiligen Store-Seiten geprüft (Stand 03.08.2026) sind folgende Angebote mit belastbaren Preisen hinterlegt:

Plugin Anbieter Preis SW-Kompatibilität
Search Pro (mit Elasticsearch-/OpenSearch-Option) ACRIS E-Commerce GmbH 69,00 €/Monat oder 699,00 €/Jahr (≈ 58,25 €/Monat); 1 Monat kostenlos testbar 6.1.0–6.7.12.2
Intelligent Search with Elastic Search signundsinn 69,00 €/Monat oder 699,00 €/Jahr (≈ 58,25 €/Monat); 1 Monat kostenlos testbar 6.2.0–6.7.12.2
Intelligente Suche (swagfuzzy) shopware AG 30,00 €/Monat bzw. 300,00 €/Jahr 4.0.0–5.7.20 (nur Shopware 5)

Bei der dritten Position lohnt ein genauer Blick: „Intelligente Suche“ (swagfuzzy) von shopware AG selbst ist ausschließlich für Shopware 5 kompatibel. Der Hersteller weist selbst darauf hin, dass die Fuzzy-Funktionalität in Shopware 6 bereits nativ vorhanden ist – für 6.7.9.0-Shops ist dieses Plugin also keine Option, sondern eher ein historischer Hinweis darauf, wie sich die Suche zwischen den Plattform-Generationen entwickelt hat.

  • ACRIS Search Pro und die signundsinn-Lösung liegen preislich praktisch gleichauf und bieten beide eine Elasticsearch-/OpenSearch-Anbindung als Kernfeature
  • Beide Anbieter räumen einen kostenlosen Testmonat ein, bevor die monatliche oder jährliche Abrechnung greift

Für einige weitere im Markt kursierende Namen – etwa Findologic, „Search Booster“ von digitvision, Boxalino, Klevu, Bloomreach oder Loop54 – ließ sich bei der Recherche keine verifizierbare Store-Seite mit belastbarem Preis finden (teils 404-Fehler, teils widersprüchliche Snippets). Diese Anbieter lassen wir hier bewusst ohne Preisangabe, statt Zahlen zu raten; wer sie in Betracht zieht, sollte die aktuelle Preisliste direkt beim Anbieter anfragen.

Zurück zur Übersicht

Shopware 6 Suche konfigurieren: FlexSearch als Ergänzung im DreamTheme (Lösung C)

Kurzer Disclosure-Hinweis vorweg: DreamTheme ist unser eigenes Theme, dieser Abschnitt ist entsprechend werblich zu lesen. Wir erwähnen es nur, weil es eine sachlich begründbare Ergänzung zur nativen Suche ist – nicht als Ersatz dafür.

DreamTheme bringt eine clientseitige FlexSearch-Instant-Search mit Tippfehlertoleranz mit, die auf die im Admin konfigurierten Sucheinstellungen aufsetzt statt sie zu ersetzen. Praktisch heißt das: Die in Lösung A gepflegten durchsuchbaren Felder und Rangpunkte bleiben die Grundlage, FlexSearch liefert zusätzlich eine sehr schnelle Live-Vorschau während der Eingabe direkt im Frontend, inklusive einer gewissen Toleranz gegenüber Vertippern. Wer eine echte serverseitige Relevanz-Suche mit Boostings und Synonymen sucht, landet trotzdem bei Advanced Search 2.0 oder einem der in Lösung B genannten Plugins – FlexSearch ist dafür kein Ersatz, sondern eine Komfort-Ebene obendrauf.

Zurück zur Übersicht

Kurz-Checkliste: So gehst du vor

  1. Native Sucheinstellungen im Admin durchgehen: UND/ODER-Logik, Mindest-Suchbegriffslänge, durchsuchbare Felder und Rangpunkte bewusst festlegen, statt die Standardwerte unangetastet zu lassen.
  2. Änderungen bündeln und danach den Suchindex einmal komplett neu aufbauen, statt nach jeder Kleinigkeit zu reindexieren.
  3. Bei reinem MySQL-Betrieb ohne Suchcluster reicht bin/console dal:refresh:index --use-queue vollständig aus.
  4. Wer OpenSearch produktiv nutzt, sollte die einschlägigen Umgebungsvariablen und optional die Shard-Konfiguration in config/packages/elasticsearch.yml prüfen.
  5. Boostings, Synonyme und Actions sind kein Bordmittel-Feature, sondern Teil des kommerziellen Advanced-Search-Produkts ab dem Evolve-Plan.
  6. Bei kuriosen Suchergebnissen zuerst die Feldkonfiguration einzeln testen, bevor man einen Bug vermutet – die Community-Threads zeigen, dass viele Fälle nie offiziell aufgeklärt wurden.

Shopware 6 Suche konfigurieren: häufige Fragen (FAQ)

Wo finde ich die Sucheinstellungen in Shopware 6?

Unter Administration → Einstellungen → Allgemein → Suche. Dort lassen sich UND/ODER-Logik, Mindest-Suchbegriffslänge, durchsuchbare Felder mit Rangpunkten und ausgeschlossene Begriffe pflegen.

Welcher CLI-Befehl baut den Suchindex neu auf?

Für den regulären MySQL/DAL-Index ist das bin/console dal:refresh:index --use-queue. Für einen aktiven OpenSearch/Elasticsearch-Cluster gelten die separaten es:*-Befehle wie es:index und es:status.

Brauche ich Advanced Search 2.0, um Synonyme zu pflegen?

Ja – laut Dokumentation sind Synonyme, Boostings und Actions als eigenständige Admin-Funktionen Teil des kommerziellen Advanced-Search-Produkts ab dem Evolve-Plan, nicht der kostenlosen nativen Suche.

Läuft Advanced Search 2.0 mit Elasticsearch oder OpenSearch?

Laut Dokumentation seit Version 6.5.6.0 ausschließlich mit OpenSearch. Elasticsearch bleibt als reine Infrastruktur-Option bestehen, wird von Advanced Search 2.0 aber nicht mehr unterstützt.

Was tun, wenn die UND-Suche keine oder falsche Ergebnisse liefert?

In der Community sind dazu mehrere Threads dokumentiert, aber keine offizielle Ursachenbestätigung. Sinnvoll ist es, die Feldkonfiguration und Rangpunkte einzeln zu testen und nach jeder Änderung den Suchindex neu aufzubauen, bevor man von einem Bug statt einer Fehlkonfiguration ausgeht.

Zurück zur Übersicht

Quellen und weiterführende Links