Website-Zustand in WordPress richtig auswerten: Meldungen verstehen und beheben

WordPress prüft seit Version 5.2 selbst, ob die Umgebung einer Website in Ordnung ist. Das Werkzeug heißt im deutschen Backend „Website-Zustand“ und steht unter Werkzeuge. Viele Betreiber öffnen es nur, wenn das Dashboard eine Warnung zeigt, und wissen dann nicht, welche Meldung dringend ist und welche sie getrost ignorieren können. Diese Anleitung erklärt, wie die Tests arbeiten, wie Sie „kritisch“ von „empfohlen“ unterscheiden, welche Meldungen auf echte Probleme hinweisen und wie Sie den Bericht für Ihren Dienstleister exportieren, ohne Zugangsdaten preiszugeben. Alle Meldungen stammen aus einer Laborinstanz mit WordPress 7.1.2.

Voraussetzungen

• WordPress: Version 5.2 oder neuer, getestet mit WordPress 7.1.2 in deutscher Sprache.
• PHP: die von WordPress unterstützten Versionen. Die offizielle Versionsschnittstelle nennt PHP 7.4 als Mindestempfehlung, im Labor lief PHP 8.4.
• Zugriff: Rolle Administrator im Backend. Der Website-Zustand ist nur für Benutzer mit der Berechtigung view_site_health_checks sichtbar, die Administratoren standardmäßig haben.
• Optional: SSH mit WP-CLI für die Auswertung auf der Kommandozeile und SFTP für wp-config-Änderungen.
• Backup: eine aktuelle Sicherung, bevor Sie aufgrund einer Meldung Plugins entfernen oder die wp-config.php ändern.

Schritt 1: Den Website-Zustand aufrufen und lesen

Öffnen Sie Werkzeuge > Website-Zustand. WordPress startet dann eine Reihe von Tests. Ein Teil läuft direkt beim Laden der Seite, ein anderer Teil asynchron im Hintergrund, etwa die Prüfung der Verbindung zu WordPress.org oder der Loopback-Anfrage an die eigene Website. Warten Sie deshalb, bis die Seite vollständig geladen hat, bevor Sie das Ergebnis bewerten.

Oben steht eine Gesamtbewertung, „Gut“ oder „Verbesserungswürdig“. Darunter gruppiert WordPress die Ergebnisse in drei Stufen:

Stufe	Bedeutung	Handlungsbedarf
kritische Probleme	Funktionen oder Sicherheit sind beeinträchtigt	zeitnah beheben
empfohlene Verbesserungen	Betrieb läuft, aber nicht optimal	prüfen und bewerten
Bestandene Tests	alles in Ordnung	keiner

Jede Meldung trägt zusätzlich ein Etikett wie „Sicherheit“ oder „Leistung“. Klappen Sie eine Meldung auf, erklärt WordPress die Ursache und verlinkt oft direkt auf die passende Einstellungsseite.

Im Labor lieferte eine frische Installation ohne Anpassungen 20 bestandene Tests, 4 Empfehlungen und 1 kritisches Problem. Dieses Zählergebnis speichert WordPress als Transient, das Dashboard-Widget „Website-Zustand“ zeigt es an. Per WP-CLI lesen Sie es so aus:

wp transient get health-check-site-status-result

{"good":20,"recommended":4,"critical":1}

Der Wert wird aktualisiert, wenn Sie die Seite im Backend öffnen, sowie einmal täglich durch das geplante Ereignis wp_site_health_scheduled_check.

Verifizieren: Sie sehen die Gesamtbewertung und die Anzahl der Meldungen je Stufe. Die Zahl im Dashboard-Widget stimmt mit der Seite überein.

Schritt 2: Kritische Meldungen richtig einordnen

Kritische Meldungen sind selten, aber ernst. Im Labor traten drei Arten auf. Die Überschriften sind sinngemäß wiedergegeben, weil die deutsche Oberfläche an einigen Stellen vertraulich formuliert. Suchen Sie nach den Stichworten in der jeweiligen Überschrift.

„Bei der REST-API ist ein Fehler aufgetreten“: Der Block-Editor lädt und speichert Inhalte über die REST-API. Schlägt der Test fehl, können Redakteure oft nicht mehr speichern. Im Labor lautete die Detailmeldung:

REST-API-Antwort: (http_request_failed) cURL error 7: Failed to connect to 127.0.0.1:21248 after 0 ms: Could not connect to server

