Arama Yap Mesaj Senden
Rückruf anfordern
+90
X
X

Wählen Sie Ihre Währung

Türkische Lira $ US Dollar Euro
X
X

Wählen Sie Ihre Währung

Türkische Lira $ US Dollar Euro

Kontaktieren Sie uns

Standort Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
WordPress-White-Screen-Diagnose

WordPress White Screen mit HTTP-Antwort und PHP-Logs bis zur Ursache verfolgen

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.

root@eka:~/diagnostics
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 status
STATUS200, 500 oder Weiterleitung
BYTESIst der Body wirklich leer?
SCOPEGesamte Site, wp-admin oder eine URL
LOG TIMEGleiches Zeitfenster wie Anfrage
01
Themenspezifische Grundlagen

White Screen von kritischem Fehler, Cache-Ausgabe und Frontend-Fehler unterscheiden

Der 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.

Umfangstest

Gesamte Site oder nur ein Bereich?

Startseite, Einzelbeitrag, wp-login.php, wp-admin und REST API getrennt testen. Bei einem Template oder Endpoint nicht alles deaktivieren.

Antworttest

HTTP-Status und Body-Größe

500, 200 mit null Byte, abgeschnittener 200-Body und Redirect-Loop haben unterschiedliche Ursachen. Header und Body sichern.

Servernachweis

WordPress- und PHP-Logs

Tritt der Fehler vor WordPress auf, kann debug.log leer bleiben. Dann sind PHP-FPM-, Apache-, Nginx- oder LiteSpeed-Logs entscheidend.

02
Terminal und Prüfung

Echte HTTP-Ausgabe und Log-Zeit statt nur Browseransicht prüfen

01

Header und Body getrennt speichern

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.html
02

Umfang nach URL vergleichen

Unterschiede 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"
done
03

Sicheres Debug-Logging aktivieren

WordPress-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);
04

Letzte Änderungen und aktive Komponenten erfassen

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 -80
03
Umsetzungsreihenfolge

White Screen vom Umfang bis zur Ursache eingrenzen

01

Datei- und Datenbank-Backup koppeln

Vor Reparatur wp-content, wp-config.php und Datenbank als zeitgleiches Set sichern. Live-Bestellungen oder Formulare berücksichtigen.

02

Umfang des White Screens bestimmen

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.

03

Status und Body als Nachweis speichern

500 und leeren 200 nicht gleichsetzen. Content-Type, Content-Length, Redirect-Kette, Body-Größe und erste HTML-Bytes dokumentieren.

04

Logs im gleichen Zeitfenster finden

Einmal reproduzieren, dann WordPress-, PHP- und Webserverlogs prüfen. Einträge wie `Fatal error`, `Uncaught`, `memory`, `permission denied` und `upstream sent` im Kontext lesen.

05

Im Log genannte Komponente gezielt isolieren

Zeigt Pfad ein Plugin oder Theme, nur dieses deaktivieren oder zurücksetzen. Ohne Log WP-CLI-Skip-Flags und kontrollierten Vergleich nutzen.

06

Cache-, Opcode- und CDN-Schichten leeren und vergleichen

Nach Reparatur kann leere Ausgabe in Object/Page Cache, OPcache oder CDN bleiben. Schichten nacheinander leeren und Origin mit öffentlicher URL vergleichen.

07

Funktion und fehlende neue Logeinträge prüfen

Neben Startseite Login, Admin, Formulare, AJAX/REST, Cron, E-Mail und Zahlungen testen; keine neuen Fatal-Fehler oder Warnungsflut zulassen.

04
Fehlerlexikon

Technische Bedeutungen leerer Ausgabe unterscheiden

HTTP 500 + leerer Body

Meist PHP-Fatal-Fehler, Webserver-Regel, Rechteproblem oder Upstream-Absturz. Logs zum Anfragezeitpunkt priorisieren.

HTTP 200 + null oder sehr kleiner Body

Code kann früh beenden, Output Buffer leeren, Endpoint falsch antworten oder Cache leere Ausgabe speichern.

HTML vorhanden, Bildschirm trotzdem weiß

Mögliche Ursachen: CSS-Sichtbarkeit, Overlay, JavaScript, fehlende Assets oder Browser-Erweiterung. Source, Console und Network prüfen.

Nur wp-admin ist weiß

Admin-Hooks, rollenabhängiger Code, Admin-AJAX oder anderer Speicherbedarf möglich. Funktionierendes Frontend beweist keine vollständige Gesundheit.

Risiken

Zu vermeidende Praktiken

  • Nur nach Browseransicht diagnostizieren, ohne HTTP-Status zu messen
  • Plugin-/Theme-Ordner ohne Backup löschen oder umbenennen
  • PHP display_errors auf Produktion aktivieren und Pfade offenlegen
  • Reparatur wegen ungeprüfter Cache-Schichten falsch beurteilen
  • Alles gleichzeitig deaktivieren und fehlerhafte Komponente nicht mehr erkennen
Checkliste

Vor Abschluss nachweisen

  • Statuscodes für Frontend, wp-admin, Login und REST sind dokumentiert
  • Body-Größe und erste HTML-Inhalte wurden geprüft
  • WordPress- und PHP/Webserver-Logs desselben Zeitpunkts wurden verglichen
  • Fehlerhafte Komponente wurde evidenzbasiert isoliert
  • Origin-, Cache/CDN- und Privatfenster-Ergebnisse stimmen überein
  • Login, Formulare, AJAX/REST, Cron und E-Mail wurden erneut getestet
05
Häufige Fragen

Klare Antworten zum WordPress White Screen

Was ist die häufigste Ursache eines WordPress White Screens?

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.

Funktioniert WP-CLI bei White Screen?

Oft ja. Bei gleichem Fatal-Fehler können Befehle mit `--skip-plugins` und `--skip-themes` laufen; mu-plugins werden eventuell weiterhin geladen.

Bedeutet leeres debug.log, dass kein Fehler vorliegt?

Nein. Fehler kann vor WordPress auftreten, Schreibrecht fehlen oder PHP anderes Logziel nutzen. PHP-FPM-, Apache-, Nginx/LiteSpeed- und Panel-Logs prüfen.

Behebt das Umbenennen des Plugin-Ordners den White Screen?

Kann bei Plugin-Ursache Zugriff herstellen, deaktiviert aber alle Plugins und beweist Ursache nicht. Wenn möglich nur das im Log genannte Plugin behandeln.

Ist die Site bei HTTP 200 gesund?

Nein. 200 kann null Byte, abgeschnittenes HTML oder Fehlerseite enthalten. Body, Funktionen und Logs zusätzlich prüfen.

06
Internes SEO-Themencluster

Nach diesem Leitfaden zum richtigen Thema wechseln

07
Technische Quellen

Mit offizieller Dokumentation prüfen

EKA SUNUCU TEKNİK BİLGİ MERKEZİ

Treffen Sie Entscheidungen anhand technischer Nachweise statt Vermutungen.

Kontaktieren Sie Eka Software- und Informationssysteme für Installation, Server, Skripte und technischen Support.

Kontakt
Top