WordPress-Website überwachen: Keyword, Login, wp-cron

Warum reicht ein Check der Startseite bei WordPress nicht?

WordPress ist ein Zusammenspiel aus Webserver, PHP, Datenbank, Theme, Plugins und meist einem Cache. Fällt eine dieser Schichten aus, entsteht nicht automatisch ein sauberer Fehlercode. Typische Situationen aus dem Betrieb:

• Seitencache liefert, Anwendung ist defekt: Ein Cache-Plugin oder ein vorgeschalteter Cache beantwortet die Startseite weiter mit „200 OK“, obwohl die Datenbank nicht mehr antwortet. Besucher sehen noch Inhalte; Warenkorb, Suche, Kommentare und Login funktionieren nicht.
• Fehlertext statt Fehlercode: Je nach Version, Konfiguration und Plugin wird eine Meldung wie „Es ist ein kritischer Fehler auf Ihrer Website aufgetreten“ oder „Error establishing a database connection“ ausgegeben. Der Statuscode ist dann häufig 500, kann aber durch Cache, Proxy oder Fehlerseiten-Plugins ein anderer sein.
• Leere Seite (White Screen): Ein PHP-Fehler bei abgeschalteter Fehleranzeige liefert einen leeren Body. Der Statuscode kann 200 oder 500 sein, der Inhalt fehlt in jedem Fall.
• Hängengebliebener Wartungsmodus: Während Updates legt WordPress eine Datei .maintenance an und antwortet mit Status 503 („Wegen geplanter Wartungsarbeiten ist diese Website kurzzeitig nicht verfügbar“). Bricht ein Update ab, bleibt die Datei liegen, und die Website bleibt im Wartungsmodus, bis jemand sie löscht.

Ein HTTP-Monitor, der nur den Statuscode der Startseite prüft, erkennt davon bestenfalls den 503. Einführung und Abgrenzung der Prüfarten finden Sie unter Monitortypen; zur Bedeutung der Codes siehe HTTP-Statuscodes erklärt.

Welche Monitore gehören zu einer WordPress-Website?

Die folgende Zusammenstellung deckt die häufigsten Fehlerbilder ab. Sie passt in ein kostenloses Solo-Konto (bis zu 10 Monitore), sodass für eine einzelne Website noch Platz für weitere Projekte bleibt.

Optional ergänzen Sie einen API/JSON-Monitor auf /wp-json/: Die Antwort ist ein JSON-Dokument, in dem sich ein Feld wie name auf Vorhandensein prüfen lässt. Das zeigt, dass die REST-API erreichbar ist, auf die Block-Editor, mobile Apps und viele Plugins angewiesen sind. Deaktivieren Sie die REST-API per Plugin oder Firewall, schlägt dieser Monitor erwartungsgemäß fehl; legen Sie ihn dann nicht an.

Wie wählt man einen guten Keyword für den Footer?

Ein Keyword-Monitor ruft die Seite ab und sucht im ausgelieferten HTML nach einem Text. UPTIMESHIELD liest dafür die ersten 256 KB der Antwort. Für WordPress gilt:

• Stabil: Nehmen Sie einen Text, der sich praktisch nie ändert, etwa Firmenname plus „Impressum“ im Footer. Vermeiden Sie Jahreszahlen („© 2026“), Aktionstexte, Zähler und alles, was ein Redakteur bearbeitet.
• Weit unten: Ein Text im Footer steht erst, nachdem Header, Navigation und Inhalt gerendert wurden. Bricht PHP mittendrin ab, fehlt er. Ein Text im <title> steht dagegen ganz oben und überlebt viele Abbrüche.
• Im HTML, nicht per JavaScript: Texte, die erst im Browser per JavaScript entstehen, sind in der Antwort nicht enthalten.
• Innerhalb der ersten 256 KB: Sehr lange Seiten mit großem Inline-CSS oder Page-Builder-Ballast schieben den Footer womöglich hinter diese Grenze. Prüfen Sie das einmal mit curl -s https://www.example.com/ | head -c 262144 | grep -c "Impressum"; bei Ergebnis 0 wählen Sie eine schlankere Seite oder einen Text weiter oben.

Für den zweiten Monitor vom Typ „darf nicht enthalten sein“ wählen Sie Meldungen, die WordPress bei Fehlern ausgibt, zum Beispiel kritischer Fehler oder Error establishing a database connection. Die Groß- und Kleinschreibung wird standardmäßig nicht unterschieden.

Wie prüft man die Datenbank, ohne dass der Cache sie verdeckt?

