Ein Kunde legt Produkte in den Warenkorb, klickt auf „Kaufen“ und landet auf einer Fehlerseite. Er bricht ab, kauft woanders, und du erfährst es nie. WooCommerce Monitoring soll genau solche stillen Fehler sichtbar machen, bevor sie sich über Tage summieren. Hier erfährst du, welche Ebenen eine Überwachung braucht und was WooCommerce und Google schon mitbringen: die Fehlerprotokolle unter WooCommerce > Status > Logs, den Core-Web-Vitals-Bericht der Search Console und einen Update-Ablauf mit Testbestellung.
Warum stille Fehler im Shop so gefährlich sind
Ein ausgefallenes Produkt oder eine kurze Serverunterbrechung fühlen sich harmlos an. Den größeren Schaden richten oft die unauffälligen Probleme an, die über Tage bestehen bleiben. Stell dir deinen Online-Shop wie ein Ladengeschäft vor, dessen Eingangstür manchmal von innen blockiert ist. Du stehst im Hinterzimmer, siehst keine Kunden und verstehst nicht, warum der Umsatz sinkt.
Typische stille Fehler in WooCommerce
- Checkout-Fehler durch Plugins, die sich nach einem Update nicht mehr vertragen
- 500er-Serverfehler, die nur bei bestimmten Produktseiten oder unter Last auftreten
- Kaputte Weiterleitungen nach Updates, die Kunden in eine Sackgasse schicken
- Fehlgeschlagene E-Mail-Benachrichtigungen, sodass Bestellbestätigungen nie ankommen
- Ausfälle beim Zahlungsanbieter, bei denen das Problem gar nicht in deinem Shop liegt
- Datenbankfehler, die Produkte oder Preise falsch anzeigen
Warum Kunden sich selten melden
Ein Kunde, der an der Kasse scheitert, hinterlässt meist keine Spur, die du ohne Suche findest: keine Bestellung, keine Nachricht. Er schließt einfach den Tab. Wer auf Rückmeldungen als einzige Fehlerquelle wartet, erfährt von einem Problem also erst, wenn sich jemand die Mühe macht, es zu melden, und das ist grundsätzlich zu spät.
Was eine unbemerkte Stunde kostet
Eine pauschale Summe gibt es nicht, du kannst sie für deinen Shop aber selbst überschlagen: durchschnittliche Bestellungen pro Stunde mal durchschnittlicher Warenkorbwert mal die Stunden, bis der Fehler auffällt. Weil manche Kunden später zurückkommen, ist das Ergebnis eher eine Obergrenze für den direkten Verlust. Monitoring setzt am letzten Faktor an, der Zeit bis zur Entdeckung.
Die vier Ebenen des WooCommerce Monitorings
Gutes Shop-Monitoring ist kein einzelnes Tool, sondern ein Schichtsystem. Jede Ebene überwacht einen anderen Bereich deines Shops und liefert andere Signale. Wer nur eine Schicht abdeckt, hat blinde Flecken.
Ebene 1: Erreichbarkeit
Ein Uptime-Monitor ruft deine Seite in festen Abständen von außen auf und schlägt Alarm, wenn sie nicht antwortet oder einen Fehlercode liefert. Das ist die einfachste Schicht, und sie hat eine klare Grenze, denn ein solcher Monitor sieht nur, ob eine Seite lädt, nicht ob ein Kauf durchgeht. Anbieter dafür gibt es viele, Tarife und Prüfintervalle ändern sich, deshalb lohnt vor der Wahl der Blick auf die aktuellen Angaben des Anbieters.
Ebene 2: Performance
Ein Shop, der zwar online ist, aber spürbar langsam lädt, verliert ebenfalls Käufer. Die Core Web Vitals messen drei Seiten davon: wie schnell das größte sichtbare Element erscheint (Largest Contentful Paint, LCP), wie schnell die Seite auf Klicks, Tippen und Tastatur reagiert (Interaction to Next Paint, INP) und wie stark sich Inhalte unerwartet verschieben (Cumulative Layout Shift, CLS). Für INP gilt laut der Search-Console-Hilfe von Google ein Wert bis 200 Millisekunden als gut, bis 500 Millisekunden als verbesserungswürdig und darüber als schlecht. Für das Monitoring ist entscheidend, wie der Core-Web-Vitals-Bericht der Search Console arbeitet. Laut Google beruht er auf Felddaten echter Besucher aus dem Chrome User Experience Report, fasst ähnliche Seiten zu URL-Gruppen zusammen und zeigt je Gruppe den Wert, den 75 Prozent der Seitenaufrufe in den letzten 28 Tagen erreicht oder unterschritten haben. Reichen die Daten einer Gruppe nicht, fasst die Search Console sie zu einer übergeordneten Gruppe für alle Adressen mit demselben Protokoll und Hostnamen zusammen, etwa alle Seiten unter https auf derselben Subdomain. Adressen unter http bilden dabei eine eigene Gruppe. Reichen auch dafür die Daten nicht, wird auch diese Gruppe nicht angezeigt. Google schreibt ausdrücklich, der Bericht sei nicht dafür gedacht, den Status einer bestimmten URL zu finden, sondern zeige die Leistung der Website als Ganzes. Als Frühwarnung direkt nach einem Update ist er damit zu träge. Eine einzelne Adresse wie deine Kassenseite prüfst du mit einem Live-Test in PageSpeed Insights oder Lighthouse.
Ebene 3: Transaktionen
Das ist die kritischste Ebene für WooCommerce. Hier geht es darum, ob der Checkout-Prozess tatsächlich funktioniert, nicht nur ob die Seite lädt. Synthetisches Monitoring spielt dazu einen Kauf automatisiert durch: Produkt in den Warenkorb, Kasse, Zahlung, Bestätigung. Solche Testkäufe gehören immer auf eine Testzahlungsart oder den Testmodus deines Zahlungsanbieters, sonst entstehen echte Bestellungen mit echten Zahlungen und echten Bestätigungsmails. Auch WooCommerce rät in seiner Update-Anleitung, Testbestellungen mit einer passenden Testzahlungsart aufzugeben.
Ebene 4: Fehlerprotokolle
WooCommerce bringt dafür ein eigenes Werkzeug mit. Laut WooCommerce-Dokumentation liegt es im WordPress-Admin unter WooCommerce > Status > Logs und zeichnet unter anderem PHP-Fatal-Errors auf. In der Liste der Protokolldateien findest du dafür eine Datei mit fatal-errors im Namen. Ein Eintrag enthält den Zeitpunkt, die Fehlermeldung, Datei und Zeile, in der der Fehler entstand, und einen Stacktrace. Serverfehler wie Zeitüberschreitungen erfasst dieses Log laut WooCommerce nicht. Für die weitere Fehlersuche nennt WooCommerce zusätzlich die PHP-Fehlerprotokolle am Server, etwa eine error.log im Hauptverzeichnis oder, bei aktiviertem Debugging in WordPress mit Speicherung in eine Datei, die debug.log im Ordner wp-content. Ein Protokoll hilft nur, wenn jemand es liest. Wer nicht regelmäßig hineinschaut, braucht einen Dienst, der Protokolle auswertet und bei kritischen Einträgen Alarm schlägt.
Die vier Ebenen im Vergleich
| Ebene | Was sie prüft | Was sie nicht sieht |
|---|---|---|
| Erreichbarkeit | Ob Shop und Kassenseite antworten | Ob ein Kauf durchgeht |
| Performance | Ladezeit, Reaktion und Stabilität aus Felddaten | Fehler, die erst heute entstanden sind |
| Transaktionen | Ob ein Testkauf bis zur Bestätigung durchläuft | Fehler außerhalb des getesteten Kaufpfads |
| Fehlerprotokolle | PHP-Fehler mit Datei, Zeile und Stacktrace | Serverfehler wie Zeitüberschreitungen im WooCommerce-Log |
Warum der Checkout der kritischste Punkt ist
Alle anderen Seiten deines Shops sind im Grunde Vorstufen. Der eigentliche Moment, in dem Umsatz entsteht oder verloren geht, ist der Checkout. Genau hier verdichten sich alle potenziellen Fehlerquellen: Plugin-Konflikte, Zahlungsanbindung, die Zuordnung des Warenkorbs zum jeweiligen Besucher, Steuerberechnung und E-Mail-Versand müssen gleichzeitig fehlerfrei funktionieren.
Was beim Checkout regelmäßig schiefläuft
- Das Zahlungsgateway meldet keine erfolgreiche Antwort zurück, etwa bei Stripe oder PayPal
- Ein Sicherheits-Plugin blockiert die Anfrage, mit der der Browser die Bestellung im Hintergrund abschickt
- Das SSL-Zertifikat ist abgelaufen oder fehlerhaft, und der Browser warnt vor der Seite
- Eine WooCommerce-Extension ist nach einem Update inkompatibel
- Der Dienst, über den dein Shop E-Mails verschickt (SMTP), ist für Bestellbestätigungen nicht konfiguriert oder abgelaufen
Besonders tückisch ist die inkompatible Extension: Der Shop sieht normal aus, und auffällig wird der Fehler erst, wenn die Bestellungen ausbleiben. Ein Monitor auf der Kassenseite bemerkt das nicht, denn die Seite lädt ja. Erst ein Testkauf oder ein Blick auf die eingehenden Bestellungen zeigt es. Vorbeugen lässt sich mit dem Wert „Tested up to WooCommerce version“, den WooCommerce in seiner Update-Anleitung als Hinweis auf Verträglichkeit nennt: Ist er bei einer Extension, einem Theme oder einem Zahlungsanbieter älter als die WooCommerce-Version, die du einspielen willst, suchst du vorher nach einem Update der Erweiterung, liest ihre Release Notes oder fragst beim Entwickler nach.
So richtest du ein einfaches Monitoring-Setup ein
Du brauchst keinen DevOps-Spezialisten, um ein solides Monitoring für deinen WooCommerce-Shop aufzusetzen. Ein Basis-Setup verbindet einen externen Monitor mit den Bordmitteln von WooCommerce und Google.
Schritt für Schritt zum Basis-Monitoring
- Uptime-Monitor einrichten: Lege bei einem Monitoring-Dienst deiner Wahl deinen Shop als HTTPS-Monitor an und lege fest, wohin die Meldung geht.
- Kassenseite separat überwachen: Ein zweiter Monitor auf deiner Checkout-Seite, etwa `/checkout/`, meldet, wenn sie nicht mit HTTP-Status 200 antwortet. Er zeigt, ob die Seite lädt, nicht ob eine Zahlung durchgeht.
- WooCommerce-Logging prüfen: Laut WooCommerce-Dokumentation schaltest du unter WooCommerce > Status > Logs > Settings mit der Option „Logger“ das Logging ein oder aus. Als Speicherort ist das Dateisystem voreingestellt, die Alternative Datenbank empfiehlt WooCommerce für Live-Shops nicht. Einträge werden standardmäßig nach 30 Tagen automatisch gelöscht, die Aufbewahrungsdauer lässt sich dort ändern.
- Search Console einrichten: Der Core-Web-Vitals-Bericht zeigt dir, wie sich Gruppen ähnlicher Seiten über die letzten 28 Tage entwickeln. Für die Kassenseite einzeln nimmst du PageSpeed Insights.
- Fehlerprotokolle an einen Alarm koppeln: Lies die fatal-errors-Datei regelmäßig oder lass sie von einem Dienst auswerten, der dich bei neuen Einträgen benachrichtigt.
- Alarmkanal festlegen: Entscheide bewusst, wohin Alarme gehen. Im allgemeinen Posteingang gehen sie leicht unter, ein eigener Chat-Kanal oder eine SMS fällt bei kritischen Meldungen eher auf.
Was einen guten Alarm ausmacht
Viele Monitoring-Systeme senden so viele Benachrichtigungen, dass man anfängt, sie zu ignorieren. Diese Alert Fatigue ist kaum besser als gar kein Monitoring: Der eine wichtige Alarm geht zwischen vielen unwichtigen unter. Ordne deshalb jeder Meldung eine Dringlichkeit zu:
- Shop oder Kassenseite nicht erreichbar: sofortiger Alarm über einen Kanal, den du wirklich siehst
- Testkauf schlägt fehl: sofortiger Alarm
- Neuer Eintrag im fatal-errors-Protokoll: zeitnahe Meldung
- Häufung kleinerer PHP-Warnungen: tägliche Zusammenfassung
- Verschlechterung der Core Web Vitals: regelmäßiger Blick in den Bericht, der ohnehin über 28 Tage mittelt
Warum Monitoring auch nach Updates Pflicht ist
Ein Shop, der gestern noch lief, kann nach einem Update an einer Stelle brechen, die niemand angefasst hat. WordPress, WooCommerce, Themes, Extensions und Zahlungsanbieter werden laufend aktualisiert, und laut WooCommerce hängt die Verträglichkeit oft am gesamten Satz aktiver Shop-Software, nicht an einem einzelnen Plugin.
Der Update-Ablauf nach WooCommerce
WooCommerce beschreibt in seiner Anleitung zum Update einen Ablauf, der Wartung und Kontrolle verbindet. Für die meisten Shops nennt die Anleitung einen monatlichen Rhythmus. Updates mit Sicherheitskorrekturen oder mit Fehlerbehebungen für Funktionen, auf die dein Shop angewiesen ist, sollen früher eingespielt werden.
- Vorher ein aktuelles Backup von Datenbank und wp-content-Ordner anlegen
- Das Update zuerst auf einer Staging-Umgebung einspielen, also einer Kopie deines Shops, in der du Updates testest, bevor Kunden betroffen sind. Dort Produktseiten, Warenkorb, Checkout, Zahlung, Versand, Steuern und Bestellmails testen, nie direkt im Live-Shop
- Den Live-Shop während des Updates in den Modus „Coming soon“ setzen, damit niemand bestellt, während Dateien und Datenbank geändert werden
- Erscheint danach ein Hinweis auf ein Datenbank-Update, ihn ausführen und den Fortschritt unter den geplanten Aktionen verfolgen
- Im Live-Shop Produktseiten und Warenkorb prüfen und eine Testbestellung mit einer passenden Testzahlungsart aufgeben, bevor „Coming soon“ wieder aus ist
- Im WordPress-Admin auf Update-Hinweise und fehlgeschlagene geplante Aktionen achten
- Läuft etwas nicht wie erwartet: Kasse geschlossen halten, bei Bedarf das Backup zurückspielen und den Fehler auf Staging suchen
In den Stunden nach dem Update lohnt zusätzlich der Blick ins fatal-errors-Protokoll und auf die eingehenden Bestellungen. Dieser Ablauf klingt nach Aufwand. Er ist aber deutlich weniger Aufwand als die Schadensbegrenzung nach einem mehrstündigen Checkout-Ausfall, mit Kundenkommunikation, entgangenem Umsatz und möglichem Reputationsschaden. Automatische Updates passen schlecht zu diesem Ablauf, denn sie laufen ohne Staging-Test, ohne frisches Backup und ohne Testbestellung direkt im Live-Shop. Für WooCommerce selbst, Zahlungsanbieter und Extensions, die am Checkout hängen, ist das kontrollierte, selbst ausgelöste Update die sicherere Variante.
Kurz zusammengefasst
WooCommerce Monitoring ist keine Frage der Betriebsgröße, sondern eine Frage des Risikobewusstseins. Jeder Shop, der Umsatz macht, kann durch unentdeckte Fehler Umsatz verlieren. Ein strukturiertes Monitoring-Setup verkürzt die Zeit, bis du davon erfährst. Die wichtigsten Punkte auf einen Blick:
- Stille Fehler im Checkout, in E-Mails oder bei Weiterleitungen bleiben ohne Monitoring oft lange unentdeckt
- Ein solides Setup kombiniert vier Ebenen: Erreichbarkeit, Performance, Transaktionen und Fehlerprotokolle
- WooCommerce protokolliert PHP-Fatal-Errors selbst unter WooCommerce > Status > Logs, Serverfehler wie Zeitüberschreitungen erfasst dieses Log nicht
- Der Core-Web-Vitals-Bericht der Search Console zeigt URL-Gruppen über 28 Tage, für eine einzelne Seite ist PageSpeed Insights das passende Werkzeug
- Testkäufe laufen nur mit einer Testzahlungsart
- Alert Fatigue vermeiden: Nur wirklich kritische Ereignisse lösen Sofort-Alarme aus
- Nach jedem Update gehören Testbestellung und Blick ins Fehlerprotokoll zur Routine
Worauf sich das stützt
Was du noch wissen solltest
WooCommerce Monitoring überwacht deinen Online-Shop auf technische Fehler wie Checkout-Probleme, Serverausfälle oder kaputte Weiterleitungen und meldet sie dir, statt darauf zu warten, dass ein Kunde es tut. Ein abgebrochener Kauf hinterlässt sonst meist keine Spur, die du ohne Suche findest.
Am verlässlichsten mit mehreren Ebenen: ein Monitor für die Erreichbarkeit von Shop und Kassenseite, ein Testkauf mit Testzahlungsart und ein regelmäßiger Blick in die Fehlerprotokolle. WooCommerce zeichnet PHP-Fatal-Errors laut eigener Dokumentation selbst auf, zu finden unter WooCommerce > Status > Logs in einer Datei mit fatal-errors im Namen.
Gefährlich sind vor allem Fehler, bei denen der Shop normal aussieht: ein Checkout, der nach einem Plugin-Update nicht mehr abschließt, ein ausgefallener Zahlungsanbieter oder Bestellbestätigungen, die nie ankommen. Ein Monitor, der nur prüft, ob die Seite lädt, bemerkt keinen davon.
Das hängt von deinem Shop ab und lässt sich selbst überschlagen: durchschnittliche Bestellungen pro Stunde mal durchschnittlicher Warenkorbwert mal die Stunden bis zur Entdeckung. Weil manche Kunden später zurückkommen, ist das eher eine Obergrenze für den direkten Verlust. Monitoring verkürzt den letzten Faktor.
WooCommerce hat ein eigenes Logging unter WooCommerce > Status > Logs, das unter anderem PHP-Fatal-Errors mit Zeitpunkt, Datei, Zeile und Stacktrace festhält. Laut WooCommerce werden Einträge standardmäßig 30 Tage aufbewahrt. Serverfehler wie Zeitüberschreitungen erfasst dieses Log nicht. Für die weitere Fehlersuche nennt die Dokumentation zusätzlich die PHP-Fehlerprotokolle am Server, etwa error.log oder debug.log.
Nur bedingt. Laut Google fasst der Core-Web-Vitals-Bericht ähnliche Seiten zu URL-Gruppen zusammen und zeigt Werte aus Felddaten der letzten 28 Tage. Er ist nicht dafür gedacht, den Status einer bestimmten URL zu finden. Für eine einzelne Seite nennt Google einen Live-Test mit PageSpeed Insights oder Lighthouse.
WooCommerce nennt in seiner Update-Anleitung einen monatlichen Rhythmus als passend für die meisten Shops. Updates mit Sicherheitskorrekturen oder mit Fehlerbehebungen für Funktionen, auf die dein Shop angewiesen ist, gehören früher eingespielt, vorher mit Backup und einem Test auf einer Staging-Umgebung, also einer Kopie deines Shops.
Nein, gutes WooCommerce Monitoring funktioniert als Schichtsystem aus mehreren Ebenen, die Erreichbarkeit, Performance, Fehlerprotokolle und den Checkout-Prozess abdecken. Wer nur ein Tool einsetzt, hat blinde Flecken: Ein Uptime-Monitor sieht etwa nicht, ob ein Kauf tatsächlich durchgeht.
