Shopsuche überwachen: Wenn die Suche nichts mehr findet

Warum eine leere Trefferliste lange unbemerkt bleibt

Eine Seite mit null Treffern ist aus Sicht des Servers ein Erfolg. Sie wird vollständig ausgeliefert, trägt Kopfbereich, Navigation und Fußzeile und antwortet in der Regel mit Status 200. Eine Uptime-Prüfung fragt genau das ab: Sie prüft die HTTP-Antwort der Startseite (XICTRAQ®-Dokumentation). Dass die Suche dahinter keine Produkte mehr findet, liegt außerhalb dessen, was ein solcher Check sehen kann. Im Team fällt es ebenfalls spät auf, weil Produkte über die Verwaltung gepflegt werden, und Kundschaft, die nichts findet, wechselt meist wortlos den Shop.

Wie viel daran hängt, zeigen die Zahlen zum Onlinehandel. In der repräsentativen Befragung des Digitalverbands haben 96 Prozent der Befragten ab 16 Jahren in den letzten zwölf Monaten online eingekauft (Bitkom). Auf Händlerseite betreiben 97 Prozent der befragten Handelsunternehmen mit mindestens zehn Beschäftigten einen eigenen Webshop (Bitkom). Die Suche dieses Shops ist für viele Besucher der kürzeste Weg zum Produkt, gerade bei großen Sortimenten.

Rund um die Aktionstage verschärft sich das. Von den Shoppern zu Black Friday und Cyber Week 2025 wollten 69 Prozent die Angebote im Internet wahrnehmen (Bitkom), das geplante Budget lag im Schnitt bei 312 Euro (Bitkom). Nach der Einteilung des Studienberichts entfallen 48 Prozent auf eher geplante Käufe (Bitkom). Wer gezielt kauft, weiß meist schon, was er sucht, und tippt es ein. Black Friday fällt 2026 auf den 27. November; bis dahin bleiben ab heute knapp vier Wochen.

Selbst eine gut gemachte Null-Treffer-Seite hilft dann wenig. Sie ist für einzelne Begriffe gedacht, zu denen der Katalog keine Produkte enthält, und kann dann Schreibweisen korrigieren, Kategorien anbieten oder verwandte Begriffe vorschlagen. Fällt die Suche ganz aus, endet jede Anfrage auf dieser Seite, auch die nach dem Bestseller.

Wie der Suchindex nach Import, Update oder Indexlauf kippt

Die Suche eines Shops liest in der Regel nicht direkt aus der Produkttabelle, sondern aus einem Index, der aus den Produktdaten gebaut wird. Shopware 6 führt dafür unter anderem einen eigenen Teilindex, der die Suchbegriffe aller Produkte festhält (Shopware-Dokumentation). Größere Shops können die Suche zusätzlich auf einen Suchserver wie OpenSearch oder Elasticsearch auslagern. Laufen Daten und Index auseinander, zeigt die Suche einen alten Stand, einen Teil der Produkte oder gar nichts.

Typische Auslöser hängen an einer Änderung, die kurz vorher lief:

• Import ohne Indexlauf: Ein Import schreibt Produkte, aber der Index wird nicht oder nur teilweise nachgezogen, etwa weil die Indexierung für den Import abgeschaltet war.
• Stehende Warteschlange: Läuft die Indexierung über die Message Queue, kann sie nach Angabe von Shopware mehrere Stunden dauern (Shopware-Dokumentation). Arbeitet kein Worker die Warteschlange ab, bleibt der Index auf dem alten Stand.
• Suchserver nicht erreichbar oder Index leer: Der Suchdienst ist nach einem Update nicht wieder gestartet, oder ein Neuaufbau brach ab, nachdem der Alias schon auf den neuen, noch leeren Index zeigte.
• Auffrischen ausgesetzt: Für Massenimporte lässt sich das Auffrischen des Index aussetzen, um schneller zu schreiben. Bricht der Import ab, bevor der alte Wert zurückgesetzt ist, werden neue und geänderte Produkte nicht mehr suchbar.
• Theme- oder Plugin-Update: Das Template der Trefferliste ändert sich, ein Skript der Sofortsuche wirft einen Fehler, oder das Suchformular sendet den Begriff unter einem anderen Parameter.
• Sichtbarkeit und Verkaufskanal: Importierte Produkte sind vorhanden, aber keinem Verkaufskanal zugeordnet oder nicht sichtbar geschaltet. Die Suche arbeitet korrekt und findet trotzdem nichts.

