Website abgestürzt: Was das heißt und wie Sie WordPress zurückholen

„Meine Website ist abgestürzt” ist ein Alltagssatz, technisch aber ungenau. Dahinter stecken sehr verschiedene Zustände: ein weißer Bildschirm, ein Fehler 500, ein Timeout oder eine nicht erreichbare Datenbank – jeder mit eigener Ursache und eigener Lösung. Wer die Fehlerseite richtig liest, grenzt das Problem in wenigen Minuten ein. Dieser Leitfaden zeigt die Bedeutung der einzelnen Zustände, eine Fünf-Minuten-Erstdiagnose und die konkreten Schritte, mit denen Sie eine WordPress-Seite zurückholen.

Was „abgestürzt” wirklich bedeutet

Ein echter Absturz – im Sinne von: Der Server ist hart ausgefallen – ist selten. Viel häufiger läuft der Server weiter, liefert aber statt der Seite eine Fehlermeldung oder gar nichts aus. Diese fünf Zustände deckt der Begriff im Alltag ab:

• Nicht erreichbar: Der Browser meldet „Server nicht gefunden” oder lädt endlos. Die Ursache liegt oft bei DNS, einer abgelaufenen Domain oder einem echten Serverausfall – nicht bei WordPress.
• Fehlerseite mit Statuscode: Der Server antwortet, aber mit 500, 502, 503 oder 504. Der Code verrät, wo es klemmt.
• Weißer Bildschirm: Die Seite lädt, bleibt aber leer (White Screen of Death). Klassiker bei PHP-Fehlern oder erschöpftem Speicher.
• Datenbankfehler: „Error establishing a database connection”. Die Anwendung läuft, erreicht aber ihre Datenbank nicht.
• Nur langsam: Die Seite kommt, aber nach 20 Sekunden. Technisch kein Absturz, wird aber oft so genannt.

Die Fehlerseite lesen – was der Statuscode verrät

Antwortet der Server mit einem HTTP-Fehler, ist der dreistellige Statuscode Ihr wichtigster Hinweis. Diese vier begegnen Ihnen bei WordPress am häufigsten, dazu zwei Sonderfälle ohne klaren Code.

HTTP 500 – Internal Server Error

Der Sammelbegriff für serverseitige Fehler. Bei WordPress steckt fast immer ein PHP-Fatal-Error dahinter (defektes Plugin oder Theme nach einem Update), eine kaputte .htaccess oder ein zu niedriges Speicherlimit. Die genaue Ursache steht nicht auf der Seite, sondern im Server-Log – dazu unten mehr.

502 Bad Gateway und 504 Gateway Timeout

Beide entstehen zwischen dem Webserver (nginx oder Apache) und dem PHP-Prozessor (PHP-FPM). 502 heißt: PHP hat eine ungültige Antwort geliefert oder ist abgestürzt. 504 heißt: PHP hat zu lange gebraucht und der Webserver hat abgebrochen. Typische Auslöser sind überlastete Ressourcen, ein hängender PHP-FPM-Pool oder sehr langsame Datenbankabfragen.

503 Service Unavailable

Der Server ist bewusst kurz nicht verfügbar. Bei WordPress erscheint 503 während eines Updates: Das System legt kurz eine Datei .maintenance im Stammverzeichnis an. Bricht ein Update ab, bleibt diese Datei liegen und die Seite zeigt dauerhaft „Kurzzeitig zur Wartung nicht verfügbar”. Die Lösung: Datei .maintenance per FTP oder Dateimanager löschen.

Weißer Bildschirm (White Screen of Death)

Eine leere Seite bedeutet meist einen PHP-Fatal-Error, bei dem die Fehleranzeige abgeschaltet ist, oder erschöpften Arbeitsspeicher. Seit WordPress 5.2 gibt es den Wiederherstellungsmodus: Bei einem fatalen Fehler mailt WordPress an die Admin-Adresse einen Link, über den sich die Seite im abgesicherten Modus öffnen und das schuldige Plugin deaktivieren lässt. Kommt keine Mail an, hilft die manuelle Diagnose weiter unten.

„Error establishing a database connection”

WordPress erreicht seine MySQL- oder MariaDB-Datenbank nicht. Ursachen sind falsche Zugangsdaten in der wp-config.php (DB_HOST, DB_USER, DB_PASSWORD), ein überlasteter oder gestoppter Datenbankserver oder eine beschädigte Tabelle.

Mehr dazu im eigenen Beitrag zur Datenbankverbindung.

Fünf-Minuten-Erstdiagnose

Bevor Sie etwas ändern, grenzen Sie das Problem ein:

