- HTTP 500 und der weiße Bildschirm (White Screen of Death) sind oft dasselbe Problem, nur aus verschiedenen Blickwinkeln.
- Die drei häufigsten Ursachen: ein inkompatibles Plugin oder Theme, ein zu niedriges PHP-Memory-Limit und eine beschädigte .htaccess-Datei.
- Erst ein Backup sichern, dann systematisch per FTP und WP_DEBUG diagnostizieren.
- Seit WordPress 5.2 schützt der eingebaute Recovery Mode vor dauerhaft gesperrten Adminbereichen.
Die Website zeigt einen leeren weißen Bildschirm. Oder der Browser liefert nur die Meldung „500 Internal Server Error“. Dahinter steckt fast immer ein PHP-Absturz, der sich in wenigen Minuten eingrenzen lässt.
Was HTTP 500 und der weiße Bildschirm bedeuten und wie sie zusammenhängen
HTTP 500 bedeutet: Der Webserver hat eine Anfrage entgegengenommen, aber PHP ist so früh auf einen Fehler gestoßen, dass kein gültiges HTML entstehen konnte. Der Server antwortet dann mit dem Statuscode 500 („Internal Server Error“), und weil kein Seiteninhalt geliefert wird, sieht der Browser entweder die generische Serverfehlermeldung oder eine vollständig weiße Seite.
Der „White Screen of Death“ (WSOD) ist meist dasselbe, nur mit einer Besonderheit: In manchen Serverumgebungen und WordPress-Konfigurationen werden PHP-Fehler unterdrückt. PHP bricht zwar ab, zeigt aber auch keine Fehlermeldung an, weil die Fehlerausgabe deaktiviert ist. Das Ergebnis: ein leerer weißer Bildschirm, ohne HTTP 500 im Browser, ohne jeden Hinweis auf die Ursache. Der Fehler ist identisch, nur unsichtbarer.
| Erscheinungsbild | Was im Hintergrund passiert | Typischer Ort |
|---|---|---|
| HTTP 500 mit Serverfehlermeldung | PHP bricht mit einem fatalen Fehler ab, Ausgabe ist eingeschaltet | Frontend und Backend |
| Weißer Bildschirm ohne Meldung | PHP bricht ab, Fehlerausgabe ist deaktiviert | Häufig nur Frontend oder nur Backend |
| Weißer Bildschirm nur im Backend | Ein Plugin oder Theme macht das Backend unbrauchbar | wp-admin |
| Fehler nur auf einer Seite | Seitenspezifisches Plugin, Widget oder Shortcode ist kaputt | Einzelne Seite oder Beitrag |
Wenn der Fehler nur das WordPress-Frontend betrifft, das Backend aber noch läuft, ist das ein gutes Zeichen: Man kann direkt im Backend arbeiten. Wenn auch das Backend weiß ist oder den 500 liefert, führt der Weg über FTP und direkte Dateibearbeitung auf dem Server.
Erst Backup sichern, dann Diagnose
Bevor irgendetwas verändert wird: ein vollständiges Backup. Das gilt auch dann, wenn die Website gerade nicht erreichbar ist. Die Datenbank lässt sich per phpMyAdmin sichern, die Dateien per FTP herunterladen oder über das Backup-Werkzeug des Hosters. Wer vorher ein automatisches Backup eingerichtet hat, kann das natürlich nutzen. Warum regelmäßige Backups hier so entscheidend sind, erklärt unsere Backup-Strategie für WordPress.
Nach dem Backup folgt die Diagnose. Dabei gilt eine einfache Regel: eine Veränderung, dann testen. Wer mehrere Dinge gleichzeitig zurücksetzt, weiß danach nicht, welche Änderung den Fehler behoben hat.
Ursache 1: Plugin- oder Theme-Konflikt
WordPress lädt beim Start alle aktiven Plugins. Enthält eines davon einen PHP-Fehler oder ist mit der aktuellen WordPress-Version oder einem anderen Plugin inkompatibel, bricht der Start ab. Das passiert typischerweise nach einem Update, nach der Installation eines neuen Plugins oder nach einem WordPress-Kern-Update.
Wenn das Backend noch erreichbar ist, lassen sich Plugins dort unter „Plugins“ mit einem Klick deaktivieren. Ist das Backend weiß oder zeigt 500, geht es nur noch per FTP oder Dateimanager des Hosters:
Alle Plugins per FTP deaktivieren
Im WordPress-Dateiverzeichnis liegt der Ordner wp-content/plugins/. Diesen Ordner in der FTP-Verbindung oder im Dateimanager des Hosters umbenennen, zum Beispiel zu plugins_backup. WordPress findet dann keine Plugins mehr und lädt ohne sie. Wenn die Website danach wieder erscheint, lag der Fehler an einem Plugin.
Um das fehlerhafte Plugin einzugrenzen, den Ordner wieder auf plugins zurückbenennen und dann die einzelnen Plugin-Unterordner der Reihe nach umbenennen, bis der Fehler wieder auftritt. Der zuletzt umbenannte Ordner ist das fehlerhafte Plugin. Dann dieses Plugin deaktiviert lassen und beim Anbieter nach einem Update oder einer Lösung suchen.
Theme auf Standard zurücksetzen
Wenn das Deaktivieren der Plugins nichts bringt, kann das aktive Theme die Ursache sein. Im Ordner wp-content/themes/ das aktive Theme-Verzeichnis umbenennen. WordPress fällt dann automatisch auf ein Standard-Theme zurück (Twenty Twenty-Three oder ein vorhandenes Fallback-Theme). Erscheint die Website danach, liegt der Fehler im Theme. In diesem Fall ein Child-Theme korrekt einrichten, anstatt direkt im Parent-Theme zu ändern. Was ein Child-Theme ist und warum es keine Option, sondern Pflicht ist, erklärt unser Artikel zum WordPress Child-Theme.
Ursache 2: Erschöpftes PHP-Memory-Limit
PHP bekommt vom Server eine maximale Speichermenge zugewiesen, den sogenannten „memory_limit“. Wenn WordPress und alle geladenen Plugins mehr Speicher brauchen als erlaubt, bricht PHP den Vorgang ab. Das Ergebnis ist ein 500 oder ein weißer Bildschirm, oft ohne jeden erklärenden Text.
Typische Auslöser: ein neues, ressourcenhungriges Plugin, ein WooCommerce-Shop mit vielen Produkten oder ein komplexes Page-Builder-Layout. Manchmal tritt der Fehler auch nur beim Aufruf des Backends auf, nicht auf dem Frontend, weil das Backend mehr Ressourcen braucht.
Memory-Limit in der wp-config.php erhöhen
In der Datei wp-config.php, die im WordPress-Wurzelverzeichnis liegt, folgende Zeile einfügen, direkt vor dem abschließenden /* That's all, stop editing! */-Kommentar:
define( 'WP_MEMORY_LIMIT', '256M' );Das weist WordPress an, PHP bis zu 256 Megabyte zuzuweisen. Ob der Server diesen Wert auch tatsächlich erlaubt, liegt beim Hosting-Anbieter. Viele Managed-WordPress-Hoster setzen das Limit bereits höher, aber bei günstigen Shared-Hosting-Paketen liegt das Standard-Limit manchmal bei 64 oder 128 Megabyte.
Wenn der WordPress-Wert nicht hilft oder der Fehler im PHP-Prozess selbst liegt, muss das Limit in der php.ini des Servers gesetzt werden. Ob und wie das möglich ist, hängt vom Hoster ab. Bei manchen gibt es im Kundencenter direkt eine Einstellmöglichkeit, bei anderen müssen sie eine eigene php.ini oder .user.ini im Wurzelverzeichnis anlegen:
memory_limit = 256MEin Profi-Tipp für die Diagnose: Wenn man das Memory-Limit verdoppelt und der Fehler verschwindet, war das die Ursache. Wenn der Fehler bleibt, liegt er woanders.
Ursache 3: Fehlerhafte .htaccess oder PHP-Fehler
Die .htaccess-Datei liegt im WordPress-Wurzelverzeichnis und steuert Weiterleitungen und Permalink-Strukturen auf Apache-Webservern. Ein Syntaxfehler in dieser Datei, zum Beispiel durch ein Plugin, das fehlerhafte Regeln einträgt, führt dazu, dass Apache den gesamten Aufruf mit einem 500 beantwortet, noch bevor PHP geladen wird. WordPress bekommt das gar nicht mit.
.htaccess umbenennen und neu erstellen
Per FTP die Datei .htaccess im Wurzelverzeichnis in .htaccess_backup umbenennen (nicht löschen, der Inhalt könnte noch nützlich sein). Wenn die Website danach wieder erscheint, war die .htaccess die Ursache.
Dann im WordPress-Backend unter „Einstellungen“ und „Permalinks“ einmal auf „Speichern“ klicken, ohne irgendetwas zu verändern. WordPress erzeugt dabei automatisch eine saubere .htaccess neu. Die angepassten Weiterleitungen aus der alten Datei müssen danach manuell hinzugefügt werden, falls vorhanden.
Auf Nginx-Servern gibt es keine .htaccess. Dort läuft die Serverkonfiguration zentral über Konfigurationsdateien, die nur der Hoster oder ein Systemadministrator bearbeiten kann. Wenn der Hoster Nginx einsetzt und ein 500 auftritt, lohnt sich ein Blick ins Server-Error-Log, das der Hoster im Kundencenter zur Verfügung stellt.
Diagnose-Werkzeuge: WP_DEBUG und das Debug-Log
Wenn die einfachen Schritte den Fehler nicht aufdecken, braucht es mehr Information. WordPress bringt ein eingebautes Debugging-System mit, das sich in der wp-config.php aktivieren lässt.
Profi-Block: WP_DEBUG in der wp-config.php
Diese drei Konstanten in die wp-config.php einfügen, vor dem /* That's all, stop editing! */-Kommentar. Danach die Website aufrufen und den Fehler provozieren:
// Debugging aktivieren
define( 'WP_DEBUG', true );
// Fehler in eine Datei schreiben statt auf dem Bildschirm ausgeben
define( 'WP_DEBUG_LOG', true );
// Fehler NICHT im Browser anzeigen (für Produktivseiten)
define( 'WP_DEBUG_DISPLAY', false ); // auf Produktivseiten false, nur auf Staging zum Testen true
@ini_set( 'display_errors', 0 );Die Fehlermeldungen landen dann in der Datei wp-content/debug.log. Diese Datei per FTP herunterladen und öffnen. Dort steht, welche PHP-Datei den Fehler ausgelöst hat und in welcher Zeile. Das verrät fast immer, welches Plugin oder Theme das Problem verursacht.
Für lokale Entwicklungsumgebungen oder Staging-Server kann man stattdessen WP_DEBUG_DISPLAY auf true setzen, dann erscheinen Fehlermeldungen direkt im Browser. Auf einer Produktivseite ist das nicht sinnvoll, weil PHP-Fehlermeldungen technische Details der Installation preisgeben. Nach der Fehlersuche alle drei Konstanten wieder auf false setzen oder komplett entfernen.
Was man im debug.log sucht: Zeilen, die mit PHP Fatal error beginnen. Diese zeigen die genaue Ursache. Zeilen mit PHP Warning oder PHP Notice sind weniger dringend und führen nicht zum Absturz.
Wer noch nicht mit einer Staging-Umgebung arbeitet, sollte das spätestens jetzt einrichten. Die Fehlersuche auf einem Klon der Produktivseite ist weit sicherer als direkt auf der Live-Website. Mehr dazu in unserem Artikel zur Staging-Umgebung.
Der WordPress Recovery Mode
Bis WordPress 5.1 gab es keine eingebaute Hilfe bei fatalen PHP-Fehlern. Wer das Backend nicht mehr erreichte, musste zwingend per FTP eingreifen. Seit WordPress 5.2 (erschienen im Mai 2019) gibt es den „Fatal Error Protection Mode“, in der WordPress-Dokumentation als Recovery Mode bezeichnet.
Wie er funktioniert: Stößt WordPress beim Start auf einen fatalen PHP-Fehler, erkennt es den betroffenen Bereich (ein bestimmtes Plugin oder Theme) und sendet automatisch eine E-Mail an die in WordPress hinterlegte Admin-E-Mail-Adresse. Diese E-Mail enthält einen individuellen Link, über den man das WordPress-Backend aufrufen kann, obwohl die Website selbst nicht läuft. Im Backend ist dann direkt ersichtlich, welches Plugin oder Theme den Fehler ausgelöst hat. Man kann es deaktivieren und die Website kommt wieder hoch.
Wichtige Einschränkung: Der Recovery Mode funktioniert nur, wenn WordPress weit genug startet, um den Fehler zu erkennen und die E-Mail zu senden. Bei sehr frühen Fehlern, zum Beispiel in der wp-config.php selbst oder bei einem beschädigten WordPress-Kern, hilft er nicht. Dann bleibt nur der FTP-Weg.
In einem Projekt, das wir betreut haben, löste ein Plugin-Update auf einer WooCommerce-Installation einen fatalen Fehler aus, der das Backend komplett blockierte. Noch bevor wir per FTP eingreifen konnten, kam die Recovery-Mode-E-Mail. Über den darin enthaltenen Link war das Backend erreichbar, das fehlerhafte Plugin deaktiviert und der Shop wieder online, alles ohne Dateizugriff auf dem Server. Eine schnelle Lösung, die früher mehrere Minuten länger gedauert hätte.
Sofort-Checkliste: Schritt für Schritt zum laufenden WordPress
- Backup der Dateien und der Datenbank sichern, bevor etwas verändert wird.
- Auf die Admin-E-Mail prüfen: Hat WordPress eine Recovery-Mode-Nachricht geschickt?
- Wenn das Backend erreichbar ist: alle Plugins deaktivieren, danach einzeln reaktivieren.
- Wenn das Backend gesperrt ist: Plugin-Ordner per FTP nach plugins_backup umbenennen.
- Wenn Plugins nicht die Ursache sind: Theme-Ordner per FTP umbenennen.
- Wenn der Fehler bleibt: .htaccess in .htaccess_backup umbenennen, dann Permalinks neu speichern.
- WP_MEMORY_LIMIT in der wp-config.php auf 256M setzen und erneut testen.
- WP_DEBUG und WP_DEBUG_LOG aktivieren, debug.log auf „PHP Fatal error“ prüfen.
- Nach der Lösung WP_DEBUG deaktivieren und das Plugin oder Theme auf Updates prüfen.
- Zukünftig: Staging-Umgebung nutzen, Updates dort zuerst testen.
- HTTP 500 und WSOD sind fast immer dasselbe: PHP ist vor der Ausgabe abgestürzt.
- Die drei häufigsten Ursachen lassen sich in wenigen Minuten ausschließen: Plugin, Memory, .htaccess.
- WP_DEBUG und das debug.log liefern die genaue Fehlermeldung und sparen lange Fehlersuche.
- Seit WordPress 5.2 schützt der Recovery Mode vor dauerhaft gesperrten Adminbereichen und macht viele FTP-Eingriffe überflüssig.
Häufige Fragen
Was ist der Unterschied zwischen HTTP 500 und dem weißen Bildschirm?
Technisch meist keiner. HTTP 500 ist die Antwort des Webservers, wenn PHP abstürzt. Der weiße Bildschirm entsteht, wenn PHP abstürzt, aber keine Fehlermeldung ausgeben darf. Beide zeigen denselben Zustand: WordPress konnte keine Seite erzeugen.
Muss ich für die Fehlersuche immer FTP nutzen?
Nicht immer. Wenn das WordPress-Backend noch zugänglich ist, können Plugins direkt dort deaktiviert werden. Wenn WordPress eine Recovery-Mode-E-Mail schickt, lässt sich über den darin enthaltenen Link das Backend aufrufen, ohne FTP. FTP braucht man nur, wenn kein Zugang mehr über den Browser besteht.
Wie aktiviere ich WP_DEBUG ohne das Backend?
Per FTP die Datei wp-config.php im WordPress-Wurzelverzeichnis herunterladen, die drei Debug-Konstanten eintragen (WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY) und die Datei wieder hochladen. Danach die Seite aufrufen und die Datei wp-content/debug.log herunterladen.
Was bedeutet „out of memory“ im debug.log?
Genau das: PHP hat das zugewiesene Speicherlimit überschritten. Die Lösung ist, WP_MEMORY_LIMIT in der wp-config.php auf einen höheren Wert zu setzen, zum Beispiel 256M. Wenn der Hoster das nicht zulässt, muss das Limit über das Hosting-Kundencenter oder den Support erhöht werden.
Was ist der WordPress Recovery Mode?
Eine seit WordPress 5.2 eingebaute Schutzfunktion. Erkennt WordPress beim Start einen fatalen PHP-Fehler durch ein Plugin oder Theme, sendet es automatisch eine E-Mail an die Admin-E-Mail-Adresse. Der Link in dieser E-Mail öffnet das Backend in einem gesicherten Modus, in dem das fehlerhafte Plugin oder Theme deaktiviert werden kann.
Warum tritt der Fehler 500 oft nach einem Update auf?
Updates ändern PHP-Code. Wenn ein Plugin nicht mit einer neuen WordPress-Version oder einer neuen PHP-Version kompatibel ist, kann nach dem Update ein fataler Fehler entstehen. Deshalb empfiehlt es sich, Updates zuerst auf einer Staging-Kopie zu testen, bevor sie auf der Produktivseite eingespielt werden.
Kann auch der Hosting-Server die Ursache sein?
Ja, selten aber möglich. Wenn der Server selbst überlastet ist oder ein Serverprozess abstürzt, antwortet er ebenfalls mit 500. In diesem Fall hilft kein FTP-Eingriff in WordPress-Dateien. Der Hoster muss informiert werden. Anhaltspunkt: Wenn die Fehlerseite schon vor dem WordPress-Loading-Prozess erscheint und auch nach dem Umbenennen aller Plugins weiterbesteht, ist der Server die wahrscheinlichere Ursache.
Wann sollte ich professionelle Hilfe holen?
Wenn alle beschriebenen Schritte den Fehler nicht auflösen, das debug.log keinen klaren Hinweis liefert oder wenn die Website ein laufendes Geschäft ist und jede Stunde Ausfall Umsatz kostet. In diesem Fall ist ein Eingriff durch eine WordPress-Agentur sinnvoll, die direkten Serverzugang und Erfahrung mit komplexen Fehlerbildern mitbringt. Ob ein Wartungsvertrag sinnvoll ist, der solche Notfälle abdeckt, zeigt unser Artikel zum WordPress Wartungsvertrag.