Loopback-Anfrage nicht abgeschlossen: WordPress ruft sich für geplante Aufgaben (WP-Cron) und für die Prüfung von Code-Änderungen im Theme- und Plugin-Editor selbst auf. Scheitert das, laufen zeitgesteuerte Beiträge, automatische Updates und Aufräumarbeiten nicht mehr zuverlässig. Die Fehlermeldung enthielt denselben cURL-Fehler.

Beide Meldungen haben im Labor dieselbe Ursache: Der Server erreicht seine eigene öffentliche Adresse nicht. Das passiert in der Praxis bei Firewalls, die ausgehende Verbindungen zum eigenen Server blockieren, bei falschen DNS-Einträgen auf dem Server, hinter manchen Reverse Proxys oder wenn ein Sicherheits-Plugin Anfragen ohne Browserkennung abweist. Testen Sie auf dem Server:

curl -sI "https://ihre-domain.de/index.php?rest_route=/"

Erwartet wird HTTP/1.1 200 oder HTTP/2 200. Liefert der Befehl auf dem Server einen Fehler, im Browser aber nicht, liegt das Problem in der Netzwerkkonfiguration des Servers. Das klären Sie mit Ihrem Hoster.

Website zeigt Besuchern Fehler an: Im Labor mit WP_DEBUG, WP_DEBUG_DISPLAY und WP_DEBUG_LOG auf true erschien diese Meldung mit dem Hinweis, dass die Protokolldatei „möglicherweise für alle Benutzer verfügbar ist“. Auf einer Live-Website schalten Sie die Anzeige ab. Wie Sie das sauber lösen, beschreibt wp-config.php härten.

Verifizieren: Nach der Korrektur rufen Sie Werkzeuge > Website-Zustand erneut auf. Die Meldung ist in die „Bestandene Tests“ gewandert, die Zahl der kritischen Probleme ist gesunken.

Schritt 3: Empfohlene Verbesserungen bewerten

Empfehlungen sind Hinweise, keine Fehler. Sie verdienen einen Blick, aber nicht jede passt zu jeder Website. Die im Labor aufgetretenen Meldungen und ihre Einordnung:

• „Inaktive Plugins sollten entfernt werden“ und „Inaktive Themes sollten entfernt werden“: WordPress begründet das so: „Inaktive Plugins sind verlockende Ziele für Angreifer.“ Deaktivierter Code liegt weiter auf dem Server und kann Lücken enthalten. Löschen Sie, was Sie nicht brauchen. Ein Standard-Theme als Rückfalloption dürfen Sie behalten.
• „Ein geplantes Ereignis ist überfällig“: Im Labor betraf das recovery_mode_clean_expired_keys. Einzelne überfällige Ereignisse auf wenig besuchten Seiten sind normal, da WP-Cron nur bei Seitenaufrufen startet. Sind viele Ereignisse dauerhaft überfällig, prüfen Sie die Loopback-Anfrage aus Schritt 2.
• „Der Opcode-Cache ist nicht aktiviert“: OPcache hält vorkompilierten PHP-Code im Arbeitsspeicher. Das ist eine Einstellung des Servers, bei Webhosting oft über das Kundenmenü zu aktivieren. Hinweise gibt PHP-OPcache und PHP-Einstellungen für WordPress optimieren.
• Website verwendet kein HTTPS: Auf einer öffentlichen Website ein Pflichtpunkt, in einer lokalen Testumgebung normal.
• „Der Autorisierungs-Header fehlt“: Relevant, wenn Sie Anwendungspasswörter für externe Werkzeuge nutzen. Der Server reicht den Header dann nicht an PHP weiter.
• „Das Vorhandensein eines Seiten-Caches kann nicht erkannt werden“: WordPress sucht nach typischen Cache-Headern. Manche Hoster cachen auf eine Weise, die WordPress nicht erkennt. Wie Sie das selbst prüfen, steht in Page-Caching in WordPress einrichten.

Gehen Sie die Empfehlungen nach dem Etikett durch: Meldungen mit „Sicherheit“ zuerst, „Leistung“ danach. Bewerten Sie jede einmal bewusst und notieren Sie, warum Sie eine bestimmte Meldung akzeptieren. Dann erkennen Sie beim nächsten Blick neue Meldungen sofort.

Verifizieren: Zu jeder verbleibenden Empfehlung gibt es eine Notiz: behoben, beim Hoster angefragt oder bewusst akzeptiert mit Begründung.

Schritt 4: Den Bericht nutzen und sicher weitergeben