Eine Seite aus dem Seitencache kommt ohne Datenbankzugriff aus. Damit der Monitor die Anwendung und nicht den Cache testet, brauchen Sie einen Endpunkt, der nie gecacht wird und eine einfache Abfrage ausführt. Das gelingt mit einem kleinen „Must-Use“-Plugin, das Sie als Datei in wp-content/mu-plugins/health-check.php ablegen:

<?php
// wp-content/mu-plugins/health-check.php
add_action('init', function () {
    $path = parse_url($_SERVER['REQUEST_URI'] ?? '', PHP_URL_PATH);
    if ($path !== '/health-4f9c2a/') {
        return;
    }
    global $wpdb;
    nocache_headers();
    header('Content-Type: text/plain; charset=utf-8');
    if ((string) $wpdb->get_var('SELECT 1') === '1') {
        status_header(200);
        echo 'wp-ok';
    } else {
        status_header(503);
        echo 'db-error';
    }
    exit;
});

Der Pfad mit Zufallsanteil verhindert, dass der Endpunkt erraten wird; er verrät nur „ok“ oder „Fehler“, keine Versionen oder Zugangsdaten. Legen Sie dann einen Keyword-Monitor auf https://www.example.com/health-4f9c2a/ mit dem Suchbegriff wp-ok an. Manche Cache-Lösungen respektieren die Cache-Control-Header von nocache_headers() nicht von selbst; schließen Sie den Pfad in diesem Fall in den Einstellungen des Cache-Plugins oder Ihres Servers vom Caching aus. Hintergründe dazu im Ratgeber Cache-Control richtig setzen.

Wie richtet man den Heartbeat für wp-cron ein?

WordPress plant Aufgaben wie zeitgesteuerte Veröffentlichungen, Updates, Papierkorb-Bereinigung und die Aufgaben vieler Plugins (Backups, Newsletter, Sitemaps, Shop-Synchronisation) über „wp-cron“. Dieser Mechanismus ist kein echter Cron: Er wird bei Seitenaufrufen angestoßen. Hat eine Seite nachts wenig Besucher, laufen fällige Aufgaben verspätet; ist der Cache so aggressiv, dass kaum ein Aufruf bis zu PHP durchkommt, noch später. Ein verpasster Termin fällt dann erst auf, wenn jemand den Beitrag vermisst. Das offizielle Plugin-Handbuch zu Cron beschreibt den Mechanismus.

Die robuste Lösung besteht aus zwei Schritten. Erstens schalten Sie den Seitenaufruf-Trigger ab, in der wp-config.php:

define('DISABLE_WP_CRON', true);

Zweitens rufen Sie wp-cron von einem echten Systemcron auf und melden den Erfolg per Ping. Legen Sie in UPTIMESHIELD einen Heartbeat-Monitor mit Intervall 15 Minuten an und tragen Sie in der Crontab ein:

*/5 * * * * cd /var/www/html && /usr/bin/php wp-cron.php && curl -fsS -m 10 --retry 2 https://uptimeshield.de/ping/IHR_TOKEN/ > /dev/null

Alternativ mit WP-CLI, das die fälligen Ereignisse direkt ausführt und bei Fehlern einen Rückgabewert ungleich null liefert: cd /var/www/html && wp cron event run --due-now && curl -fsS -m 10 …. Das && sorgt dafür, dass der Ping nur nach erfolgreichem Lauf folgt. Die tatsächliche Ping-URL mit Ihrem Token zeigt der Monitor an; mehr zum Prinzip im Ratgeber Cronjobs mit Heartbeat überwachen.

Wie schützt man Updates vor Fehlalarmen?

Nach Core-, Theme- und Plugin-Updates ist die Wahrscheinlichkeit für Fehler am höchsten. Wer Updates von Hand einspielt, sollte vorher ein Wartungsfenster für die betroffenen Monitore setzen: Während des Fensters gibt es keinen Alarm, die Zeit zählt nicht in die Verfügbarkeit, und der Status lautet „Wartung“. Planen Sie das Fenster knapp (Dauer des Updates plus Puffer). Danach lohnt ein gezielter Blick auf Antwortzeit und Fehler: Steigt der Median nach einem Update dauerhaft, hat das Update Last hinzugefügt, siehe Antwortzeit interpretieren.

Wenn Ihr Hoster oder ein Plugin automatische Updates durchführt, haben Sie kein festes Zeitfenster. Dann ist die Kombination aus Keyword-Monitor, Health-Endpunkt und Bestätigung nach zwei Fehlschlägen die bessere Absicherung: Ein Update, das die Seite für zwei Minuten in den Wartungsmodus versetzt, verursacht keinen Alarm; bleibt sie hängen, schon.