Wie schnell neue Daten im Suchserver ankommen, regelt das Auffrisch-Intervall. Standardmäßig frischt OpenSearch einen Index jede Sekunde auf (OpenSearch-Dokumentation). Der Wert -1 schaltet das Auffrischen ab (OpenSearch-Dokumentation), und für reine Schreibphasen nennt die Dokumentation genau das als Möglichkeit, die Indexierung zu beschleunigen (OpenSearch-Dokumentation). Was beim Import Zeit spart, wird zum stillen Fehler, wenn danach niemand den Normalwert setzt.

Nicht jeder Ausfall endet in einer leeren Liste. In Shopware legt eine Umgebungsvariable fest, was bei einem Fehler des Suchservers passiert: Mit dem Wert 1, der Vorgabe, wird die Ausnahme geworfen (Shopware-Dokumentation), und die Suchseite zeigt einen Fehler. Mit dem Wert 0 wird der Fehler nur protokolliert, und die Suche weicht auf die Datenbank aus (Shopware-Dokumentation). Der Shop antwortet weiter, mit anderer Trefferlogik und womöglich anderer Antwortzeit; diesen Fall zeigen eher die Schrittzeiten als ein roter Status.

Was Uptime-, API- und Browser-Check jeweils sehen

Drei Prüfarten kommen für die Suche in Frage, und sie decken unterschiedliche Schichten ab. Die Uptime-Überwachung prüft die Erreichbarkeit. API-Monitoring prüft einzelne JSON-Endpunkte mit Zusicherungen (XICTRAQ®-Dokumentation). Der Browser-Check steuert einen echten Chromium-Browser durch einen mehrstufigen Ablauf (XICTRAQ®-Dokumentation) und sieht damit, was die Kundschaft sieht.

Die Tabelle zeigt, warum der Browser-Check die Hauptrolle spielt und der API-Check ergänzt. Die Grundlagen synthetischer Abläufe fasst der Beitrag Browser-Monitoring: Wenn Uptime grün ist, der Checkout aber kaputt zusammen.

Die Suche als Browser-Check einrichten

Im Browser-Monitoring von XICTRAQ® besteht ein Szenario aus Schritten wie Seite öffnen, Feld ausfüllen, klicken, auf ein Element warten und Text oder Adresse prüfen. Pro Szenario sind bis zu 40 Schritte möglich, das Intervall liegt zwischen 5 Minuten und 24 Stunden (XICTRAQ®-Dokumentation). Für die Suche genügen sieben:

1. Startseite öffnen (goto): Schlägt schon das fehl, meldet der Check einen Fehlerstatus statt einer leeren Suche.
2. Begriff eingeben (fill) in das Suchfeld der Kopfzeile.
3. Suche absenden (click) über den Button des Suchformulars, so wie es die Kundschaft tut.
4. Auf die Trefferliste warten (wait_for) mit dem Selektor der ersten Produktkarte. Bei null Treffern erscheint sie nicht, und der Schritt läuft in sein Timeout.
5. Adresse prüfen (assert_url): Die Ergebnisseite trägt den Begriff im Parameter. Fehlt er, hat das Formular etwas anderes gesendet.
6. Treffer prüfen (assert_text) am Produktnamen der ersten Karte.
7. Screenshot als Beleg für den grünen Lauf.

{
  "name": "Shopsuche: Winterjacke liefert Treffer",
  "viewport": {
    "width": 1280,
    "height": 800
  },
  "timeout_ms": 15000,
  "step_retry": 1,
  "steps": [
    {
      "type": "goto",
      "url": "https://shop.example.invalid/"
    },
    {
      "type": "fill",
      "selector": "header input[name=search]",
      "value": "Winterjacke"
    },
    {
      "type": "click",
      "selector": "header form.search-form button[type=submit]"
    },
    {
      "type": "wait_for",
      "selector": ".search-results .product-box",
      "timeout_ms": 10000
    },
    {
      "type": "assert_url",
      "contains": "search=Winterjacke"
    },
    {
      "type": "assert_text",
      "selector": ".search-results .product-box .product-name",
      "contains": "Winterjacke"
    },
    {
      "type": "screenshot"
    }
  ]
}