Der Reiter „Bericht“ zeigt alle technischen Daten der Installation in aufklappbaren Abschnitten. Im Labor waren das 14 Abschnitte, darunter „Verzeichnisse und Größen“, „Must-Use-Plugins“, „Aktive Plugins“, „Medienverarbeitung“, „Server“, „Datenbank“, „WordPress-Konstanten“ und „Dateisystem-Berechtigungen“. Hier sehen Sie etwa, welche PHP-Version und welches Speicherlimit tatsächlich gelten, ob Verzeichnisse beschreibbar sind und welche Konstanten in der wp-config.php gesetzt sind.

Mit der Schaltfläche „Bericht in die Zwischenablage kopieren“ erhalten Sie den gesamten Bericht als Text. Den geben Sie an einen Plugin-Support oder an Ihren Dienstleister weiter. WordPress lässt dabei als privat markierte Werte weg. Im Labor waren das Homepage-URL, Website-URL, Datenbank-Benutzername, -Host, -Name, Tabellenpräfix, Zeichensatz, Kollation und ABSPATH. Das Datenbankpasswort gehört gar nicht zum Bericht, eine Suche im exportierten Text fand es nicht. Prüfen Sie den Text vor dem Versenden trotzdem kurz, denn Plugins können eigene Abschnitte ergänzen.

Wer den Zustand regelmäßig per Skript auswerten möchte, liest die Tests auf der Kommandozeile aus. WordPress stellt dafür die Klasse WP_Site_Health bereit. Folgender Aufruf lief im Labor und listet Status und Titel aller direkten Tests:

wp eval '
require_once ABSPATH . "wp-admin/includes/class-wp-site-health.php";
require_once ABSPATH . "wp-admin/includes/admin.php";
$h = WP_Site_Health::get_instance();
foreach ( WP_Site_Health::get_tests()["direct"] as $k => $t ) {
  if ( is_string( $t["test"] ) && method_exists( $h, "get_test_" . $t["test"] ) ) {
    $r = call_user_func( array( $h, "get_test_" . $t["test"] ) );
    echo $r["status"] . " | " . wp_strip_all_tags( $r["label"] ) . PHP_EOL;
  }
}' --user=admin

Die Ausgabe enthielt im Labor Zeilen wie good | PHP-Standardzeitzone ist gültig und recommended | Der Opcode-Cache ist nicht aktiviert. Die Hintergrundtests wie Loopback-Anfrage und HTTPS-Status sind darin nicht enthalten, sie laufen im Backend separat.

Verifizieren: Der kopierte Bericht enthält im Abschnitt „Datenbank“ weder Benutzername noch Passwort, und der WP-CLI-Aufruf liefert eine Zeile je Test.

Schritt 5: Tests anpassen und dauerhaft beobachten

Manche Empfehlungen sind in Ihrer Umgebung bewusst anders gelöst, etwa ein Seiten-Cache auf Ebene des Hosters. Statt die Meldung jedes Mal wegzudenken, können Sie einen Test gezielt ausblenden. Der Filter site_status_tests ist dafür vorgesehen. Legen Sie die Datei wp-content/mu-plugins/site-health-anpassen.php an:

<?php
/**
 * Plugin Name: Website-Zustand anpassen
 * Description: Blendet Tests aus, die in dieser Umgebung bewusst anders gelöst sind.
 */
add_filter( 'site_status_tests', function ( $tests ) {
	// Seiten-Cache übernimmt der Hoster, WordPress erkennt ihn nicht.
	unset( $tests['async']['page_cache'] );
	return $tests;
} );

Im Labor war der Test page_cache danach nicht mehr in der Testliste. Blenden Sie nur Tests aus, deren Thema nachweislich gelöst ist, und dokumentieren Sie die Datei. Sonst verdecken Sie später ein echtes Problem.

Für schwierige Fälle bietet das Plugin „Health Check & Troubleshooting“ des WordPress-Teams zusätzliche Werkzeuge. Nach Installation der deutschen Sprachdatei heißt die wichtigste Funktion „Problembehandlungsmodus aktivieren“. Sie deaktiviert laut Plugin-Beschreibung alle Plugins und nutzt ein Standard-Theme, aber nur für Ihre eigene Sitzung. Besucher sehen weiter die normale Website. Außerdem enthält es Prüfungen zur „Datei-Integrität“ und eine „E-Mail-Prüfung“.