1. Liegt es an Ihnen? Öffnen Sie die Seite über mobile Daten (nicht Ihr WLAN) oder über einen Prüfdienst wie „Down for everyone or just me”. Sind nur Sie betroffen, ist es oft Ihr Browser-Cache oder DNS, nicht der Server.
2. Ist das Backend erreichbar? Rufen Sie ihre-domain.de/wp-admin auf. Lädt das Dashboard, während die Startseite streikt, liegt der Fehler eher im Theme oder im Caching als am Server selbst.
3. Server-Log ansehen. Die echte Fehlermeldung steht im Log, nicht im Browser. In Plesk (Obsidian, Stand: Juli 2026) öffnen Sie es über Websites & Domains → [Ihre Domain] → Logs; alternativ im Dateimanager unter Logs → error_log. Auf dem Server selbst liegt die Datei unter /var/www/vhosts/system/<domain>/logs/error_log (mit einem Hardlink in /var/www/vhosts/<domain>/logs/error_log).
4. WordPress-Debug einschalten. Ergänzen Sie in der wp-config.php oberhalb der Zeile „That’s all, stop editing”:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Danach protokolliert WordPress Fehler in wp-content/debug.log, ohne sie Ihren Besuchern anzuzeigen.

WordPress zurückholen – die häufigsten Fixes

Plugin-Konflikt ausschließen

Häufigste Ursache für 500er und weißen Bildschirm ist ein Plugin – oft direkt nach einem Update. Ohne Backend-Zugang deaktivieren Sie alle Plugins auf einen Schlag: Benennen Sie per FTP oder im Plesk-Dateimanager den Ordner wp-content/plugins in plugins_alt um. WordPress deaktiviert damit alle Plugins. Lädt die Seite wieder, benennen Sie zurück und schalten die Plugins einzeln wieder scharf, bis der Fehler zurückkehrt – das ist der Übeltäter.

Theme testen

Bleibt der Fehler, wechseln Sie testweise auf ein Standard-Theme (etwa Twenty Twenty-Four). Ohne Backend benennen Sie den Ordner des aktiven Themes unter wp-content/themes um – WordPress fällt automatisch auf ein vorhandenes Standard-Theme zurück.

Speicherlimit erhöhen

Steht im Log „Allowed memory size … exhausted”, hilft in der wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

Greift das nicht, muss das PHP-Limit memory_limit serverseitig steigen – bei Plesk unter den PHP-Einstellungen der Domain.

.htaccess neu erzeugen

Bei Apache kann eine defekte .htaccess einen 500er auslösen. Benennen Sie die Datei um und speichern Sie im Dashboard unter Einstellungen → Permalinks einmal (ohne Änderung) – WordPress schreibt daraufhin eine frische .htaccess.

Datenbank reparieren

Bei Datenbankfehlern nach einem Absturz aktivieren Sie in der wp-config.php die Reparatur:

define( 'WP_ALLOW_REPAIR', true );

Rufen Sie dann ihre-domain.de/wp-admin/maint/repair.php auf und lassen Sie reparieren. Entfernen Sie die Zeile danach wieder, weil diese Seite sonst ohne Login für jeden erreichbar ist.

Damit es nicht wieder passiert

• Automatische Backups mit Wiederherstellungstest – ein Backup, das sich nicht einspielen lässt, ist keines. Siehe Backups erstellen.
• Updates zuerst im Staging, nie direkt auf der Live-Seite.
• Uptime-Monitoring, das Sie per Mail oder SMS warnt, bevor der Kunde anruft.
• Passendes Hosting: Bei wiederkehrenden 502/504 unter Last reicht das Paket oft schlicht nicht mehr aus.

FAQ

Ist „abgestürzt” dasselbe wie „gehackt”? Nicht zwangsläufig. Ein Absturz hat meist technische Ursachen (Update, Speicher, Datenbank). Ein Hack kann ebenfalls Fehler auslösen, zeigt aber oft zusätzliche Symptome: fremde Weiterleitungen, unbekannte Admin-Konten oder Spam-Inhalte. Prüfen Sie im Zweifel die Server-Logs und die Benutzerliste.

Meine Seite ist weiß – wo fange ich an? Erst WP_DEBUG_LOG einschalten und wp-content/debug.log lesen. Steht dort ein Plugin- oder Theme-Pfad, haben Sie den Verursacher. Bleibt das Log stumm, benennen Sie den Plugins-Ordner um (siehe oben).

Wie lange darf eine Seite offline sein, bevor Google abstraft? Kurze Ausfälle von Minuten bis wenigen Stunden verkraftet Google in der Regel – der Googlebot kommt später wieder. Kritisch wird es bei tagelanger Nichterreichbarkeit. Ein korrekt gesetzter Statuscode 503 während geplanter Wartung signalisiert „später wiederkommen” und schützt das Ranking besser als ein 500er oder ein Timeout.

Brauchen Sie Unterstützung wenn Ihre Website streikt? Ypsilon.dev ist Ihre Webagentur aus Regensburg – jetzt kostenlose Erstberatung anfragen.