Die Selektoren stammen aus dem eigenen Theme und lassen sich in den Entwicklerwerkzeugen des Browsers ablesen. Drei Details entscheiden, ob der Check zuverlässig misst. Erstens wartet wait_for, bis der Selektor im DOM sichtbar ist, mit einstellbarem Timeout (XICTRAQ®-Dokumentation); eine leere Trefferliste führt damit zu einem klaren Fehlschlag statt zu einem grünen Lauf. Zweitens unterscheidet assert_text beim Enthaltensein Groß- und Kleinschreibung (XICTRAQ®-Dokumentation): Der erwartete Text gehört so in den Check, wie er im Produktnamen steht. Drittens prüft der Schritt den ersten passenden Treffer. Steht das gesuchte Produkt nicht zuverlässig auf Platz eins, eignet sich als Ziel eher die Trefferliste als Ganzes.

Für die Trefferliste ist ein eigenes Timeout von etwa zehn Sekunden sinnvoll: Eine Suche, die länger braucht, ist für die Kundschaft kaum besser als eine leere. Technisch wäre mehr möglich, denn ein Schritt darf bis zu 60 Sekunden dauern, und der ganze Lauf wird nach 90 Sekunden abgebrochen (XICTRAQ®-Dokumentation). Den Wiederholungszähler, der sich pro Schritt von 0 bis 3 setzen lässt (XICTRAQ®-Dokumentation), hält man beim Warten auf die Trefferliste besser niedrig: Jeder zusätzliche Versuch verlängert den Lauf und kann eine Suche verdecken, die erst beim zweiten Anlauf antwortet. Wer Abläufe lieber aufzeichnet als schreibt, findet den Weg im Beitrag Browser-Flows aufzeichnen und automatisch überwachen; die vollständige Liste der Schritt-Typen führt die Dokumentation zum Browser-Monitoring.

Als zweiter Monitor lohnt der direkte Aufruf der Ergebnisadresse ohne Formular: Fällt nur der Lauf über das Formular aus, liegt der Fehler im Suchfeld, fallen beide aus, im Index oder Suchserver.

Den Suchbegriff so wählen, dass der Check etwas beweist

Ein Such-Check ist nur so aussagekräftig wie sein Begriff. Er muss Treffer liefern, solange der Shop gesund ist, und darf nicht von Saison, Lagerbestand oder einer Aktion abhängen. Bewährt haben sich mehrere kleine Monitore statt eines großen, weil der Alarm dann schon im Namen sagt, was nicht mehr geht:

• Dauerläufer aus dem Kernsortiment: ein Produkt, das seit Monaten im Katalog steht und bleiben wird, mit einem Namen, den Kundinnen und Kunden tatsächlich eintippen.
• Artikelnummer: prüft die exakte Suche. Manche Suchkonfigurationen führen Nummern in einem eigenen Feld des Index, das bei einer Umstellung leicht vergessen wird.
• Begriff mit Umlaut oder aus zwei Wörtern: „Wärmflasche“ oder „Jacke Damen“ prüft Zeichenbehandlung und Wortzerlegung im Index.
• Service-Begriff: „Rücksendung“ oder „Versandkosten“. Besucher suchen erfahrungsgemäß nicht nur nach Produkten, sondern auch nach Rückgabe, Versand oder Zahlungsarten. Führt der Shop solche Begriffe auf eine Serviceseite, prüft dieser Check, ob das nach einer Umstellung noch so ist.
• Nicht geeignet: Aktionsartikel, Restposten und Produkte, die bei fehlendem Bestand aus der Suche verschwinden. Sie machen den Check rot, ohne dass die Suche defekt ist.