Der Website-Zustand ist eine Momentaufnahme. Nach jedem Update, jedem neuen Plugin und jedem Serverwechsel kann sich das Bild ändern. Nehmen Sie den Blick auf Werkzeuge > Website-Zustand deshalb in Ihren regelmäßigen Ablauf auf, siehe Wartungsplan für WordPress. Wer Updates, Backups und die Kontrolle danach nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung, wöchentliche Backups auf externen Speicher und die Firewall. Eine einmalige Homepage-Analyse gehört dazu.

Verifizieren: Unter Plugins > Must-Use erscheint „Website-Zustand anpassen“, die ausgeblendete Meldung fehlt im Website-Zustand, und für die nächste Kontrolle steht ein Termin fest.

Typische Fehler

• REST-API und Loopback schlagen mit „cURL error 7“ fehl: Der Server erreicht sich selbst nicht. Mit curl -sI auf dem Server prüfen, Firewall, DNS und Proxy-Konfiguration mit dem Hoster klären.
• Loopback scheitert hinter HTTP-Auth: WordPress reicht laut Core-Code die Zugangsdaten der aktuellen Sitzung an die Loopback-Anfrage weiter. Schlägt der Test dennoch fehl, prüfen Sie, ob ein vorgeschalteter Proxy den Header entfernt.
• „Ein geplantes Ereignis ist überfällig“ bleibt dauerhaft: WP-Cron startet nicht. Im Labor meldete wp cron test dazu „Error: WP-Cron spawn failed with error: cURL error 7“. Ursache wie beim Loopback beheben oder WP-Cron auf einen echten Cronjob des Servers umstellen.
• Warnung zu sichtbaren Fehlern trotz Abschaltung: WP_DEBUG_DISPLAY steht zwar auf false, aber display_errors ist in PHP aktiv oder eine zweite Definition steht weiter unten in der wp-config.php.
• Website-Zustand fehlt im Menü: Ihr Benutzer hat nicht die Rolle Administrator oder ein Plugin entzieht die Berechtigung.

Häufige Fragen

Muss die Gesamtbewertung immer „Gut“ zeigen?

Nein. Einzelne Empfehlungen können in Ihrer Umgebung sinnvoll offen bleiben. Wichtig ist, dass keine kritischen Probleme bestehen und Sie jede Empfehlung bewusst bewertet haben.

Werden beim Website-Zustand Daten an WordPress.org übertragen?

Der Test „Die Verbindung mit WordPress.org wird unterstützt“ prüft, ob Ihr Server WordPress.org erreicht. Das braucht WordPress ohnehin für Updates. Der Bericht selbst bleibt auf Ihrem Server, bis Sie ihn kopieren.

Kann ich den Problembehandlungsmodus auf einer Live-Website nutzen?

Laut Plugin-Beschreibung wirkt er nur für Ihre Sitzung. Legen Sie trotzdem vorher ein Backup an, denn das Plugin selbst ist eine zusätzliche Komponente mit eigenem Code.

Testumfang

Wir haben die Prüfungen des Website-Zustands im Labor mit WordPress 7.1.2 durchgespielt, direkt per WP-CLI ebenso wie die Hintergrundtests. Auch die tägliche automatische Prüfung lief und speicherte ihr Ergebnis.

Den Problembehandlungsmodus im Browser, Firewalls einzelner Hoster und Multisite-Installationen haben wir nicht geprüft. Betrifft Sie einer dieser Punkte, testen Sie das Vorgehen zuerst auf einer Kopie Ihrer Website.

Fazit

Der Website-Zustand ist das schnellste Werkzeug, um technische Schwachstellen einer WordPress-Installation zu erkennen. Kritische Meldungen zu REST-API, Loopback und Fehleranzeige verdienen sofortige Aufmerksamkeit, Empfehlungen eine bewusste Bewertung, und der Bericht erleichtert jede Supportanfrage. Wenn Sie die regelmäßige Kontrolle zusammen mit Updates und Backups lieber abgeben, übernimmt das die WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• Wartungsplan für WordPress: wöchentliche, monatliche und jährliche Aufgaben
• wp-config.php härten: Salts, Dateibearbeitung und Debug-Einstellungen
• PHP-OPcache und PHP-Einstellungen für WordPress optimieren
• Page-Caching in WordPress einrichten und Cache-Probleme beheben
• WordPress-Dokumentation: Site Health Screen
• Developer Reference: site_status_tests
• Health Check & Troubleshooting im Plugin-Verzeichnis von wordpress.org