WordPress-Monitoring vom Plugin-Update bis zum WP-Cron
XICTRAQ überwacht Erreichbarkeit, Unterseiten, WP-Cron, offen liegende Dateien und eingebundene Skripte Ihrer WordPress-Website und erkennt den Wartungsmodus bei Updates als geplante Pause statt als Ausfall. Der cookielose Tracker erfasst Seitenaufrufe, JavaScript-Fehler und die Suchbegriffe der WordPress-Suche.
Diese Pfade zuerst prüfen
- Uptime-MonitoringStartseite mit Wartungserkennung
/ - Uptime-MonitoringAnmeldeseite als eigene Unterseite
/wp-login.php - API-MonitoringREST-API: Status und JSON-Antwort
/wp-json/ - HeartbeatsPer Server-Cron auslösen, danach pingen
/wp-cron.php - Security-ScanOffen lesbares Fehlerprotokoll
/wp-content/debug.log
Warum ein Check der Startseite bei WordPress nicht reicht
Eine WordPress-Website besteht aus dem Kern, einem Theme und meist mehreren Plugins, die sich einzeln aktualisieren lassen. Löst ein Update einen schweren PHP-Fehler aus, antwortet WordPress mit seiner Meldung über einen kritischen Fehler und HTTP 500. Geplante Aufgaben laufen über WP-Cron, das nur bei Seitenaufrufen prüft, ob etwas fällig ist. Und ein Seiten-Cache kann die Startseite weiter ausliefern, während PHP oder Datenbank ausgefallen sind.
XICTRAQ verteilt die Prüfung deshalb auf mehrere Module: Uptime-Monitoring mit Unterseiten und Wartungserkennung, Heartbeats für WP-Cron, den Security-Scan für offen liegende Dateien, den visuellen Changelog mit Defacement-Erkennung für eingeschleuste Skripte und die Skript-Integrität für eingebundene externe Skripte. Für die REST-API unter /wp-json/ eignet sich ein API-Check, der Status und JSON-Antwort prüft.
Was XICTRAQ nicht übernimmt: Es gleicht die Versionen von WordPress, Plugins und Themes nicht mit bekannten Schwachstellen ab, und Skripte von Ihrer eigenen Domain, also auch die Dateien lokal installierter Plugins und Themes, gehören nicht zur Skript-Integrität. Den Stand der Updates prüfen Sie weiter im WordPress-Adminbereich.
Verlegt ein Sicherheits-Plugin die Anmeldeadresse, überwachen Sie die neue Adresse statt /wp-login.php. Ein API-Check auf /wp-json/ kennt keine Wartungserkennung: Antwortet WordPress dort während eines Updates mit 503, wertet der Check das als Fehlschlag.
Was auf WordPress-Websites typischerweise bricht
Kritischer Fehler nach einem 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. Bleibt die Antwort bei 200 und fehlt nur ein Teil der Seite, meldet ein Schlüsselwort-Check auf der überwachten Adresse das fehlende Wort, und der Tracker meldet JavaScript-Fehler aus echten Besuchen mit Meldung, Datei und Zeile.
Datenbank weg, Cache antwortet weiter
Ist die Datenbank nicht erreichbar, antwortet WordPress in der Grundeinstellung mit einer Meldung zum Datenbankfehler und HTTP 500. Liefert ein Seiten-Cache die Startseite als gespeicherte Kopie aus, kann sie trotzdem weiter mit HTTP 200 antworten. Das Uptime-Monitoring ruft hinterlegte Unterseiten direkt auf und löst für eine nicht erreichbare Unterseite einen eigenen Alarm aus. Wählen Sie dafür eine Seite, die Ihr Seiten-Cache nicht zwischenspeichert; wie viele Unterseiten möglich sind, hängt vom Tarif ab.
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 eigene Wartungsseite unter wp-content/maintenance.php zählt nur als Wartung, wenn sie mit HTTP 503 antwortet und einen Hinweis wie „Wartungsarbeiten“ oder „undergoing maintenance“ trägt. Eine Plugin-Wartungsseite mit HTTP 200 bleibt für das Monitoring eine normale Seite.
WP-Cron bleibt bei wenig Besuch liegen
WP-Cron prüft bei jedem Seitenaufruf, ob geplante Aufgaben fällig sind. Bleiben Aufrufe aus, können sich Aufgaben wie das Veröffentlichen geplanter Beiträge verzögern. Schalten Sie WP-Cron per DISABLE_WP_CRON ab, lösen Sie es ü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.
Eingeschleuste fremde Skripte
Ein kompromittiertes Plugin oder Theme kann fremde Skripte in die Seite einbauen, ohne dass sich die Erreichbarkeit ändert. Mit eingeschalteter Defacement-Erkennung lernt XICTRAQ in den ersten drei Läufen die externen Skript-Hosts der Seite. Kommt danach ein neuer hinzu, fließt er mit Quelltext- und Screenshot-Änderungen in eine Bewertung, ab der Alarmschwelle meldet XICTRAQ ein mögliches Defacement samt den fremden Hosts. Die Skript-Integrität meldet bei verifizierten Websites zusätzlich, wenn sich ein bereits erfasstes externes Skript ändert. Beide Prüfungen hängen vom Tarif ab, und Schadcode von der eigenen Domain oder als Inline-Skript gilt für beide nicht als fremder Skript-Host.
Fehlerprotokoll oder Konfigurationskopie offen lesbar
Sind WP_DEBUG und WP_DEBUG_LOG eingeschaltet, schreibt WordPress Fehler in der Regel 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 WordPress erkennt
Die Technikerkennung liest HTML und Antwortköpfe der überwachten Seite, 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. Tragen die Seiten zusätzlich die Kennungen woocommerce oder wc-blocks, gilt die Website als WooCommerce-Shop, mehr dazu auf der Seite zu WooCommerce.
- Wartung erkennt XICTRAQ an einer 503-Antwort mit Wartungshinweis, etwa dem WordPress-Hinweis auf planmäßige Wartung auf Englisch oder Deutsch, einem Wartungshinweis im Seitentitel oder einer Adresse mit /maintenance im Pfad. Ein 503 ohne solchen Hinweis und ohne erkennbare Bot-Abwehr bleibt eine Störung.
- Im Security-Scan weist XICTRAQ bei WordPress zusätzlich einen erkannten Page-Builder wie Elementor oder Divi und ein erkanntes SEO-Plugin aus.
- XICTRAQ gleicht die WordPress-Version nicht mit bekannten Schwachstellen ab, auch nicht die Versionen von Plugins und Themes. Kommt statt der Seite eine Fehlerseite oder eine Bot-Abwehr zurück, bewertet XICTRAQ das CMS in diesem Lauf nicht und leitet daraus keinen Systemwechsel ab.
Was der Tracker in WordPress erfasst
Der Tracker braucht für WordPress keine eigene Erkennung: Er erfasst auf jeder Seite, die das Skript lädt, Aufrufe, Fehler und Interaktionen. Speziell auf WordPress zugeschnitten sind die Zuordnung angemeldeter Nutzer über die Klassen am body und die Auswertung der WordPress-Suche. 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 Web Vitals wie LCP, CLS und INP.
- JavaScript-Fehler mit Meldung, Datei, Zeile und Stacktrace sowie nicht abgefangene Promise-Ablehnungen, etwa wenn ein aktualisiertes Plugin ein Skript bricht.
- Suchbegriffe der WordPress-Suche: Das Standard-Suchformular übergibt den Begriff im Parameter s, XICTRAQ zeigt ihn im Bericht zu den Suchbegriffen.
- Formularinteraktionen, sofern Ihr Tarif Formular-Analysen enthält: erster Kontakt, Fokus und Verlassen je Feld mit Eingabelänge und Verweildauer, Validierungsfehler des Browsers und das Absenden. Formulare ohne id und name, etwa von Contact Form 7, unterscheidet XICTRAQ an der action-Adresse samt Anker.
- Klicks auf externe Links und auf Downloads der eigenen Domain wie PDF oder ZIP, etwa aus der Mediathek, dazu Klicks auf Elemente mit dem Attribut data-xictraq-event.
- Angemeldete Nutzer, sofern Ihr Tarif die Nutzerzuordnung enthält und das Theme oder ein Plugin am body neben logged-in eine Klasse nach dem Muster user-id-Nummer setzt.
Nicht automatisch erfasst
- Ob das Formular-Plugin die Nachricht tatsächlich versendet hat: Der Tracker sieht das Absenden im Browser, nicht die Verarbeitung auf dem Server.
- Validierungsfehler, die ein Formular-Plugin erst auf dem Server feststellt.
- Feldinhalte: Von Eingaben erfasst der Tracker nur die Länge, nicht den Text.
- Angemeldete Nutzer ohne Kennung: WordPress selbst setzt für sie am body die Klasse logged-in, aber keine Nutzernummer.
- Aktionen im Adminbereich wie Veröffentlichen, Updates oder das Freigeben von Kommentaren. Dafür gibt es kein automatisches Ereignis.
- Suchbegriffe, die nicht als Abfrageparameter in der Adresse stehen, etwa wenn ein Theme oder Plugin auf eine Adresse wie /search/begriff/ umleitet.
Fehlendes übergeben Sie über die JavaScript-API: xictraq.event(name, eigenschaften) für eigene Ereignisse und xictraq.identify(nutzerId, merkmale) für angemeldete Nutzer. Alternativ setzen Sie window.xictraqUser mit id, type, group, name und company oder das Meta-Tag xictraq:user-id, beides liest der Tracker selbst aus.
Die passenden Module für WordPress
Häufige Fragen
Wie binde ich den XICTRAQ-Tracker in WordPress 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 erfasst der Tracker Seitenaufrufe, JavaScript-Fehler und die Suchbegriffe der WordPress-Suche ohne weitere Einstellung.
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.
Wie überwache ich WP-Cron 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. Der Ping belegt den Lauf selbst, nicht, ob jede einzelne Aufgabe darin gelingt.
Bemerkt XICTRAQ, wenn meine WordPress-Website gehackt wurde?
Teilweise. Mit eingeschalteter Defacement-Erkennung meldet XICTRAQ nach einer Lernphase neue externe Skript-Hosts zusammen mit Quelltext- und Screenshot-Änderungen als mögliches Defacement, die Skript-Integrität meldet geänderte externe Skripte, und der Security-Scan listet offen lesbare Dateien wie debug.log. Schadcode aus Dateien der eigenen Domain, der die Seite nicht sichtbar verändert, fällt diesen Prüfungen in der Regel nicht auf.
Prüft XICTRAQ, ob WordPress, Plugins und Themes aktuell sind?
Nein. Die Technikerkennung erkennt WordPress, gleicht aber weder die WordPress-Version noch Plugins und Themes mit bekannten Schwachstellen ab. Den Stand der Updates prüfen Sie im WordPress-Adminbereich. XICTRAQ meldet die Folgen, die ein Update sichtbar macht, etwa einen kritischen Fehler auf der Startseite oder eine Unterseite, die nicht mehr antwortet.
Erfasst XICTRAQ angemeldete Nutzer und die WordPress-Suche?
Die Suche ja: Das Standard-Suchformular übergibt den Begriff im Parameter s, XICTRAQ zeigt ihn im Bericht zu den Suchbegriffen. Angemeldete Nutzer ordnet der Tracker zu, wenn am body neben logged-in eine Klasse nach dem Muster user-id-Nummer steht, die WordPress selbst nicht setzt, oder wenn Sie window.xictraqUser, das Meta-Tag xictraq:user-id oder xictraq.identify() verwenden. Die Nutzerzuordnung setzt einen Tarif voraus, der sie enthält.