Zum Positivlauf gehört eine Gegenprobe. Ein Begriff, den es im Shop sicher nicht gibt, etwa „zz-testbegriff-leer“, muss die Null-Treffer-Seite auslösen; der Check prüft per assert_text deren Meldung. Das klingt überflüssig, fängt aber einen tückischen Fehler: Verliert ein Update den Suchparameter, zeigt der Shop für jeden Begriff dieselbe ungefilterte Produktliste. Der Positivlauf bleibt grün, weil die Winterjacke darin vorkommt. Erst die Gegenprobe wird rot, weil auch der Unsinnsbegriff Treffer liefert.

Die Trefferzahl selbst ist ein schwaches Prüfziel, weil sie mit dem Sortiment schwankt; ein Vergleich auf genaue Gleichheit schlägt bei jedem neuen Produkt an. Die Meldung zur Trefferzahl hat trotzdem eine eigene Bedeutung. Lädt die Trefferliste ohne Seitenwechsel nach, gelten kurze Meldungen wie „18 results returned“ oder „No results returned“ als Statusmeldungen im Sinn des Erfolgskriteriums 4.1.3 der WCAG (W3C), das auf Stufe AA liegt (W3C). Wer sie ohnehin per Selektor anspricht, kann gleich prüfen, ob sie für Screenreader als Status ausgezeichnet ist.

Schrittzeiten: wenn die Suche langsam wird, bevor sie ausfällt

Nicht jeder Ausfall kommt plötzlich. Eine Suche kann über Tage langsamer werden: Der Suchserver hat zu wenig Speicher, eine Warteschlange staut sich, nach einer Umstellung läuft die Suche über die Datenbank. Die Run-Historie hält dafür je Lauf die Gesamtdauer, die Dauer pro Schritt und Erfolg oder Fehler fest (XICTRAQ®). So lässt sich eine schleichende Verschlechterung an einem einzelnen Schritt erkennen, lange bevor der ganze Ablauf bricht (XICTRAQ®).

Für die Suche ist der Schritt wait_for auf die Trefferliste die interessante Zeile: Er misst die Zeit vom Absenden bis zur sichtbaren ersten Produktkarte, also Suche, Übertragung und Darstellung zusammen. Die Übersicht zeigt die letzten 50 Läufe je Monitor (XICTRAQ®-Dokumentation); bei einem Intervall von 15 Minuten sind das gut zwölf Stunden Verlauf. Typische Muster:

• Sprung nach einem Deploy: Die Dauer steigt von einem Lauf auf den nächsten und bleibt oben. Erste Frage: Was wurde ausgeliefert, und läuft die Suche noch über den Suchserver?
• Langsamer Anstieg über Tage: Hinweis auf wachsende Warteschlangen, Speicherdruck oder einen Index, der nicht mehr aufgeräumt wird.
• Ausreißer zu festen Uhrzeiten: Fallen die langsamen Läufe mit Import oder Indexlauf zusammen, konkurrieren beide um dieselben Ressourcen.
• Deutlich andere Dauer ohne Deploy: Dann lohnt der Blick ins Fehlerprotokoll des Shops, ob die Suche auf einen Ersatzweg ausweicht.

Suchvorschläge und Sofortsuche mitprüfen

Viele Shops zeigen schon beim Tippen Vorschläge mit Produktbildern. Diese Liste kommt meist über eine eigene Anfrage und ein eigenes Skript; sie kann ausfallen, während die volle Suche funktioniert, und umgekehrt. Für solche Komponenten gibt es den Schritt type: Er arbeitet wie fill, tippt aber zeichenweise, damit Felder reagieren, die auf jede Eingabe hören (XICTRAQ®-Dokumentation).

{
  "name": "Suchvorschläge: Winterj zeigt Winterjacke",
  "timeout_ms": 10000,
  "steps": [
    {
      "type": "goto",
      "url": "https://shop.example.invalid/"
    },
    {
      "type": "type",
      "selector": "header input[name=search]",
      "value": "Winterj"
    },
    {
      "type": "wait_for",
      "selector": ".search-suggest .search-suggest-product",
      "timeout_ms": 5000
    },
    {
      "type": "assert_text",
      "selector": ".search-suggest",
      "contains": "Winterjacke"
    },
    {
      "type": "screenshot"
    }
  ]
}

