WordPress kritischer Fehler beheben: 8 Ursachen + Schritt-für-Schritt-Lösungen (2026)

WordPress kritischer Fehler — was die Meldung bedeutet

Ein WordPress kritischer Fehler tritt auf, wenn deine WordPress-Seite plötzlich nur noch die Meldung „Es gab einen kritischen Fehler auf deiner Website. Bitte überprüfe deinen E-Mail-Posteingang für Anweisungen“ anzeigt. Dahinter steckt ein PHP-Fehler, den WordPress nicht selbst beheben konnte. Das ist die seit Version 5.2 eingeführte Schutzmaßnahme, die früher als „White Screen of Death“ (komplett weiße Seite) bekannt war.

Die gute Nachricht: WordPress sendet automatisch eine Recovery-Mail an die E-Mail-Adresse des Admin-Accounts. Darin steht ein Link, mit dem du in den geschützten Recovery-Mode gelangst — eine Spezial-Version des Backends, in der das fehlerhafte Plugin oder Theme deaktiviert ist und du normal arbeiten kannst.

Die schlechte Nachricht: Die Mail kommt manchmal gar nicht an (Spam-Filter, falsche Admin-E-Mail, blockierter Mail-Versand) oder das Problem ist so tief, dass auch der Recovery-Mode versagt. In dem Fall musst du den Fehler manuell diagnostizieren und beheben — meist über FTP-Zugang oder das Hosting-Panel.

Die 8 häufigsten Ursachen für einen kritischen WordPress-Fehler

Aus jahrelanger Praxis-Erfahrung mit WordPress-Notfällen lassen sich die Auslöser auf acht typische Szenarien eingrenzen — sortiert nach Häufigkeit:

Plugin-Konflikte sind mit fast 45 % der weitaus häufigste Auslöser. Deshalb starten alle vernünftigen Diagnose-Strategien mit dem Plugin-Test. Erst wenn das nichts bringt, folgen PHP-Memory, Theme und tiefere technische Ursachen.

Sofort-Diagnose: Recovery-Mail prüfen + Debug-Log aktivieren

Bevor du mit der Reparatur startest, brauchst du eine konkrete Fehlermeldung. WordPress zeigt sie aus Sicherheitsgründen nicht im Frontend an — du musst sie aktiv abrufen.

Schritt 1: Posteingang der Admin-E-Mail prüfen

WordPress versendet bei einem kritischen Fehler automatisch eine Recovery-Mail an die im Backend hinterlegte Admin-Adresse. Betreff meist: „Deine Webseite hat ein technisches Problem“. Darin sind enthalten:

• Eine konkrete Fehlermeldung (PHP-Fatal-Error mit Datei und Zeilennummer)
• Der Name des verursachenden Plugins oder Themes
• Ein Recovery-Mode-Link, mit dem du das Backend trotz Fehler erreichen kannst

Diese E-Mail ist der schnellste Weg zum Problem. Wenn sie ankommt, kennst du in 30 Sekunden die Ursache.

Schritt 2: Wenn keine E-Mail kommt — Debug-Modus aktivieren

Per FTP (FileZilla, Cyberduck) verbindest du dich mit dem Webserver, öffnest die wp-config.php im WordPress-Wurzelverzeichnis und änderst diese Zeile:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Nach dem Speichern und einem Reload der Seite schreibt WordPress alle Fehler in die Datei /wp-content/debug.log. Dort findest du die genaue PHP-Meldung — meist mit Hinweis auf das problematische Plugin und die Zeile, in der der Fehler auftritt.

Lösung 1: Plugin-Konflikt isolieren (löst 45 % aller Fälle)

Wenn der Fehler nach einem Plugin-Update oder einer neuen Installation aufgetreten ist, ist der Auslöser fast sicher dort zu suchen. Drei Wege führen zum Ziel:

Methode A: Über Recovery-Mode (wenn die E-Mail kam)

Klicke den Recovery-Link aus der Mail an, logge dich ein. WordPress zeigt dir oben einen gelben Hinweis mit dem fehlerhaften Plugin. Gehe zu Plugins → Installiert, deaktiviere das markierte Plugin und prüfe, ob die Seite wieder läuft.

Methode B: Plugins per FTP komplett deaktivieren

Wenn du keinen Backend-Zugriff hast, deaktivierst du alle Plugins manuell über FTP:

1. FTP-Verbindung zum Server herstellen
2. In das Verzeichnis /wp-content/plugins/ wechseln
3. Den gesamten Ordner plugins in plugins-deaktiviert umbenennen
4. Seite neu laden — wenn sie jetzt funktioniert, war es ein Plugin
5. Ordner zurückbenennen in plugins
6. Im Backend einzeln aktivieren, bis der Fehler wieder auftritt — das ist der Übeltäter

Methode C: Halbierungs-Verfahren bei vielen Plugins

Wer 30 oder mehr Plugins installiert hat und nicht jedes einzeln testen will, nutzt das Halbierungs-Verfahren: erst die Hälfte der Plugins aktivieren — Fehler weg? Dann liegt der Auslöser in der anderen Hälfte. Diese halbieren und so weiter. Nach 5–6 Iterationen ist der Übeltäter gefunden, auch bei vielen Plugins.

Lösung 2: PHP-Memory-Limit erhöhen

Wenn die Fehlermeldung im Debug-Log „Allowed memory size exhausted“ oder ähnliches enthält, ist die zugewiesene Speichergröße zu klein. WordPress braucht für komplexere Setups (Page-Builder, WooCommerce, viele Plugins) mindestens 256 MB, ideal sind 512 MB.

Per wp-config.php

In der wp-config.php direkt nach der ersten Kommentarzeile diese Zeile einfügen:

