WooCommerce-Monitoring vom Warenkorb bis zum WP-Cron
XICTRAQ überwacht Shop, Warenkorb, Kasse und die Hintergrundaufgaben Ihres WooCommerce-Shops und erkennt den WordPress-Wartungsmodus bei Updates als geplante Pause statt als Ausfall. Der cookielose Tracker liest Produktaufrufe, Warenkorb und Bestellabschluss aus dem Markup der klassischen WooCommerce-Vorlagen.
Diese Pfade zuerst prüfen
- Uptime-MonitoringStartseite mit Wartungserkennung
/ - Uptime-MonitoringKundenkonto, meist vom Seiten-Cache ausgenommen
/mein-konto/ - Skript-IntegritätWarenkorb: Dritt-Skripte und Formularziele
/warenkorb/ - Browser-MonitoringVom Produkt über den Warenkorb bis zur Kasse
/kasse/ - Security-ScanOffen lesbares Fehlerprotokoll
/wp-content/debug.log
Warum ein Check der Startseite bei WooCommerce nicht reicht
WooCommerce läuft als Plugin in WordPress, zusammen mit Theme, Zahlungs-, Versand- und weiteren Erweiterungen. WooCommerce empfiehlt, Warenkorb, Kasse und Kundenkonto vom Seiten-Cache auszunehmen. Fallen PHP oder Datenbank aus, kann eine zwischengespeicherte Startseite darum weiter antworten, während genau die Seiten scheitern, auf denen verkauft wird.
XICTRAQ verteilt die Prüfung deshalb auf mehrere Module: Uptime-Monitoring mit Unterseiten und Wartungserkennung, Browser-Checks für den Weg zur Kasse, Heartbeats für WP-Cron und die geplanten Aktionen von WooCommerce, den Security-Scan für offen liegende Dateien und die Skript-Integrität für eingebundene Dritt-Skripte.
Die Pfade auf dieser Seite gelten für eine deutschsprachige Installation, in der die Seiten in der Regel /warenkorb/, /kasse/ und /mein-konto/ heißen. In englischsprachigen Installationen lauten sie /cart/, /checkout/ und /my-account/. Maßgeblich ist die Adresse, die Ihr Shop tatsächlich verwendet.
Lassen Sie Browser-Checks vor dem Bestellknopf enden, damit keine echten Bestellungen entstehen, und melden Sie sich im Kundenkonto mit einem eigenen Testkunden an statt mit einem echten Kundenkonto.
Was in WooCommerce-Shops typischerweise bricht
Kritischer Fehler nach einem Plugin-Update
Löst ein Plugin-, Theme- oder WordPress-Update einen schweren PHP-Fehler aus, zeigt WordPress seine Meldung über einen kritischen Fehler und antwortet mit HTTP 500. Das Uptime-Monitoring wertet Statuscodes außerhalb von 200 bis 399 als Ausfall, sofern es keine Wartung und keine Bot-Abwehr erkennt, und meldet hinterlegte Unterseiten einzeln. Bleibt die Antwort bei 200 und fehlt nur ein Teil der Seite, meldet ein Schlüsselwort-Check auf der überwachten Adresse das fehlende Wort.
Seiten-Cache verdeckt den Ausfall
WooCommerce empfiehlt, Warenkorb, Kasse und Kundenkonto vom Seiten-Cache auszunehmen. Fallen PHP oder Datenbank aus, kann die zwischengespeicherte Startseite weiter mit HTTP 200 antworten, während diese Seiten scheitern. Das Uptime-Monitoring ruft hinterlegte Unterseiten wie /mein-konto/ oder /warenkorb/ direkt auf und löst für eine nicht erreichbare Unterseite einen eigenen Alarm aus.
Wartungsmodus während eines Updates
Während WordPress den Kern oder aktive Plugins und Themes aktualisiert, antwortet es in der Regel mit HTTP 503 und dem Hinweis, die Website sei wegen Wartungsarbeiten kurzzeitig nicht verfügbar. XICTRAQ erkennt diese Seite auf Deutsch wie auf Englisch als Wartung: Ausfall- und Inhaltsalarme pausieren, SSL-, Domain- und Blacklist-Alarme laufen weiter. Beginn und Ende stehen im Changelog. Eine Wartungsseite aus einem Plugin, die mit HTTP 200 antwortet, bleibt für das Monitoring eine normale Seite.
Kasse lädt, Bestellen scheitert
Ein JavaScript-Fehler aus einem Zahlungs- oder Checkout-Plugin kann die Kasse lahmlegen, obwohl jede Seite mit HTTP 200 antwortet. Ein Browser-Check legt ein Produkt in den Warenkorb, öffnet die Kasse, füllt Felder aus und prüft, ob erwartete Elemente sichtbar sind. Schlägt ein Schritt fehl, löst XICTRAQ einen Alarm aus und legt, soweit möglich, einen Screenshot des fehlgeschlagenen Schritts ab. Zusätzlich meldet der Tracker JavaScript-Fehler aus echten Besuchen mit Meldung, Datei und Zeile.
WP-Cron und geplante Aktionen stehen
WP-Cron prüft bei jedem Seitenaufruf, ob geplante Aufgaben fällig sind, und der Action Scheduler von WooCommerce wird in der Grundeinstellung über WP-Cron und bei Aufrufen im Adminbereich angestoßen. Bei wenig Besuchern können sich so geplante Aufgaben verzögern, etwa das Stornieren unbezahlter Bestellungen oder die Zustellung von Webhooks. Lösen Sie WP-Cron über den Server-Cron aus und hängen Sie den Aufruf eines Heartbeats an: Bleibt sein Ping über das erwartete Intervall samt Toleranz aus, meldet XICTRAQ den verpassten Lauf.
Fehlerprotokoll oder Konfigurationskopie offen lesbar
Mit WP_DEBUG_LOG schreibt WordPress Fehler in der Grundeinstellung nach wp-content/debug.log, und eine liegen gebliebene Kopie wie wp-config.php.bak kann die Zugangsdaten zur Datenbank enthalten. Der Security-Scan fragt solche Dateien ab und listet die, die mit HTTP 200 antworten, eine offene wp-config.php.bak als kritisch. Antwortet ein Server auf jede Adresse mit 200, überspringt der Scan diese Abfragen, statt Scheinbefunde zu melden.
Woran XICTRAQ WooCommerce erkennt
Die Technikerkennung liest HTML und Antwortköpfe der überwachten Seite. Sie erkennt zuerst WordPress und darin WooCommerce, ein Wechsel des erkannten CMS landet im Changelog. Die Wartungserkennung wertet dagegen die Antwort selbst aus, unabhängig vom erkannten System.
- WordPress an Pfaden wie /wp-content/, /wp-includes/ oder /wp-json/ im Quelltext oder am Generator-Tag, WooCommerce zusätzlich an den Kennungen woocommerce oder wc-blocks.
- Wartung erkennt XICTRAQ an einer 503-Antwort, die den WordPress-Hinweis auf planmäßige Wartung auf Englisch oder Deutsch trägt oder einen Wartungshinweis im Seitentitel. Ein 503 ohne solchen Hinweis und ohne erkennbare Bot-Abwehr bleibt eine Störung.
- Wechselt das erkannte CMS, etwa beim Umzug von WordPress auf ein anderes System, schreibt XICTRAQ einen Eintrag „CMS gewechselt“ in den Changelog.
- Kommt statt der Seite eine Fehlerseite oder eine Bot-Abwehr zurück, bewertet XICTRAQ CMS und Shop in diesem Lauf nicht und leitet daraus keinen Systemwechsel ab. Server- und CDN-Angaben aus den Antwortköpfen gelten weiter.
Was der Tracker in WooCommerce erfasst
Der Tracker erkennt WooCommerce an den Skriptvariablen wc_add_to_cart_params oder woocommerce_params oder an einem Element mit der Klasse woocommerce und liest Shop-Ereignisse aus dem Markup der klassischen WooCommerce-Vorlagen. Er setzt keine Cookies und legt im Standard-Tracking nichts im Browser-Speicher ab. Shop-Ereignisse verbucht XICTRAQ, sofern Ihr Tarif E-Commerce-Tracking enthält.
Erfasst der Tracker von selbst
- Seitenaufrufe mit Herkunft und UTM-Parametern, Web Vitals wie LCP, CLS und INP sowie JavaScript-Fehler mit Meldung, Datei und Zeile.
- Produktaufrufe mit Produkt-ID, Name und Kategorie aus dem Markup der Produktseite oder aus deren strukturierten Produktdaten. Als Preis dient der erste Betrag im Markup, bei einem Sonderpreis oder einer Warenkorbsumme im Kopfbereich kann das ein anderer Betrag als der Verkaufspreis sein.
- Klicks auf „In den Warenkorb“: auf der Produktseite mit Produkt-ID, Name, Menge und dem Preis wie beim Produktaufruf, in Produktlisten mit der Produkt-ID, dazu Warenkorb-Klicks in Produktblöcken.
- Mengenänderungen und Entfernen im klassischen Warenkorb, je Artikel mit dem Endwert statt jedem Zwischenschritt.
- Den Warenkorb-Stand im klassischen Warenkorb: Positionen mit Menge und Preis sowie die Summen, die der Summenkasten ausweist.
- Den Bestellabschluss auf der Bestellbestätigung mit Gesamtbetrag und Bestellnummer aus der klassischen Bestellübersicht. Lädt der Kunde die Seite neu, verbucht XICTRAQ dieselbe Bestellnummer nicht erneut als Umsatz.
- Den Beginn des Checkouts auf einer Kasse, deren Adresse „checkout“ enthält, etwa /checkout/.
Nicht automatisch erfasst
- Fremdwährungen in der automatischen Erkennung: Den Bestellumsatz aus der Bestellübersicht meldet der Tracker als EUR, auch wenn der Shop in einer anderen Währung abrechnet. Eine andere Währung übergeben Sie über xictraq.revenue().
- Den Checkout-Beginn unter /kasse/: Die automatische Erkennung sucht „checkout“ in der Adresse, die deutsche Standardadresse der Kasse enthält das nicht.
- Mengenänderungen, Entfernen und Warenkorb-Stand im Warenkorb aus Blöcken. Die Erkennung dafür deckt nur den klassischen Warenkorb ab.
- Umsatz auf Bestätigungsseiten, die den Gesamtbetrag nicht in der klassischen Bestellübersicht von WooCommerce ausgeben.
- Angemeldete Kunden: WordPress selbst kennzeichnet sie am body nur mit der Klasse logged-in, ohne Kundennummer. Für die Zuordnung braucht es eine Kennung, etwa eine vom Theme gesetzte body-Klasse nach dem Muster user-id-Nummer, ein Attribut data-user-id, window.xictraqUser, das Meta-Tag xictraq:user-id oder xictraq.identify().
- Steuer, Versand und Gutscheincode am Kaufereignis selbst.
- Stornos und Erstattungen, die im WordPress-Backend entstehen. Dafür gibt es kein automatisches Ereignis.
Fehlende Werte übergeben Sie über die JavaScript-API: xictraq.checkout("begin") auf einer Kasse unter /kasse/, xictraq.revenue(betrag, "EUR", bestellnummer, { tax, shipping, coupon }) auf einer Bestätigungsseite ohne klassische Bestellübersicht, xictraq.identify(kundennummer, { group }) für angemeldete Kunden und xictraq.refund(bestellnummer, betrag, "EUR") für Erstattungen, Beträge in Euro.
Die passenden Module für WooCommerce
Häufige Fragen
Wie binde ich den XICTRAQ-Tracker in einen WooCommerce-Shop ein?
Sie fügen das Skript-Tag mit Ihrer Website-Kennung im Attribut data-site in den Kopfbereich jeder Seite ein, etwa über das Child-Theme oder ein Plugin für eigenen Kopfcode. Das Skript lädt mit defer und setzt keine Cookies. Danach erkennt der Tracker WooCommerce selbst und liest Produktaufrufe, Warenkorb und Bestellabschluss aus dem Markup.
Löst der WordPress-Wartungsmodus bei Updates einen Ausfallalarm aus?
In der Regel nicht. Im Wartungsmodus antwortet WordPress mit HTTP 503 und dem Hinweis auf Wartungsarbeiten, XICTRAQ erkennt diese Kombination als Wartung. Ausfall- und Inhaltsalarme pausieren, SSL-, Domain- und Blacklist-Alarme bleiben scharf, Beginn und Ende stehen im Changelog. Ein 503 ohne Wartungshinweis und ohne erkennbare Bot-Abwehr wertet XICTRAQ dagegen als Störung, weil auch ein überlasteter Server so antwortet.
Welche Unterseiten sollte ich bei WooCommerce zusätzlich überwachen?
Vor allem Warenkorb und Kundenkonto, in deutschsprachigen Installationen meist /warenkorb/ und /mein-konto/. WooCommerce empfiehlt, sie vom Seiten-Cache auszunehmen, sie zeigen darum in der Regel einen Fehler, den eine zwischengespeicherte Startseite verdeckt. Das Uptime-Monitoring meldet jede hinterlegte Unterseite einzeln, wie viele Pfade möglich sind, hängt vom Tarif ab. Die Kasse prüfen Sie besser mit einem Browser-Check, der vorher ein Produkt in den Warenkorb legt.
Wie überwache ich WP-Cron und die geplanten Aktionen von WooCommerce?
Mit einem Heartbeat: Schalten Sie WP-Cron per DISABLE_WP_CRON in der wp-config.php ab, lösen Sie es über den Server-Cron aus, etwa mit wp cron event run --due-now, und rufen Sie danach die Ping-Adresse des Heartbeats auf. Bleibt der Ping über das erwartete Intervall samt Toleranz aus, meldet XICTRAQ den verpassten Lauf. Eigene Adressen für Start und Fehlschlag erfassen zusätzlich Laufzeit und Abbrüche. Ob einzelne Aktionen im Action Scheduler scheitern, zeigt der Ping nicht, er belegt den Lauf selbst.
Prüft XICTRAQ die Zahlungs-Skripte im WooCommerce-Checkout?
Sofern Ihr Tarif die Skript-Integrität enthält, hält sie bei einem Scan Ihrer verifizierten Website für bis zu zwölf eingebundene externe Skripte der gescannten Seite den SHA-256-Hash fest und meldet, wenn sich ein Skript später ändert. Scannen Sie einen Pfad wie /warenkorb/ oder /kasse/, achtet sie zusätzlich auf neue externe Formularziele. Skripte von der eigenen Shop-Domain, also auch WooCommerce selbst und lokal installierte Plugins, gehören nicht zu dieser Prüfung, ebenso wenig Inline-Skripte.
Erfasst der Tracker auch Warenkorb und Kasse aus Blöcken?
Teilweise. Warenkorb-Klicks in Produktblöcken erfasst er, Mengenänderungen, Entfernen und den Warenkorb-Stand liest er nur aus dem klassischen Warenkorb. Den Checkout-Beginn meldet er, wenn die Adresse „checkout“ enthält und ein Element mit der Klasse woocommerce-checkout vorhanden ist, den Umsatz nur aus der klassischen Bestellübersicht auf der Bestätigungsseite. Wo das nicht greift, rufen Sie xictraq.checkout("begin") und xictraq.revenue() selbst auf.