Der Vorschlags-Check gehört in einen eigenen Monitor. Fällt nur er aus, sagt der Alarm genau das, und niemand sucht den Fehler im Index. Ein kurzes Timeout ist hier angebracht, weil Vorschläge, die erst nach Sekunden erscheinen, kaum jemand wahrnimmt.

Ergänzend: den Such-Endpunkt per API-Check prüfen

Liefert der Shop seine Suchergebnisse über eine Schnittstelle aus, etwa für eine Headless-Storefront oder die Sofortsuche, lässt sich dieser Endpunkt zusätzlich direkt prüfen. Das API-Monitoring kennt vier Arten von Zusicherungen: Statuscode, Antwortzeit, Werte im JSON-Body per JSON-Path und Textinhalt (XICTRAQ®). Für eine Suche bietet sich diese Kombination an:

• Status 200 als Grundbedingung.
• Antwortzeit unter einer Schwelle, die aus dem eigenen Verlauf abgeleitet ist.
• Trefferzahl im JSON-Body größer als null, über den Operator gt (XICTRAQ®).
• Ein bekannter Produktname im Antworttext per Textprüfung.

Vor dem Einrichten lohnt eine Stichprobe von Hand, welches Feld die Trefferzahl trägt. Adresse und Feldname sind hier Beispiele; der echte Pfad steht in der Schnittstellendokumentation des Shopsystems.

Der Vorteil des API-Checks ist der Takt: Endpunkt-Checks laufen je nach Tarif ab 30 Sekunden (Agency) bis 5 Minuten (Starter) (XICTRAQ®), und der Verlauf zeigt die Antwortzeit der letzten 100 Läufe (XICTRAQ®). Der Nachteil ist die Sicht: Der API-Check sieht weder Template noch Skript noch Suchformular. Er meldet, dass der Index antwortet, nicht, dass die Kundschaft die Treffer zu sehen bekommt.

Such-Check rot: Screenshot lesen, Ursache eingrenzen

Schlägt ein Schritt fehl, nimmt XICTRAQ® im Moment des Fehlers einen Screenshot auf und legt ihn in der Run-Historie ab (XICTRAQ®-Dokumentation). Dazu kommen der Index des fehlgeschlagenen Schritts und die Fehlermeldung (XICTRAQ®-Dokumentation). Der Fehlschlag erzeugt einen Alert mit der Schwere critical (XICTRAQ®-Dokumentation), der über die eingerichteten Alarmkanäle verschickt wird; Wiederholungen fasst die Dedupe zusammen, Vorgabe sind 10 Minuten (XICTRAQ®-Dokumentation). Wird der Lauf wieder grün, schließt XICTRAQ® den Alert automatisch (XICTRAQ®-Dokumentation).

Bei der Suche ist der Screenshot meist schon die halbe Diagnose:

Der Alarm sollte bei der Person landen, die einen Indexlauf anstoßen oder einen Deploy zurückrollen darf, nicht in einem Sammelpostfach. Ob die Kette auch nachts trägt, lässt sich vorher in einer Alarmierungsübung prüfen.

Nach Import, Indexlauf und Deploy sofort prüfen

Suchausfälle folgen typischerweise auf eine Änderung. Darum gehört der Such-Check direkt nach jeder Änderung angestoßen, nicht nur im Intervall. „Jetzt ausführen“ stellt einen Monitor fällig, und der nächste Cron-Tick, der jede Minute läuft, führt ihn aus, ohne das Intervall abzuwarten (XICTRAQ®-Dokumentation). Nach einem Deploy zeigt das in der Regel binnen Minuten, ob die Suche noch findet; wie das mit einem Rückrollen zusammenspielt, beschreibt der Beitrag zum Deploy als Ausfallursache.

Für nächtliche Importe ist eine zweite Messung sinnvoll: Ein Heartbeat am Ende des Importskripts meldet, ob der Import überhaupt durchgelaufen ist. Der Browser-Check danach zeigt, ob das Ergebnis in der Suche angekommen ist. Fehlt der Heartbeat, liegt der Fehler beim Import; ist er da und die Suche leer, beim Index.