Welche Fehler treten bei der WordPress-Überwachung häufig auf?

• Security-Plugin oder WAF sperrt den Monitor. Plugins gegen Brute-Force-Angriffe sperren Adressen, die /wp-login.php in kurzen Abständen aufrufen. Symptom: Der Login-Monitor meldet sporadisch 403 oder 429, die Website selbst läuft. Gegenmaßnahme: Den User-Agent UPTIMESHIELD-Monitor in der Firewall freigeben oder die Login-Prüfung weglassen, wenn sie keinen Mehrwert bringt.
• Geänderte Login-URL. Verschieben Plugins die Anmeldeseite, liefert /wp-login.php 404. Überwachen Sie dann die tatsächlich genutzte Adresse.
• Keyword ändert sich unbemerkt. Ein Theme-Wechsel oder ein überarbeiteter Footer lässt den Monitor fehlschlagen. Das ist keine Störung, aber ein Anlass, den Text zu prüfen und anzupassen.
• Nur eine Seite überwacht. Ein Shop, dessen Startseite läuft, kann an Warenkorb oder Kasse scheitern. Legen Sie für die geschäftskritische Seite einen eigenen Monitor an, mehr dazu in Onlineshop überwachen.
• wp-cron deaktiviert, kein Systemcron eingerichtet. Wer DISABLE_WP_CRON setzt und den Systemcron vergisst, hat gar keine geplanten Aufgaben mehr. Der Heartbeat-Monitor meldet das, weil der Ping ausbleibt.
• Cron-Umgebung anders als Shell. Im Cron fehlen oft PATH und Umgebungsvariablen. Verwenden Sie absolute Pfade (/usr/bin/php) und testen Sie den Befehl einmal als der Benutzer, unter dem der Cron läuft.

Checkliste: WordPress-Monitoring in 15 Minuten

1. HTTP-Monitor auf die Startseite anlegen, Intervall 5 Minuten.
2. Keyword-Monitor („muss enthalten sein“) mit stabilem Footer-Text anlegen.
3. Keyword-Monitor („darf nicht enthalten sein“) für „kritischer Fehler“ anlegen.
4. Health-Endpunkt als mu-Plugin einrichten und per Keyword wp-ok überwachen.
5. SSL-Monitor für die Domain anlegen, siehe SSL-Zertifikate rechtzeitig überwachen.
6. DISABLE_WP_CRON setzen, Systemcron mit Heartbeat-Ping einrichten.
7. Alarmkanäle einrichten und mit dem Testversand prüfen, siehe Benachrichtigungen richtig einrichten.
8. Vor manuellen Updates ein Wartungsfenster setzen.

Grenzen und Einordnung

Monitoring von außen prüft das ausgelieferte Ergebnis, nicht den Zustand der Installation. Es erkennt nicht, ob ein Plugin veraltet oder verwundbar ist, ob die Website gehackt wurde, solange sie normal antwortet, oder ob Backups wiederherstellbar sind. Der Heartbeat belegt nur, dass der Systemcron bis zur Ping-Zeile kam, nicht, dass jede einzelne WordPress-Aufgabe erfolgreich war. Der Login-Monitor ruft die Seite ab; ob die Anmeldung mit Zugangsdaten funktioniert, wird nicht getestet. Und ein Keyword im Footer beweist nicht, dass Bestellungen, Formulare oder Zahlungen funktionieren. Mehr dazu in Grenzen automatischer Website-Prüfungen.

Wie setzt man das mit UPTIMESHIELD um?

Registrieren Sie sich kostenlos, denn Monitore gibt es nur mit Konto; die einmalige Einzelprüfung im Uptime Checker funktioniert ohne. Im Dashboard legen Sie die Monitore aus der Tabelle an, vergeben ein Tag wie „wordpress“ und aktivieren mindestens einen Alarmkanal. Das kostenlose Solo-Konto bietet zehn Monitore im 5-Minuten-Intervall; Pro erlaubt Intervalle ab einer Minute, siehe Preise. Zusätzlich lohnt der Sofort-Report: Er prüft einmalig Antwortzeit, Weiterleitungen, Security-Header, robots.txt, Sitemap und DNS-Einträge und nennt Maßnahmen. Wiederkehrende Website-Checks im Dashboard zeigen den Notenverlauf, etwa nach einem Plugin-Update. Alle Prüfungen tragen den User-Agent UPTIMESHIELD-Monitor, den Sie in Firewalls freigeben können.