define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Per .htaccess

In der .htaccess im WordPress-Wurzelverzeichnis ergänzen:

php_value memory_limit 512M
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300

Per Hosting-Panel

Bei vielen Hostern (STRATO, IONOS, all-inkl, Raidboxes) lässt sich das PHP-Memory-Limit direkt im Panel einstellen — meist unter „PHP-Einstellungen“ oder „PHP-Konfiguration“. Vorteil: bleibt auch bei WordPress-Updates erhalten.

Lösung 3: Theme zurücksetzen oder auf Standard-Theme wechseln

Wenn der Fehler nach einem Theme-Update oder Theme-Wechsel auftritt, ist das aktive Theme der Verdächtige. Test:

1. Per FTP in /wp-content/themes/ wechseln
2. Den Ordner deines aktiven Themes umbenennen (z. B. astra → astra-test)
3. WordPress springt automatisch auf das nächste verfügbare Theme (meist Twenty Twenty-Four)
4. Seite neu laden — wenn sie jetzt funktioniert, war es das Theme
5. Ordner zurückbenennen, dann beim Theme-Hersteller nach Update fragen oder Child-Theme prüfen

Bei Page-Buildern wie Elementor, Divi oder WPBakery ist es oft nicht das Theme, sondern eine kaputte Page-Builder-Datei. Hier hilft es, eine zuletzt bearbeitete Seite per FTP-Backup zurückzuspielen oder die Page-Builder-Daten der betroffenen Seite manuell aus der Datenbank zu löschen.

Lösung 4: .htaccess reparieren

Eine beschädigte oder fehlerhaft konfigurierte .htaccess kann ebenfalls einen kritischen Fehler verursachen — vor allem nach Plugin-Installationen, die eigene Umleitungsregeln eintragen (Caching-Plugins, Sicherheits-Plugins). Reparatur:

1. Per FTP die .htaccess aus dem WordPress-Wurzelverzeichnis herunterladen (Backup!)
2. Die Original-Datei löschen oder in .htaccess-backup umbenennen
3. Im Backend zu Einstellungen → Permalinks gehen und ohne Änderung auf „Speichern“ klicken — WordPress generiert automatisch eine frische, saubere .htaccess
4. Falls das Backend nicht erreichbar ist: eine neue Datei mit dem Standard-Inhalt anlegen

Standard-Inhalt einer sauberen .htaccess für WordPress:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Lösung 5: Datenbank reparieren

Wenn die Fehlermeldung „Error establishing a database connection“ oder ein Hinweis auf korrupte Tabellen enthält, liegt das Problem in der MySQL-Datenbank. WordPress hat dafür eine eingebaute Reparatur-Funktion, die du wie folgt aktivierst:

1. In der wp-config.php diese Zeile hinzufügen: define( 'WP_ALLOW_REPAIR', true );
2. Im Browser aufrufen: https://deine-seite.de/wp-admin/maint/repair.php
3. Auf „Repair Database“ klicken — WordPress prüft und repariert alle Tabellen automatisch
4. Nach erfolgreicher Reparatur die Zeile sofort wieder entfernen (Sicherheitsrisiko, weil ohne Login zugänglich)

Alternativ funktioniert die Datenbank-Reparatur über phpMyAdmin (im Hosting-Panel): alle Tabellen markieren → „Tabelle reparieren“ aus dem Dropdown wählen.

Lösung 6: Aus dem Backup wiederherstellen

Wenn keine der vorherigen Methoden hilft oder du keine FTP-Zugangsdaten hast, ist das Backup die beste Lösung. Voraussetzung: du hast aktuelle Backups (was bei einem Wartungsvertrag automatisch der Fall ist).

Drei Wege zum Backup-Restore:

• Plugin-Backup (UpdraftPlus, BackWPup): Im Backend (Recovery-Mode) auf „Restore“ klicken — Plugin spielt das letzte Backup automatisch ein.
• Hosting-Backup: Über das Hosting-Panel (STRATO, IONOS, Raidboxes etc.) das jüngste Backup wiederherstellen — meist mit einem Klick.
• Manueller Restore per FTP + phpMyAdmin: Dateien per FTP hochladen, Datenbank-Dump per phpMyAdmin importieren.

Wann du sofort professionelle Hilfe holen solltest

Manche Situationen sind kein DIY-Fall — falsche Schritte können den Schaden vergrößern oder Datenverlust verursachen. Hol einen WordPress-Profi, wenn:

• Du keine FTP-Zugangsdaten hast und auch nicht über das Hosting-Panel zum Dateisystem kommst
• Die Recovery-Mail nicht ankommt und du keinen Zugriff auf die Admin-E-Mail-Adresse hast
• Es Hinweise auf einen Hack oder Malware gibt (verdächtige Dateien, Spam-Weiterleitungen, „Diese Seite wurde gehackt“-Warnung)
• Die Seite geschäftskritisch ist und jede Stunde Downtime Geld oder Reputation kostet
• Du kein aktuelles Backup hast und die manuellen Lösungsversuche bisher nichts gebracht haben
• Es um einen WooCommerce-Shop geht und Bestellungen verloren gehen könnten

Bei Werbeagentur Luppert bieten wir WordPress-Notfall-Hilfe ab 70 €/Stunde an. Im laufenden Wartungsvertrag (ab 29,99 €/Monat) ist die Notfall-Wiederherstellung sogar enthalten — meist sind betroffene Seiten innerhalb von 2–4 Stunden wieder online.

Eigenständig fixen, Freelancer holen oder Agentur — Vergleich

Häufige Fragen zum WordPress kritischen Fehler

Jetzt Notfall melden
☎ Sofort anrufen