Für die Aktionswochen bietet sich dieser Ablauf an:

1. Anfang November: Monitore für Dauerläufer, Artikelnummer, Service-Begriff, Gegenprobe und Suchvorschläge anlegen und mehrfach grün laufen lassen.
2. Vor dem Start der Aktion: Große Importe und Preisupdates nicht in die letzte Nacht legen; nach jedem Import „Jetzt ausführen“.
3. Während der Black Week: Intervall eng setzen, Alarm an die Bereitschaft, die einen Indexlauf anstoßen darf.
4. Für Aktionsartikel: zusätzlich einen Check auf den Namen des Aktionsprodukts, nur für den Aktionszeitraum. Wie sich die Einlösung des Aktionscodes daneben prüfen lässt, zeigt der Beitrag zum Rabattcode im Checkout.
5. Nach der Aktion: Aktions-Checks pausieren und das Intervall der Dauer-Checks zurücksetzen.

Was der Such-Check nicht ersetzt

Ein Browser-Check beweist, dass eine Handvoll fester Begriffe Treffer liefert. Er misst nicht, ob die Reihenfolge der Treffer gut ist, ob Synonyme greifen oder welche Begriffe echter Kundschaft ins Leere laufen. Dafür ist die Auswertung der Suchbegriffe da, wie sie der oben verlinkte Beitrag zur internen Suche beschreibt. Der Check prüft die Funktion, die Auswertung die Qualität.

Die eigenen Zahlen bleiben dabei sauber: Der Runner blockt den XICTRAQ®-Tracker, damit synthetische Läufe die Analytics nicht mit Test-Seitenaufrufen füllen (XICTRAQ®-Dokumentation). Shop-eigene Suchstatistiken zählen den Prüfbegriff dagegen womöglich mit. Jeder Lauf sendet den User-Agent XICTRAQ-BrowserMonitor/1.0 (XICTRAQ®-Dokumentation), über den sich diese Aufrufe im Shop herausfiltern lassen.

Nach einem größeren Umbau von Suchserver, Theme oder Shopversion gehört die Suche zudem vor dem Livegang mit einer längeren Begriffsliste von Hand geprüft. Weitere Prüfpunkte für Shopware-Shops sammelt die Seite zum Shopware-Monitoring; dieselbe Bauart von Check überwacht auch die Beschriftung des Bestellbuttons.

Checkliste: Shopsuche überwachen vor der Black Week

• Drei bis fünf Suchbegriffe festlegen: Dauerläufer, Artikelnummer, Begriff mit Umlaut, Service-Begriff
• Je Begriff einen Browser-Check mit wait_for auf die erste Produktkarte und assert_text auf den Produktnamen anlegen
• Gegenprobe mit einem Unsinnsbegriff einrichten, die die Null-Treffer-Meldung erwartet
• Suchvorschläge als eigenen Monitor mit dem Schritt type prüfen
• Schrittzeiten der Trefferliste eine Woche lang beobachten und als Normalwert notieren
• Bei einer Such-Schnittstelle zusätzlich einen API-Check mit Trefferzahl größer null anlegen
• Nach jedem Import, Indexlauf und Deploy „Jetzt ausführen“
• Heartbeat ans Ende des Importskripts setzen
• Alarm an die Person leiten, die einen Indexlauf anstoßen darf

Die Suche gehört zu den Funktionen, die man misst

Eine Shopsuche, die antwortet, ist noch keine Suche, die findet. Zwischen beiden liegen Index, Warteschlange, Suchserver und Template, und jede dieser Schichten kann nach einer Änderung still ausfallen. Ein Browser-Check mit festem Suchbegriff, einer Gegenprobe und einem Blick auf die Schrittzeiten macht daraus eine Messung mit Uhrzeit, Screenshot und Alarm. Browser-Monitoring ist ab dem Business-Plan enthalten (XICTRAQ®-Dokumentation); die Tarife stehen auf der Preisseite. Wer die Monitore jetzt im Browser-Monitoring anlegt, hat bis zum 27. November eine Reihe grüner Läufe und einen Normalwert für die Schrittzeiten, an dem sich jede Abweichung ablesen lässt.