„Auf deiner Website ist ein kritischer Fehler aufgetreten.“ Das ist eine der beunruhigendsten WordPress-Meldungen, besonders direkt nach einem Plugin-Update, Theme-Wechsel oder einer Codeänderung.
Die gute Nachricht: kritischen WordPress-Fehler Das bedeutet nicht automatisch, dass die Website verloren, die Datenbank zerstört oder ein kompletter Neustart nötig ist. WordPress hat bei der Ausführung einen schweren PHP-Fehler festgestellt, der die Anfrage verhindert. Die Meldung ist nur das Symptom. Entscheidend ist, die Ursache zu finden.
Seit WordPress 5.2 gibt es außerdem die integrierte Funktion Recovery Mode, die Administratoren bei fatalen Fehlern durch Plugins, Themes oder eigenen Code hilft. Bevor du wahllos alles deaktivierst, solltest du prüfen, was WordPress bereits über das Problem weiß.
Was bedeutet „kritischer Fehler“ in WordPress wirklich?
WordPress ist überwiegend in PHP geschrieben. Zum Erstellen einer Seite führt es den Core, das aktive Theme, Plugins und gegebenenfalls eigenen Code aus. Verursacht eine Komponente einen fatalen Fehler, kann die Ausführung abbrechen.
WordPress fängt bestimmte fatale Fehler ab und zeigt Besuchern statt unverständlicher oder sensibler technischer Details eine allgemeine Fehlermeldung. Die offizielle Recovery-Mode-Dokumentation erklärt, dass diese Funktion mit WordPress 5.2 eingeführt wurde, um Situationen zu bewältigen, in denen ein fataler PHP-Fehler den normalen Betrieb verhindert.
Das ist für die Diagnose entscheidend: Die Meldung nennt nicht die defekte Komponente. Sie sagt nur, dass WordPress die Ausführung nicht abschließen konnte. Die eigentliche Diagnose folgt danach.
Kritischer WordPress-Fehler: häufige Ursachen
Die WordPress-Dokumentation zu häufigen Fehlern nennt unter anderem Plugin-Konflikte, Theme-Inkompatibilität, ungeeignete PHP-Versionen, Speichergrenzen und beschädigte WordPress-Dateien. Auch eigener Code kann die Ursache sein: Ein fehlerhaftes Custom-Plugin, Snippet oder PHP-Skript kann den Betrieb stoppen.
Nicht jeder kritische Fehler gehört zwingend zu diesen Gruppen, doch sie sind sinnvolle Ausgangspunkte. Ebenso wichtig ist der zeitliche Zusammenhang.
Wenn die Website vor fünf Minuten noch funktionierte und der Fehler direkt nach einem Plugin-Update erschien, solltest du dieses Plugin zuerst prüfen. Hast du gerade functions.php bearbeitet und die Website ist beim Speichern ausgefallen, ist nicht automatisch die Datenbank schuld. Eine geordnete Diagnose beginnt mit der letzten Änderung.
Prüfe zuerst die Administrator-E-Mail
Wenn WordPress nach einem fatalen Fehler beim normalen Seitenaufruf den Recovery Mode aktiviert, kann es eine E-Mail mit Fehlerdetails und einem speziellen Wiederherstellungslink an den Administrator senden.
Diese E-Mail kann das betroffene Plugin oder Theme nennen. Statt zwanzig Plugins zu deaktivieren, hast du vielleicht schon einen konkreten Hinweis.
Prüfe das Administrator-Postfach einschließlich Spam. Eine fehlende E-Mail beweist nicht, dass der Recovery Mode nicht ausgelöst wurde: Laut WordPress-Dokumentation kann die Zustellung in manchen Konfigurationen scheitern.
So funktioniert der WordPress Recovery Mode
Der Recovery Mode ist keine zweite WordPress-Installation und repariert fehlerhafte Komponenten nicht automatisch. Er öffnet eine besondere Administrator-Sitzung, in der das verursachende Plugin oder Theme pausiert werden kann, damit du das Dashboard erreichst.
Nach dem Login über den E-Mail-Link zeigt WordPress Hinweise zur problematischen Erweiterung. Du kannst sie deaktivieren, den Code korrigieren oder Einstellungen ändern und anschließend den Recovery Mode verlassen.
Das verhindert eine unnötig drastische Maßnahme: die gesamte Website abzuschalten, nur um wieder in die Verwaltung zu gelangen.
Verwechsle ihn aber nicht mit dem WordPress-Wartungsmodus. Der Wartungsmodus schützt während Updates, wenn Dateien ausgetauscht werden. Der Recovery Mode hilft bei bestimmten fatalen Fehlern. Zwei unangenehme Meldungen, aber unterschiedliche Ursachen.
Wenn die Wiederherstellungs-E-Mail nicht ankommt
Wenn der Link fehlt oder der Fehler den Zugriff weiterhin verhindert, brauchst du eine manuelle Diagnose. Die Regel bleibt: erst Informationen sammeln, dann gezielt Änderungen vornehmen.
Das erste wichtige Werkzeug ist das Fehlerprotokoll. WordPress bietet die Konstanten WP_DEBUG, WP_DEBUG_LOG und WP_DEBUG_DISPLAY. Die offizielle Debugging-Dokumentation erklärt ihre Verwendung und empfiehlt, vor Änderungen eine Staging-Umgebung oder ein geeignetes Backup bereitzuhalten.
Eine häufig verwendete Konfiguration protokolliert Fehler, ohne sie Besuchern anzuzeigen:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Wenn WP_DEBUG_LOG auf truegesetzt ist, wird das Protokoll normalerweise unter wp-content/debug.loggespeichert. Suche dort nach dem fatalen Fehler und vor allem nach dem Dateipfad. Zeigt der Pfad auf einen Ordner unter wp-content/plugins/nome-plugin/, ist das ein deutlich konkreterer Hinweis als „vielleicht ein Plugin“.
Debugging nicht dauerhaft auf der Live-Website aktiv lassen
Debugging dient der Fehlersuche, nicht als dauerhafte Einstellung auf öffentlichen Websites. Die WordPress-Dokumentation sieht Debug-Werkzeuge vor allem für lokale und Staging-Umgebungen vor und rät vom dauerhaften Einsatz im Live-Betrieb ab.
Hinzu kommt die Sicherheit: Logs können Serverpfade, technische Details und andere sensible Informationen enthalten. WordPress warnt ausdrücklich vor Logdateien, die öffentlich über das Web erreichbar sind.
Aktiviere daher nur das Nötige, sammle Informationen, behebe den Fehler und stelle die passende Produktionskonfiguration wieder her. Debugging ist ein Diagnosewerkzeug, kein dauerhafter Schmuck für deine Website.
Wenn ein Plugin schuld ist und du WordPress nicht öffnen kannst
Wenn Log oder E-Mail ein bestimmtes Plugin nennen, das Dashboard aber unerreichbar bleibt, kannst du es über die Dateien deaktivieren. WordPress dokumentiert dazu das vorübergehende Umbenennen des Plugin-Ordners per FTP/SFTP oder Dateimanager unter wp-content/plugins.
. Liegt die betroffene Komponente beispielsweise im Ordner mio-plugin, verhindert das vorübergehende Umbenennen normalerweise das Laden durch WordPress. Anschließend kannst du prüfen, ob die Website wieder erreichbar ist.
Wenn du den Verursacher nicht kennst, kannst du auch alle Plugins deaktivieren, indem du den Ordner pluginsumbenennst. Diese Methode wird in der Dokumentation zu häufigen Fehlern erwähnt, ist aber deutlich invasiver und sollte bei konkreten Hinweisen nicht die erste Wahl sein.
Auf Onlineshops oder Websites mit kritischen Funktionen kann wahlloses Deaktivieren erhebliche Folgen haben. Nutze lieber das Skalpell, wenn du die Stelle schon kennst, statt einer Kettensäge.
Und wenn das Theme verantwortlich ist?
Auch ein Theme kann fatale Fehler auslösen, besonders nach Codeänderungen, Updates oder PHP-Wechseln. Wenn das Problem direkt nach der Aktivierung oder Änderung eines Themes begann, ist der zeitliche Zusammenhang wichtig.
Die WordPress-Dokumentation empfiehlt bei häufigen Fehlern, nach Möglichkeit zu einem Standard-Theme zu wechseln. Ohne Dashboard kann dazu ein Eingriff ins Dateisystem nötig sein.
Prüfe vor dem Umbenennen von Ordnern oder manuellen Änderungen, ob ein funktionsfähiges alternatives Theme installiert ist und welches Ergebnis du erwartest. Wahllose Änderungen erschweren die Fehlersuche zusätzlich.
PHP-Version, Speicher und Kompatibilität
Nicht jeder kritische Fehler stammt von einer schlicht „defekten“ Komponente. Ein Plugin kann monatelang laufen und nach einer Umgebungsänderung ausfallen. Eine neue PHP-Version kann inkompatiblen Code sichtbar machen; auch erschöpfter Arbeitsspeicher kann die Ausführung stoppen.
Logs unterscheiden diese Fälle. Fehlende Funktionen, Typfehler, Syntaxfehler und Speichermangel erzählen unterschiedliche Geschichten. Wer nur „critical error“ auf der Website liest, übersieht die entscheidenden Diagnoseinformationen.
Wenn das Problem nach einer PHP-Änderung im Hosting-Panel auftritt, prüfe die Anforderungen der Komponenten und Hinweise des Providers. Wechsle nicht planlos PHP-Versionen, sondern ermittle zuerst die Inkompatibilität.
Ein Update hat den kritischen Fehler verursacht: Was tun?
Ein kritischer Fehler direkt nach einem Update bedeutet nicht automatisch, dass WordPress ein Downgrade braucht. Kläre zuerst, welche Komponente ausgefallen ist und warum.
Prüfe Recovery-E-Mail, Logs und Zustand der aktualisierten Komponente. Wurde das Update unterbrochen, kontrolliere die Vollständigkeit der Dateien. Bei einer Inkompatibilität mit Plugins oder Umgebung kann die vorübergehende Wiederherstellung einer funktionierenden Version sinnvoller sein als hektische Änderungen auf der Live-Website.
Hier hilft eine verlässliche Backup-Strategie. Unser WordPress-Backup-Leitfaden erklärt, warum eine Sicherung nur dann hilft, wenn sie vollständig und tatsächlich wiederherstellbar ist.
Wichtige Updates vorher im Staging zu testen, reduziert das Risiko zusätzlich. Ein kritischer Fehler ist weit weniger kritisch, wenn er auf einer Kopie auftritt, die kein Kunde verwendet.
Stelle nicht als Erstes ein Backup wieder her
Ein vorhandenes Backup muss nicht die erste Maßnahme sein. Wenn nur ein aktualisiertes Plugin betroffen ist und du es per Recovery Mode in Minuten identifizieren und deaktivieren kannst, wäre eine vollständige Wiederherstellung übertrieben.
Auf dynamischen Websites kann ein Restore außerdem seit der Sicherung geänderte Daten zurücksetzen: Bestellungen, Nutzer, Kommentare oder Inhalte, je nach Umfang der Wiederherstellung.
Ein Backup ist ein Sicherheitsnetz. Bevor du es benutzt, solltest du wissen, aus welcher Höhe du fällst.
Was du nach der Fehlerbehebung prüfen solltest
Eine wieder erreichbare Startseite bedeutet noch nicht, dass alles erledigt ist. Nach der Deaktivierung eines Plugins prüfe seine Funktionen, nach einer Snippet-Korrektur die betroffenen Seiten und nach einem PHP-Wechsel die wichtigsten Website-Bereiche.
Bei Onlineshops kontrolliere Navigation, Konto, Warenkorb und Checkout. Sende bei Formularen eine Testnachricht. Prüfe bei Mitgliederseiten Login und geschützte Inhalte. Die Tests müssen zu den Änderungen passen.
Deaktiviere anschließend vorübergehende Debug-Einstellungen und dokumentiere die Ursache. Zu wissen, dass die Website wieder funktioniert, ist hilfreich. Zu wissen, warum sie ausgefallen ist, verhindert dieselbe Situation beim nächsten Update.
Eine einfache Vorgehensweise, um nichts zu verschlimmern
Bei einem kritischen WordPress-Fehler ist die Reihenfolge wichtiger als die Klickgeschwindigkeit.
- Überlege, was unmittelbar vor dem Fehler geändert wurde.
- Prüfe das Administrator-Postfach auf die Recovery-Mode-E-Mail.
- Öffne gegebenenfalls den Wiederherstellungslink und identifiziere die betroffene Komponente.
- Falls das nicht reicht, prüfe Logs oder aktiviere vorübergehend die Protokollierung gemäß WordPress-Dokumentation.
- Bearbeite die tatsächlich betroffene Komponente statt wahllos Plugins zu deaktivieren.
- Nutze bei Bedarf ein geprüftes Backup für die Rückkehr zu einem funktionierenden Zustand.
- Teste danach die betroffenen Funktionen und entferne vorübergehende Debug-Einstellungen.
Das ist weniger spektakulär als „alles deaktivieren und schauen“, liefert aber etwas Wertvolleres: eine Diagnose.
Ein kritischer Fehler ist eine allgemeine Meldung, kein Urteil
Die Meldung ist absichtlich allgemein. Sie schützt Besucher vor technischen Details und zeigt an, dass WordPress die Ausführung nicht abschließen konnte. Zur Lösung brauchst du die Diagnoseinformationen hinter der sichtbaren Meldung.
Recovery Mode, Administrator-E-Mail und Logs sind die ersten Werkzeuge. Plugins, Theme, eigener Code, PHP-Kompatibilität, Speicher und beschädigte Dateien sind mögliche Ursachen, keine Urteile, die man zufällig auswählen sollte.
Der Unterschied zwischen geordnetem Vorgehen und einer halben Stunde Panik liegt meist darin: Erst herausfinden, was kaputt ist, dann gezielt ändern. WordPress bietet dafür bereits viele der nötigen Werkzeuge.
Das Team von The Waffle