Ein White Screen ist kein einzelner Fehler. Der Server kann 500 liefern, bei 200 einen leeren oder abgeschnittenen Body senden, nur wp-admin betreffen oder Cache/CDN kann eine alte leere Ausgabe liefern. Zuerst Umfang und echte HTTP-Antwort messen.
curl -sS -D /tmp/headers.txt -o /tmp/body.html https://example.com/
sed -n '1,20p' /tmp/headers.txt
wc -c /tmp/body.html
tail -n 120 wp-content/debug.log
wp plugin status
wp theme statusDer Browser kann leer wirken, obwohl HTML vorhanden ist oder JavaScript/CSS Inhalte verbirgt. Mit `curl` Status, Header und Body-Größe messen; danach WordPress debug.log und PHP-FPM-, Apache-, Nginx- oder LiteSpeed-Logs im gleichen Zeitfenster vergleichen.
Startseite, Einzelbeitrag, wp-login.php, wp-admin und REST API getrennt testen. Bei einem Template oder Endpoint nicht alles deaktivieren.
500, 200 mit null Byte, abgeschnittener 200-Body und Redirect-Loop haben unterschiedliche Ursachen. Header und Body sichern.
Tritt der Fehler vor WordPress auf, kann debug.log leer bleiben. Dann sind PHP-FPM-, Apache-, Nginx- oder LiteSpeed-Logs entscheidend.
Zeigt Status, Content-Type, Redirects und ob Body wirklich leer ist. Vergleich zwischen CDN und Origin kann Cache-Unterschiede zeigen.
curl -sS -D /tmp/wp-headers.txt -o /tmp/wp-body.html https://example.com/
sed -n '1,25p' /tmp/wp-headers.txt
wc -c /tmp/wp-body.html
head -c 300 /tmp/wp-body.htmlUnterschiede zwischen Frontend, Login, Admin und REST können auf Theme, Admin-Plugin oder Rewrite hinweisen. Statuscodes gemeinsam anzeigen.
for u in / /wp-login.php /wp-admin/ /wp-json/; do
curl -sS -o /dev/null -w "$u %{http_code} %{size_download}\n" "https://example.com$u"
doneWordPress-Logging ohne Anzeige aktivieren, Fehler einmal reproduzieren und letzte Zeilen lesen. Wird nichts geschrieben, wp-content-Rechte und PHP-Error-Log prüfen.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);Zeitlinie von Deployment, Plugin-/Theme-Update, PHP-Wechsel oder Cache-Regel beschleunigt die Diagnose.
wp core version
php -v
wp plugin list --status=active --fields=name,status,version,update
wp theme list --status=active --fields=name,status,version,update
find wp-content -type f -mmin -180 | head -80Vor Reparatur wp-content, wp-config.php und Datenbank als zeitgleiches Set sichern. Live-Bestellungen oder Formulare berücksichtigen.
Startseite, Inhalt, wp-login.php, wp-admin und wp-json in privatem Fenster und anderem Netz vergleichen. Bei nur einem Gerät Browser/Cache prüfen.
500 und leeren 200 nicht gleichsetzen. Content-Type, Content-Length, Redirect-Kette, Body-Größe und erste HTML-Bytes dokumentieren.
Einmal reproduzieren, dann WordPress-, PHP- und Webserverlogs prüfen. Einträge wie `Fatal error`, `Uncaught`, `memory`, `permission denied` und `upstream sent` im Kontext lesen.
Zeigt Pfad ein Plugin oder Theme, nur dieses deaktivieren oder zurücksetzen. Ohne Log WP-CLI-Skip-Flags und kontrollierten Vergleich nutzen.
Nach Reparatur kann leere Ausgabe in Object/Page Cache, OPcache oder CDN bleiben. Schichten nacheinander leeren und Origin mit öffentlicher URL vergleichen.
Neben Startseite Login, Admin, Formulare, AJAX/REST, Cron, E-Mail und Zahlungen testen; keine neuen Fatal-Fehler oder Warnungsflut zulassen.
Meist PHP-Fatal-Fehler, Webserver-Regel, Rechteproblem oder Upstream-Absturz. Logs zum Anfragezeitpunkt priorisieren.
Code kann früh beenden, Output Buffer leeren, Endpoint falsch antworten oder Cache leere Ausgabe speichern.
Mögliche Ursachen: CSS-Sichtbarkeit, Overlay, JavaScript, fehlende Assets oder Browser-Erweiterung. Source, Console und Network prüfen.
Admin-Hooks, rollenabhängiger Code, Admin-AJAX oder anderer Speicherbedarf möglich. Funktionierendes Frontend beweist keine vollständige Gesundheit.
Plugin-/Theme-PHP-Fatal-Fehler und Speichermangel sind häufig, aber auch leere 200-Antworten, Cache, Rechte, Webserver oder Frontend sind möglich. Status und Logs sind nötig.
Oft ja. Bei gleichem Fatal-Fehler können Befehle mit `--skip-plugins` und `--skip-themes` laufen; mu-plugins werden eventuell weiterhin geladen.
Nein. Fehler kann vor WordPress auftreten, Schreibrecht fehlen oder PHP anderes Logziel nutzen. PHP-FPM-, Apache-, Nginx/LiteSpeed- und Panel-Logs prüfen.
Kann bei Plugin-Ursache Zugriff herstellen, deaktiviert aber alle Plugins und beweist Ursache nicht. Wenn möglich nur das im Log genannte Plugin behandeln.
Nein. 200 kann null Byte, abgeschnittenes HTML oder Fehlerseite enthalten. Body, Funktionen und Logs zusätzlich prüfen.
Kontaktieren Sie Eka Software- und Informationssysteme für Installation, Server, Skripte und technischen Support.