Shopware-Monitoring von der Storefront bis zur Store API
XICTRAQ prüft Storefront, Kasse, Store API und Hintergrundprozesse Ihres Shopware-Shops und erkennt den Wartungsmodus als geplante Pause statt als Ausfall. Der cookielose Tracker liest Produktaufrufe, Warenkorb und Bestellabschluss direkt aus dem Standard-Markup von Shopware 6.
Diese Pfade zuerst prüfen
- Uptime-MonitoringStartseite mit Wartungserkennung
/ - Skript-IntegritätWarenkorb: Dritt-Skripte und Formularziele
/checkout/cart - Browser-MonitoringVom Produkt bis zur Bestellübersicht
/checkout/confirm - Browser-MonitoringAnmeldung mit einem Testkunden
/account/login - API-MonitoringStore API mit sw-access-key
/store-api/product - SEO-MonitoringSitemap samt verlinkter .xml.gz-Dateien
/sitemap.xml
Warum ein Ping auf die Startseite nicht reicht
Ein Shopware-6-Shop besteht aus mehr als der Storefront: Die Store API bedient Headless-Frontends und Apps, geplante Aufgaben und die Nachrichtenwarteschlange laufen als eigene Hintergrundprozesse, Plugins und Theme greifen in Warenkorb und Kasse ein. Ein Update kann an jeder dieser Stellen etwas verschieben, während die Startseite weiter mit HTTP 200 antwortet.
XICTRAQ verteilt die Prüfung deshalb auf mehrere Module: Uptime-Monitoring mit Unterseiten und Wartungserkennung, Browser-Checks für den Weg zur Kasse, API-Checks für die Store API, Heartbeats für die Hintergrundprozesse und die Skript-Integrität für eingebundene Dritt-Skripte.
Shopware 5 überwacht XICTRAQ ebenfalls per Uptime-, Browser- und API-Checks. Die Shop-API-Anbindung für Patchstand, Bestellstatus und Bestellimport gibt es dagegen nur für Shopware 6; Shopware-5-Shops erkennt der Scan und meldet das Supportende, per API anbinden lassen sie sich nicht. Der Hersteller hat die Weiterentwicklung von Shopware 5 Ende Juli 2024 eingestellt und liefert seitdem keine regulären Sicherheitsupdates mehr. Der Tracker erfasst dort deutlich weniger als bei Shopware 6: Produktaufrufe und Warenkorb-Klicks auf der Produktdetailseite, den Bestellabschluss nur über einen dataLayer-Eintrag oder einen eigenen Aufruf.
Lassen Sie Browser-Checks auf der Bestellübersicht enden, damit keine echten Bestellungen entstehen, und melden Sie sich dabei mit einem eigenen Testkunden an statt mit einem echten Kundenkonto.
Was in Shopware-Shops typischerweise bricht
Wartungsmodus, geplant oder vergessen
Ist der Wartungsmodus eines Verkaufskanals aktiv, leitet Shopware 6 Besucher auf /maintenance um und antwortet dort mit HTTP 503. XICTRAQ wertet das als Wartung: Ausfall- und Inhaltsalarme pausieren, SSL-, Domain- und Blacklist-Alarme bleiben scharf. Beginn und Ende stehen im Changelog, sodass sich auch ein vergessener Wartungsmodus nachvollziehen lässt.
Serverfehler nach Update oder Plugin-Installation
Nach einem Update kann die Storefront oder eine einzelne Seite mit einem Serverfehler antworten, während andere Seiten noch laufen. Das Uptime-Monitoring prüft neben der Startseite auch hinterlegte Unterseiten wie /checkout/cart, meldet einen Ausfall je Pfad mit Statuscode und hält im Verlauf die Zeitanteile von DNS, Verbindung, TLS und erster Antwort fest.
Kauf-Button oder Kasse reagiert nicht
Ein JavaScript-Fehler aus einem Plugin kann den Warenkorb-Button oder die Kasse lahmlegen, obwohl jede Seite mit HTTP 200 antwortet. Ein Browser-Check klickt den Weg vom Produkt über den Warenkorb bis zur Bestellübersicht durch und hält beim fehlgeschlagenen Schritt einen Screenshot fest. Zusätzlich meldet der Tracker JavaScript-Fehler aus echten Besuchen, wiederholt gesehene Fehler lösen einen Alarm aus.
Geplante Aufgaben und Warteschlange stehen
Geplante Aufgaben brauchen in Shopware 6 einen Hintergrundprozess wie bin/console scheduled-task:run, die Nachrichtenwarteschlange verarbeitet in der empfohlenen Einrichtung ein Worker mit messenger:consume. Steht einer davon, bleibt die Storefront in der Regel erreichbar und ein Erreichbarkeits-Check sieht nichts. Ein Heartbeat erwartet nach jedem Lauf einen Ping und meldet, wenn er ausbleibt oder ein Fehlschlag gemeldet wird.
Manipuliertes Dritt-Skript im Checkout
Zahlungs-, Chat- oder Marketing-Skripte fremder Anbieter laden auf Warenkorb und Kasse mit. Bei einer verifizierten Website hält die Skript-Integrität beim Scan den SHA-256-Hash externer Skripte fest, ruft sie danach regelmäßig erneut ab und meldet Abweichungen. Scannen Sie zusätzlich /checkout/cart, meldet ein späterer Scan dieser Seite neue externe Formularziele. Skripte von der eigenen Shop-Domain gehören nicht zu dieser Prüfung.
Store API liefert Fehler oder leere Daten
Headless-Frontends und Apps nutzen die Store API unter /store-api/. Das API-Monitoring ruft einen Endpunkt wie /store-api/product mit dem Zugriffsschlüssel des Verkaufskanals im Header sw-access-key auf und prüft Statuscode, Antwortzeit und per JSON-Pfad einzelne Felder der Antwort. So fällt auch eine Antwort auf, die mit HTTP 200 kommt, aber nicht mehr die erwarteten Daten enthält.
Woran XICTRAQ Shopware erkennt
Die Technikerkennung liest HTML und Antwortköpfe der überwachten Seite und unterscheidet Shopware 6 von Shopware 5. Ein Wechsel des erkannten Systems landet im Changelog, Wartungserkennung und Tracker arbeiten davon unabhängig.
- Shopware 6 an Antwortköpfen wie sw-language-id und sw-currency-id oder an Spuren im HTML wie /bundles/storefront/ oder data-sales-channel-id.
- Shopware 5 an Pfaden wie /engine/Shopware/ oder /themes/Frontend/Responsive/. Geführt wird Shopware 5 als „Shopware“, Shopware 6 als „Shopware 6“.
- Wechselt das erkannte System, etwa bei der Migration von Shopware 5 auf 6, schreibt XICTRAQ einen Eintrag „CMS gewechselt“ mit altem und neuem System in den Changelog.
- Bei Shopware 6 fragt XICTRAQ zusätzlich die Adminseite /admin ab und liest aus deren Versionsschaltern Haupt- und Nebenversion. Ändert sie sich, steht die alte und die neue Version im Changelog, ein Rückschritt als Warnung.
- Den genauen Patchstand, etwa 6.7.14.2, liest XICTRAQ auf Wunsch über die Admin-API eines Shopware-6-Shops. Dafür legen Sie in der Shopware-Administration unter Einstellungen › System › Integrationen eine Integration ohne Administratorrechte an und tragen deren Zugangsschlüssel in den Website-Einstellungen ein, sobald die Domain bestätigt ist; für den Patchstand braucht sie keine Rolle. Abgerufen wird einmal täglich die Versionsnummer; ändert sich der Patchstand, steht der Wechsel im Changelog. Wer zusätzlich den Bestellstatus im Bestellverlauf sehen möchte, schaltet ihn dort ein und gibt der Integration eine Rolle mit Leserecht auf Bestellungen, Zahlungen, Lieferungen und deren Status. Für den Bestellstatus werden dann nur Bestellnummer und Status der vom Tracker erfassten Käufe gelesen, keine Kundendaten.
- Mit dem optionalen Bestellimport holt XICTRAQ über dieselbe Integration den gesamten bisherigen Bestellverlauf und danach alle zehn Minuten neue und geänderte Bestellungen, auch die in der Administration angelegten, etwa nach einer telefonischen Bestellung. Die Rolle braucht dafür unter Einstellungen › System › Benutzer & Rechte › Rolle › Detaillierte Privilegien genau acht Einträge, jeweils nur mit „Lesen“: order, order_line_item, order_transaction, order_delivery, state_machine_state, payment_method, shipping_method und currency. Abgerufen werden Bestellnummer, Zeitpunkt, Beträge mit Steuer und Versandkosten, Währung, Zahlungs- und Versandart, Status und Positionen sowie Name, Firma und Kundennummer des Bestellers. E-Mail-Adresse, Anschrift, Telefonnummer, Kommentar des Bestellers und USt-IdNr fordert XICTRAQ nicht an, auch wenn die Rolle einzelne davon lesbar macht. Bestellungen, die der Tracker bereits erfasst hat, zählen nicht doppelt; schalten Sie den Import aus oder trennen Sie die Anbindung, werden die importierten Daten gelöscht. Der Bestellimport gehört zum Business-Tarif; die Anleitung Schritt für Schritt steht in der Dokumentation unter „Shop-Anbindung (Shopware 6)“.
- Wartung erkennt XICTRAQ an einer 503-Antwort, die nach Weiterleitungen auf /maintenance landet oder einen Wartungshinweis in Titel oder Text trägt. Ein 503 ohne solchen Hinweis bleibt eine Störung.
- Kommt kein Seiteninhalt zurück, etwa hinter einer Bot-Abwehr, bleibt die bisherige Shop-Erkennung stehen, statt als „kein Shopware“ verbucht zu werden.
Was der Tracker in Shopware erfasst
Der Tracker erkennt Shopware 6 an window.salesChannelId aus dem Standard-Template und liest Shop-Ereignisse direkt aus dem Storefront-Markup. Er setzt keine Cookies und legt im Standard-Tracking nichts im Browser-Speicher ab.
Erfasst der Tracker von selbst
- Seitenaufrufe mit Herkunft, UTM-Parametern und Gerätetyp, dazu Ladezeiten und Web Vitals wie LCP, CLS und INP.
- Produktaufrufe auf der Produktdetailseite von Shopware 6 mit Name und Preis, dazu die Produktnummer, soweit das Markup sie als itemprop="sku" ausgibt.
- Klicks auf „In den Warenkorb“ mit Produkt, Preis und Menge, Mengenänderungen und Entfernen auf der Warenkorbseite sowie das Entfernen im Off-Canvas-Warenkorb.
- Den Warenkorb-Stand auf Seiten mit Warenkorbpositionen: Positionen, Zwischensumme, Versand, Steuer und Gesamtbetrag. Im Off-Canvas-Warenkorb Positionen und Gesamtbetrag.
- Den Beginn des Checkouts auf der Bestellübersicht unter /checkout/confirm.
- Den Bestellabschluss auf /checkout/finish mit Gesamtbetrag und Bestellnummer, soweit die Abschlussseite sie anzeigt.
- JavaScript-Fehler aus echten Besuchen mit Meldung, Datei und Zeile.
Nicht automatisch erfasst
- Angemeldete Kunden: Der Tracker ordnet sie nur zu, wenn das Theme eine Kundenkennung ausgibt, etwa als data-customer-id oder window.customerId. Das Standard-Template von Shopware 6 tut das nicht.
- Fremdwährungen am Bestellumsatz: Der Abschlussbetrag wird als EUR gemeldet, auch wenn der Verkaufskanal in einer anderen Währung abrechnet. Dasselbe gilt für den Stand des Off-Canvas-Warenkorbs.
- Steuer, Versandkosten und einzelne Positionen am Kaufereignis selbst. Diese Werte stehen nur im getrennt erfassten Warenkorb-Stand; mit dem Bestellimport kommen die Positionen zugeordneter Bestellungen aus dem Shop.
- Stornos und Erstattungen. Dafür gibt es kein automatisches Ereignis; mit dem optionalen Bestellimport kommt ihr Stand aus dem Shop.
- Bei Shopware 5 den Bestellabschluss und den Umsatz, sofern kein Plugin den Kauf als purchase-Eintrag im dataLayer ablegt. Den Checkout-Beginn meldet dort sonst nur eine allgemeine Pfaderkennung, die bereits auf /checkout/cart anschlägt.
- Bestellungen, die ohne Storefront-Seite entstehen, etwa über die Administration oder einen Store-API-Client ohne Tracker. Mit dem optionalen Bestellimport über die Admin-API zählen sie dennoch mit.
Fehlende Werte übergeben Sie über die JavaScript-API: xictraq.revenue(betrag, "EUR", bestellnummer, { tax, shipping }) auf der Abschlussseite eines Shopware-5-Shops, xictraq.identify(kundenId, { group }) für angemeldete Kunden und xictraq.refund(bestellnummer, betrag, "EUR") für Erstattungen.
Die passenden Module für Shopware
Häufige Fragen
Löst der Shopware-Wartungsmodus einen Ausfallalarm aus?
In der Regel nicht. Shopware 6 leitet bei aktivem Wartungsmodus auf /maintenance um und antwortet dort mit HTTP 503. XICTRAQ erkennt diese Kombination als Wartung und pausiert Ausfall- und Inhaltsalarme, SSL-, Domain- und Blacklist-Alarme bleiben scharf. Ein 503 ohne Wartungshinweis wertet XICTRAQ dagegen als Störung, weil auch ein überlasteter Server so antwortet.
Kann ein Browser-Check den Checkout von Shopware durchspielen?
Ja. Ein Browser-Check kann Seiten öffnen, klicken, Formulare ausfüllen, auf Elemente warten und Texte, Adressen oder Statuscodes prüfen. Lassen Sie ihn auf der Bestellübersicht unter /checkout/confirm enden, damit keine echten Bestellungen entstehen. Für die Anmeldung unter /account/login nutzen Sie einen eigenen Testkunden statt eines echten Kundenkontos.
Wie überwache ich die Shopware Store API?
Legen Sie im API-Monitoring einen Endpunkt wie /store-api/product an und hinterlegen Sie den Zugriffsschlüssel des Verkaufskanals als Header sw-access-key. Prüfen lassen sich Statuscode, Antwortzeit, Textinhalte, Antwortköpfe sowie einzelne Felder per JSON-Pfad oder die ganze Antwort per JSON-Schema.
Wie bemerke ich, dass geplante Aufgaben oder der Queue-Worker nicht mehr laufen?
Mit einem Heartbeat: Sie hängen an den Cron-Eintrag mit bin/console scheduled-task:run --no-wait einen Aufruf der Ping-Adresse an. Bleibt der Ping über das erwartete Intervall samt Toleranz aus, meldet XICTRAQ den verpassten Lauf. Über eigene Adressen für Start und Fehlschlag erfassen Sie zusätzlich Laufzeit und Abbrüche, das eignet sich auch für einen Worker mit messenger:consume, der per --time-limit regelmäßig endet und neu gestartet wird.
Was erfasst der Tracker bei Shopware 5?
Deutlich weniger als bei Shopware 6: Produktaufrufe und Warenkorb-Klicks auf der Produktdetailseite, dazu Seitenaufrufe, Web Vitals und JavaScript-Fehler. Bestellabschluss und Umsatz erfasst er nur, wenn ein Plugin den Kauf im dataLayer ablegt; sonst rufen Sie auf der Abschlussseite xictraq.revenue() selbst auf. Vom Hersteller erhält Shopware 5 seit Ende Juli 2024 keine regulären Sicherheitsupdates mehr.
Findet der Security-Scan offen liegende Shopware-Dateien?
Er fragt neben allgemeinen Dateien wie .env, .git/config oder SQL-Dumps auch .env.local, config/jwt/private.pem sowie auth.json und composer.json aus Composer ab. Offen liegen sie in der Regel nur, wenn das Web-Verzeichnis auf den Projektordner zeigt statt auf public. Gemeldet wird eine Datei erst, wenn ihr Anfang zu ihr passt, etwa der Kopf eines privaten Schlüssels; eine Start- oder Fehlerseite, die unter jeder Adresse antwortet, zählt nicht als Treffer. In Installationen mit Schlüsseldateien unterschreibt config/jwt/private.pem die Zugangstoken der Admin-API, ein offener Schlüssel steht darum als kritisch im Bericht.
Meldet XICTRAQ eine veraltete Shopware-Version?
Ja, mit Einschränkung. Shopware 5 gilt als ohne Herstellerupdates und wird als veraltet gemeldet. Per API anbinden lässt sich Shopware 5 nicht. Bei Shopware 6 liest XICTRAQ die Haupt- und Nebenversion, etwa 6.6, aus der öffentlich erreichbaren Adminseite und bewertet sie gegen die Release-Notes des Herstellers; den Patchstand verrät die Adminseite nicht. Verbinden Sie den Shop über eine Integration ohne Rolle mit XICTRAQ, kommt der genaue Patchstand, etwa 6.7.14.2, einmal täglich aus der Admin-API. Ohne diese Anbindung und bei gesperrter Adminseite bleibt die Version ungemessen. Ein Wechsel der Version oder zwischen Shopware 5 und 6 steht im Changelog. Das CRA-Cockpit bewertet zusätzlich Komponenten, die ihre Version preisgeben, etwa PHP im Antwortkopf, den Webserver, OpenSSL oder jQuery.
Welche Rechte braucht die Integration für den Bestellimport?
Eine Rolle mit genau acht Einträgen, jeweils nur „Lesen“: order, order_line_item, order_transaction, order_delivery, state_machine_state, payment_method, shipping_method und currency. Sie legen die Rolle unter Einstellungen › System › Benutzer & Rechte an, setzen die Rechte unter „Detaillierte Privilegien“ und weisen sie unter Einstellungen › System › Integrationen der Integration zu; Administratorrechte braucht diese nicht. Beim Einschalten prüft XICTRAQ die Rechte sofort und nennt fehlende. Mit dem Leserecht auf order macht Shopware technisch auch übrige Kundenangaben wie die E-Mail-Adresse lesbar; XICTRAQ fordert davon nur Name, Firma und Kundennummer an.
Zählt XICTRAQ Bestellungen aus dem Shop-Admin und vom Tracker verpasste Käufe mit?
Ja, mit dem Bestellimport. Bestellungen aus dem Shop-Admin zählen beim nächsten Abgleich, Online-Bestellungen ohne erfassten Kauf nach zwei Stunden, damit eine späte Meldung des Trackers nicht doppelt zählt. Sie fließen in Umsatz, Bestellungen, Produkte und Berichte ein, nicht in Conversion-Rate und Funnel, weil ihnen kein Besuch zugrunde liegt. Im Shop stornierte Bestellungen übernimmt der Import nicht.