„Es gab einen kritischen Fehler auf deiner Website.“ Mehr sagt WordPress nicht, und genau diese Wortkargheit macht die Meldung so nervenaufreibend. Deine Website ist weg, das Backend oft gleich mit, und der einzige Hinweis ist ein Satz, der klingt wie ein Achselzucken.
Hier kommt die Beruhigung: Der kritische Fehler ist in den allermeisten Fällen ein Plugin- oder Theme-Problem, und WordPress hat dir im Moment des Absturzes bereits ein Rettungspaket geschickt, von dem viele gar nichts wissen: eine E-Mail mit einem Wiederherstellungslink, der dich an der kaputten Website vorbei ins Backend bringt.
In diesem Artikel lösen wir den Fehler Schritt für Schritt: erst über den Wiederherstellungsmodus (der bequeme Weg), dann per FTP (der Weg, der immer funktioniert), und mit dem Debug-Log als Beweismittel, damit du nicht raten musst, sondern schwarz auf weiß siehst, wer der Schuldige ist. Und falls du gar keine Meldung siehst, sondern nur eine komplett weiße Seite: Auch dieser Sonderfall hat hier seinen eigenen Abschnitt. Dahinter steckt nämlich derselbe PHP-Fehler, nur ohne Verpackung.
Das Wichtigste in Kürze:
- Die Meldung ist WordPress‘ Schutzmechanismus bei einem fatalen PHP-Fehler, in den meisten Fällen ausgelöst durch ein Plugin oder Theme, oft direkt nach einem Update.
- Prüf zuerst dein Admin-E-Mail-Postfach: WordPress verschickt automatisch eine Mail mit Wiederherstellungslink, über den du trotz Fehler ins Backend kommst.
- Im Wiederherstellungsmodus zeigt dir WordPress sogar, WELCHE Erweiterung den Fehler verursacht. Deaktivieren, fertig.
- Ohne Mail läuft die Lösung per FTP: plugins-Ordner umbenennen, Theme auf Standard umstellen, Speicherlimit erhöhen.
- Siehst du statt der Meldung eine komplett weiße Seite? Das ist technisch derselbe fatale PHP-Fehler, nur ohne die Schutzmeldung von WordPress. Ein schneller Test: Ist nur das Frontend weiß, deutet das aufs Theme. Sind Frontend und Backend weiß, ist eher ein Plugin oder das Speicherlimit schuld.
- Das Debug-Log (WP_DEBUG_LOG) verrät dir die exakte Fehlerquelle samt Dateipfad, wenn das Ausschlussverfahren nicht reicht.
Was die Meldung wirklich bedeutet
Hinter dem kritischen Fehler steckt ein sogenannter Fatal Error: PHP, die Sprache hinter WordPress, ist bei der Ausführung auf ein unlösbares Problem gestoßen und hat abgebrochen. Früher gab es in diesem Moment den berüchtigten White Screen of Death, also eine komplett weiße Seite ohne jede Information. Die heutige Meldung ist der zivilisierte Nachfolger: WordPress fängt den Absturz ab, zeigt Besuchern eine neutrale Meldung und schickt dem Administrator eine Hilfs-Mail.
Die Ursachen dahinter sind erstaunlich konstant. An der Spitze mit großem Abstand: ein Plugin- oder Theme-Konflikt, typischerweise nach einem Update, einer Neuinstallation oder einem PHP-Versionswechsel beim Hoster. Danach kommen ein erschöpftes PHP-Memory-Limit (erkennbar an „Allowed memory size exhausted“ im Fehlerprotokoll), eine zu alte oder zu neue PHP-Version für eine deiner Erweiterungen, und beschädigte Dateien. Merk dir diese Reihenfolge, sie ist gleich unser Fahrplan!
Schritt 1: Die Rettungs-Mail und der Wiederherstellungsmodus
Bevor du irgendetwas Technisches anfasst, öffne dein Postfach, und zwar das der Administrator-E-Mail-Adresse aus den WordPress-Einstellungen (auch den Spam-Ordner!). Die Mail geht NICHT an die Adresse deines Benutzerkontos, und genau das ist oft der Grund, warum sie scheinbar fehlt, denn viele haben im Profil eine andere Adresse hinterlegt.
Die Betreffzeile lautet genau: „[Name deiner Website] Deine Website hat ein technisches Problem“. Vorne in eckigen Klammern steht der Titel deiner Website, damit findest du die Mail ganz easy über die Suche im Postfach. Diese Mail ist Gold wert, aus zwei Gründen:
- Sie benennt oft schon den Verursacher („ausgelöst durch das Plugin XY“). Ganz unten steht außerdem ein Block „Fehlerdetails“ mit der eigentlichen Fehlermeldung. Den kannst du direkt an deinen Hoster-Support schicken, oft liefert er dasselbe wie das Fehlertagebuch, ohne dass du eine einzige Datei anfassen musst.
- Sie enthält einen Wiederherstellungslink, mit dem du trotz Fehler wieder in deine Website kommst.
Der Link ist 24 Stunden gültig. WordPress verschickt außerdem höchstens eine solche Mail pro 24 Stunden, wer die Seite mehrfach aufruft und auf eine neue Mail wartet, wartet also umsonst. Ist der Link abgelaufen, muss der Fehler erneut auftreten, damit eine frische Mail rausgeht.
- Link anklicken und einloggen Du landest im Wiederherstellungsmodus (Recovery-Modus) und kannst dich ganz normal einloggen, während die fehlerhafte Erweiterung für dich pausiert ist. Bist du einmal drin, hält die Sitzung eine Woche, du musst also nicht in Panik alles in fünf Minuten erledigen.
- Den Übeltäter finden Im Backend, also im Verwaltungsbereich deiner Website, öffnest du die Seite Plugins. Oben in der Filterleiste erscheint ein eigener Reiter „Pausiert (1)“, darüber findest du den Übeltäter sofort. Beim Plugin steht der Hinweis „Dieses Plugin konnte nicht ordnungsgemäß geladen werden und ist im Wiederherstellungsmodus pausiert.“, beim Theme „Dieses Theme konnte nicht ordnungsgemäß geladen werden und wurde im Administrations-Backend pausiert.“
- Deaktivieren Deaktiviere das markierte Plugin beziehungsweise wechsle weg vom markierten Theme.
- Wiederherstellungsmodus verlassen Klick auf den Button „Wiederherstellungsmodus verlassen“. Der sitzt oben rechts in der schwarzen Leiste am oberen Bildschirmrand, in den Einstellungen suchst du ihn vergeblich.
Und schon läuft deine Website wieder. Das Ganze dauert keine fünf Minuten!
Schritt 2: Der FTP-Weg, wenn keine Mail kommt
Keine Rettungs-Mail im Postfach? Kein Grund zur Panik! Alles, was der Wiederherstellungsmodus für dich erledigt, kannst du auch von Hand machen. Du brauchst dafür nur Zugriff auf die Dateien deiner Website, und der ist schneller eingerichtet, als du denkst.
Kurz vorweg: So kommst du an deine Dateien
- Dateimanager im Hosting-Panel Das ist ein Datei-Explorer, der direkt im Browser in der Verwaltungsoberfläche deines Hosters läuft. Du musst nichts installieren, und für zwei, drei Handgriffe ist das der bequemste Weg.
- FTP-Programm wie FileZilla FTP ist ein Verfahren, mit dem du Dateien zwischen deinem Rechner und dem Server hin- und herschiebst, und FileZilla ist ein kostenloses Programm dafür. Musst du viele Dateien bewegen, bist du damit besser bedient.
- Die richtigen Zugangsdaten Die FTP-Zugangsdaten sind NICHT deine WordPress-Anmeldedaten. Sie stehen im Hosting-Panel unter einem Punkt wie FTP-Zugänge oder FTP-Konten, und dort legst du im Zweifel einfach einen neuen Zugang an.
- Verbindung klappt nicht? Dann verlangt dein Hoster meist SFTP statt FTP, also die verschlüsselte Variante der Übertragung. Welche Zugangsart gilt, steht im Panel bei den FTP-Zugängen.
- Der richtige Ordner Je nach Hoster heißt er httpdocs, public_html oder www. Das Erkennungsmerkmal, das immer stimmt: Hier liegen wp-admin, wp-content und wp-config.php nebeneinander. Siehst du die nicht, bist du falsch, und dann fasst du NICHTS an.
- Dateien bearbeiten Herunterladen, bearbeiten, wieder hochladen. Nimm dafür nur einen reinen Texteditor, also Editor/Notepad unter Windows oder TextEdit im Modus Reiner Text am Mac. NIEMALS Word, Pages oder Google Docs, die bauen unsichtbare Zeichen ein, und die Seite bleibt weiß.
Jetzt geht’s ans Eingemachte. Du arbeitest dich von der häufigsten Ursache zur seltensten vor: erst die Plugins, dann das Theme, dann das Speicherlimit. Und keine Sorge, jeder Schritt ist einzeln machbar!
- 1. Plugin-Ordner umbenennen Navigiere in den Ordner wp-content und benenne den Ordner plugins um, etwa in plugins-alt. Umbenennen löscht nichts. Deine Plugins liegen unverändert im Ordner und kommen beim Zurückbenennen komplett zurück.
- 2. Seite neu laden Ruf deine Website auf und lade sie neu. Läuft sie wieder, war es ein Plugin, und du weißt schon mal, wo du suchen musst.
- 3. Ins Backend und Plugins öffnen Jetzt kommt der Schritt, den die meisten Anleitungen verschlucken: Logg dich unter deinedomain.de/wp-admin ins Backend ein, also in den Verwaltungsbereich deiner Website. Öffne in der linken Seitenleiste die Seite Plugins, solange der Ordner noch plugins-alt heißt. Das Umbenennen allein deaktiviert die Plugins nämlich nicht in der Datenbank, erst dieser Aufruf trägt sie wirklich als deaktiviert ein.
- 4. Ordner zurückbenennen Erst jetzt benennst du plugins-alt wieder in plugins um. Die Plugins stehen dann wieder in der Liste, bleiben aber aus.
- 5. Plugins einzeln wieder anschalten Halte ein zweites Browser-Fenster mit deiner Startseite offen. Aktiviere ein Plugin, lade im zweiten Fenster neu und geh weiter zum nächsten, bis der Fehler zurückkommt, denn dann ist das zuletzt aktivierte Plugin der Täter. Sperrt dich das Aktivieren wieder aus, ist das kein Rückschritt: Du benennst den plugins-Ordner einfach nochmal um. Ganz ehrlich: Bei 25 Plugins dauert das eine halbe Stunde.
- Kein Plugin schuld? Theme testen Benenne in wp-content/themes den Ordner deines aktiven Themes um. Weißt du nicht mehr, wie es heißt: Deins ist der Ordner, der NICHT mit twenty anfängt, und hast du ein Child-Theme, also ein abgeleitetes Theme, dessen Name auf -child endet, benennst du dieses um. Wichtig: Der automatische Rückfall klappt nur, wenn im themes-Ordner noch ein mitgeliefertes Theme liegt, dessen Name mit Twenty anfängt, sonst hast du nach dem Umbenennen gar kein Theme.
- Theme als Übeltäter erwischt Läuft die Seite nach dem Umbenennen, liegt der Fehler im Theme, sehr oft in einer frisch bearbeiteten functions.php. Dann einfach die letzte Änderung dort rückgängig machen.
- Immer noch nichts? Speicherlimit prüfen Das lohnt sich nur, wenn im Fehlerprotokoll „Allowed memory size … exhausted“ steht, ohne diesen Satz ist Speicher-Erhöhen nur Raten. Öffne dann die wp-config.php und such mit Strg+F (Mac: cmd+F) nach dem Textstück Schluss mit dem Bearbeiten, ohne Apostroph, denn der ist typografisch und wird sonst nicht gefunden. In der deutschen Datei lautet die Zeile „Das war’s, Schluss mit dem Bearbeiten! Viel Spaß.“, bei älteren oder englischen Installationen steht dort That’s all, stop editing. Die neue Zeile kommt DARÜBER, nicht darunter.
Hier ist die Zeile fürs Speicherlimit zum Kopieren, damit du dich nicht vertippst:
define( 'WP_MEMORY_LIMIT', '256M' );
Die Zeile wirkt allerdings nur, wenn dein Hoster das zulässt. Bleibt der Fehler, hat er eine niedrigere Obergrenze gesetzt. Die änderst du im Hosting-Panel bei den PHP-Einstellungen, oder du schreibst dem Support eine Zeile.
Schritt 3: Debug-Log lesen statt raten
Das Ausschlussverfahren hat nichts gebracht, oder du willst es einfach genau wissen? Dann lass dir den Fehler im Klartext geben, statt weiter zu raten. Dafür gibt es zwei Wege, und der erste ist deutlich bequemer.
Der bequemere Weg zuerst: das Fehlerprotokoll deines Hosters. Das schreibt der Server von selbst mit, es ist immer da, und du musst keine Datei anfassen. Du findest es im Hosting-Panel meist unter einem Punkt wie Logs, Logfiles oder Protokolle.
Der Unterschied in einem Satz: Das Protokoll des Hosters kommt vom Server und ist immer vorhanden, das Fehlertagebuch von WordPress musst du erst einschalten, dafür ist es genauer. Dieses Fehlertagebuch heißt Debug-Log, und WordPress schreibt es nur auf Wunsch mit. So schaltest du es ein:
- 1. Die wp-config.php öffnen Die Datei liegt ganz oben in deinem Website-Ordner, direkt neben den Ordnern wp-admin und wp-content. Sichere vorher eine Kopie auf deinem eigenen Rechner. Bearbeiten nur mit einem reinen Texteditor, niemals mit Word, Pages oder Google Docs.
- 2. Die vorhandene Zeile ändern Such mit Strg+F (Mac: cmd+F) nach WP_DEBUG, statt zu scrollen. Dort steht define( ‚WP_DEBUG‘, false ); und du änderst false in true. Findest du die Zeile nicht, fügst du sie selbst ein, und steht sie schon auf true, lässt du sie einfach so.
- 3. Zwei Zeilen ergänzen und speichern Direkt darunter kommen die zwei Zeilen aus der Box unten. Die erste schaltet das Fehlertagebuch ein, die zweite sorgt dafür, dass die Meldungen nicht auf deiner Seite erscheinen. Aber Achtung: WP_DEBUG_LOG wirkt nur, wenn WP_DEBUG auf true steht, die zwei neuen Zeilen allein reichen nicht.
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Gespeichert und hochgeladen? Dann such im Ordner wp-content nach der Datei debug.log. Ist sie noch nicht da, hast du nichts falsch gemacht! Die Datei entsteht erst, wenn nach der Änderung tatsächlich wieder ein Fehler auftritt. Ruf also die kaputte Seite einmal auf.
Zum Lesen lädst du die Datei herunter und öffnest sie mit demselben reinen Texteditor. Die neuesten Einträge stehen ganz unten, mit Strg+Ende (Mac: cmd+Pfeil nach unten) springst du direkt hin.
Klingt nach Zeichensalat? Keine Sorge, du suchst nur nach einer einzigen Zeile: der mit „Fatal error“, also dem schweren Fehler, der deine Seite lahmlegt. Zeilen mit „Notice“ (Hinweis), „Warning“ (Warnung) oder „Deprecated“ (veraltet) sind harmlos, die darfst du getrost überspringen. In der Fatal-error-Zeile steht ein Dateipfad, und der verrät den Täter:
- Pfad mit /plugins/ Steht im Pfad /plugins/irgendein-plugin/, ist dieses Plugin dein Kandidat.
- Pfad mit /themes/ Steht dort /themes/dein-theme/functions.php, ist das Theme schuld, meist wegen einer frisch eingefügten Code-Zeile.
- „Allowed memory size … exhausted“ Steht das im Protokoll, ist es kein Plugin-Drama, sondern schlicht der Speicher am Anschlag.
Sonderfall: die komplett weiße Seite (White Screen of Death)
Du siehst gar keine Meldung, sondern nur eine leere weiße Seite? Dann liegt derselbe fatale PHP-Fehler vor — WordPress schafft es hier nur nicht mehr, dir die Schutzmeldung auszuliefern. Live-Websites unterdrücken PHP-Fehler nämlich aus gutem Grund, statt sie für alle Besucher sichtbar auf den Bildschirm zu schreiben. Die gute Nachricht: Die Fehlermeldung existiert! Sie wird dir nur nicht angezeigt. Deine Aufgabe ist also nicht Rätselraten, sondern die versteckte Meldung sichtbar zu machen oder den Verursacher per Ausschlussverfahren einzukreisen. Genau das machen wir jetzt.
Der Schnelltest: Frontend, Backend oder beides?
Bevor du irgendetwas änderst, beantworte eine Frage, denn sie halbiert deine Suche: Ist nur das Frontend weiß, also die öffentliche Website, die deine Besucher sehen? Oder auch das Backend, also dein Verwaltungsbereich unter deinedomain.de/wp-admin?
| Was siehst du? | Was bedeutet das und was tust du? |
|---|---|
| Nur die öffentliche Website ist weiß, der Verwaltungsbereich geht | Das ist fast sicher das Theme. Aktiviere im Backend unter Design → Themes eines der mitgelieferten Themes, deren Name mit Twenty anfängt: einfach auf der Kachel auf Aktivieren klicken. Ist gar keins mehr installiert, installierst du erst über Theme hinzufügen eines. Wird die Seite wieder sichtbar, ist dein Theme der Patient. |
| Website und Verwaltungsbereich sind beide weiß | Dann ist es eher ein Plugin oder das Speicherlimit. Die Reparatur läuft über FTP wie in Schritt 2. |
Dein eigenes Theme bleibt beim Test komplett erhalten. Du schaltest nur um und danach genauso wieder zurück. Ehrlich gesagt musst du Menüzuordnungen und Widgets nach dem Zurückschalten manchmal neu setzen. Und Besucher sehen in diesen Minuten das nackte Standard-Theme, also teste besser nicht zur Stoßzeit.
Beide Bereiche weiß? Keine Sorge, das klingt technischer, als es ist.
Erste Hilfe: Cache leeren
Der unspektakulärste Fix zuerst, weil er erstaunlich oft reicht. Der Browser-Cache ist der Zwischenspeicher deines Browsers. Er merkt sich Seiten, um sie schneller zu zeigen, und liefert dann manchmal hartnäckig die alte, kaputte Version aus. So räumst du ihn aus dem Weg:
- Öffne deine Website zur Gegenprobe im privaten Fenster: Strg+Umschalt+N, am Mac cmd+Umschalt+N. Das ist der schnellste Test und braucht kein Menü.
- Lade die Seite hart neu mit Strg+F5.
- Nutzt du ein Caching-Plugin, leerst du dessen Zwischenspeicher gleich mit. Kommst du gar nicht ins Backend, leerst du ihn über das Hosting-Panel oder, wenn du ohnehin schon per FTP drin bist, indem du den Inhalt des Ordners wp-content/cache löschst.
Manchmal ist der eigentliche Fehler längst weg, aber der Cache liefert hartnäckig die kaputte weiße Version aus. Zwei Minuten Aufwand, und wenn es das war, kannst du hier aufhören zu lesen!
Der unterschätzte Auslöser: die PHP-Version
Ein Sonderfall verdient einen eigenen Abschnitt, weil er so oft übersehen wird: Der kritische Fehler taucht „aus dem Nichts“ auf, ohne dass du irgendetwas geändert hast. Häufige Erklärung: Dein Hoster hat die PHP-Version umgestellt, und eine deiner Erweiterungen verträgt die neue Version nicht, oder umgekehrt verlangt ein frisch aktualisiertes Plugin eine neuere PHP-Version, als dein Tarif eingestellt hat.
Der Check kostet zwei Minuten:
- Sieh im Hosting-Panel bei deiner Domain nach, welche PHP-Version aktiv ist. Das steht meist unter einem Punkt wie PHP-Einstellungen oder PHP-Version.
- Schau nach, was deine Plugins verlangen. Das steht nicht im WordPress-Backend, sondern auf der Seite des Plugins bei wordpress.org unter der Angabe „Requires PHP“.
- Gleich beides mit der Empfehlung ab: WordPress selbst empfiehlt mindestens PHP 8.3. Die technische Untergrenze liegt bei 7.4, und die bekommt längst keine Sicherheitsupdates mehr.
Und wenn die PHP-Version tatsächlich der Auslöser ist? Stell sie im Panel probeweise eine Stufe zurück und lade die Website neu. Läuft sie wieder, ist die Ursache bewiesen. Gratulation!
Ehrlich gesagt ist das aber nur eine Zwischenlösung, weil alte PHP-Versionen keine Sicherheitsupdates mehr bekommen. Die eigentliche Aufgabe lautet: das bockige Plugin aktualisieren oder ersetzen.
Wenn gar nichts hilft
Bleibt der Fehler hartnäckig? Dann geht es an die selteneren Ursachen. Ehrlich gesagt sind das die Eingriffe, bei denen du am meisten kaputtmachen kannst, deshalb bekommst du hier die Einordnung und die Reißleine gleich mit.
- WordPress selbst neu drüberbügeln Dabei tauschst du die Programmdateien von WordPress aus, also alles außer Inhalten, Bildern, Themes und Plugins. Hol dir die aktuelle deutsche Version von de.wordpress.org. Deine wp-config.php ist im Download gar nicht enthalten. Den Ordner wp-content löschst du NIEMALS, darin stecken alle Themes, Plugins und Bilder. Benenne wp-admin und wp-includes erst um, etwa in wp-admin-alt. Dann lädst du die neuen hoch und testest die Seite. Die -alt-Ordner löschst du erst, wenn alles läuft.
- Dateirechte geradeziehen Dateirechte legen fest, wer eine Datei lesen und ändern darf. Stehen sie falsch, darf der Server deine eigene Website nicht mehr öffnen. Hinter einem kritischen Fehler stecken sie aber selten. Eher fragt WordPress dann plötzlich nach FTP-Zugangsdaten. Die üblichen Startwerte sind 644 für Dateien und 755 für Ordner. Das ist ein Ausgangspunkt, kein Gesetz. Am sichersten rufst du deinen Hoster an und sagst: „bitte die Dateirechte meiner WordPress-Installation auf den Standard zurücksetzen“.
- Ein Backup einspielen Am einfachsten ist ein Wiederherstellungspunkt im Hosting-Panel, das ist ein Klick, viele Hoster haben das, und kaum jemand weiß es. Etwas aufwendiger ist die Wiederherstellen-Funktion deines Backup-Plugins, die setzt aber voraus, dass du ins Backend kommst, und am schwersten ist es, Dateien und Datenbank von Hand zurückzuspielen. Alles, was seit dem Backup dazugekommen ist, also Beiträge, Kommentare oder Bestellungen, ist danach weg. Sicher deshalb vorher trotzdem den aktuellen kaputten Stand, sonst gibt es keinen Weg zurück.
- Den Hoster-Support anschreiben In die Nachricht gehören deine Domain, seit wann der Fehler auftritt und was unmittelbar davor passiert ist, etwa ein Update oder ein PHP-Wechsel. Dazu kommen die kopierte Fehlerzeile aus dem Protokoll und alles, was du schon probiert hast. Für Server, PHP-Version und Speicherlimit ist der Hoster zuständig, für dein Plugin nicht. Das ist keine Abfuhr, sondern die normale Zuständigkeit.
Alle anderen WordPress-Fehlermeldungen, von der Datenbankverbindung bis zur Weiterleitungsschleife, habe ich im großen Überblick zu den häufigsten WordPress-Fehlern gesammelt.
Damit es nicht wieder passiert
Der kritische Fehler entsteht fast immer im selben Moment: beim unkontrollierten Update. Die gute Nachricht? Die Vorbeugung ist unspektakulär, und ein paar Angewohnheiten reichen:
- Updates kontrolliert einspielen Lass Updates nicht nachts automatisch über alles laufen, sondern spiel sie mit Backup davor und kurzem Funktionstest danach ein. Automatische Updates schaltest du im Backend unter Plugins ab, in der Zeile jedes Plugins steht ganz rechts „Automatische Updates deaktivieren“. Für WordPress selbst gilt: Sicherheitsupdates ruhig automatisch lassen, große Versionssprünge lieber von Hand.
- Eine Testkopie nutzen Das ist eine Kopie deiner Website, die nur du siehst und auf der du Updates erst ausprobierst, das Fachwort dafür ist Staging. Schau im Hosting-Panel nach einem Punkt namens Staging oder Testumgebung, bei vielen Tarifen ist das ein Klick und kostet nichts extra. Ehrlich gesagt lohnt der Aufwand bei einer kleinen Website nicht immer, da reichen Backup plus kontrolliertes Update.
- PHP-Version regelmäßig prüfen Einmal im Quartal statt einmal pro Jahrzehnt.
- Ein Twenty-Theme als Fallschirm behalten Lass immer eines der mitgelieferten Themes installiert liegen, deren Name mit Twenty anfängt. Es kostet nichts und rettet dich im Notfall, denn ohne so ein Theme funktioniert der automatische Rückfall aus Schritt 2 nicht mehr.
- Startseite aufrufen
- Eine Unterseite aufrufen
- Das Kontaktformular einmal abschicken
- Bei einem Shop einmal etwas in den Warenkorb legen
- Das Ganze einmal am Handy wiederholen
Wenn du diese Routine nicht selbst fahren willst, ist genau das der Kern unserer WordPress-Wartung: kontrollierte Updates mit Sichtprüfung, damit du die Meldung aus diesem Artikel gar nicht erst zu Gesicht bekommst.
Häufige Fragen zum kritischen Fehler
Was bedeutet „Es gab einen kritischen Fehler auf deiner Website“?
WordPress hat einen fatalen PHP-Fehler abgefangen, der die Website zum Absturz gebracht hätte, und zeigt stattdessen diese Schutzmeldung. Der Auslöser ist in den allermeisten Fällen ein Plugin- oder Theme-Konflikt nach einem Update, seltener ein erschöpftes Speicherlimit, eine unpassende PHP-Version oder beschädigte Dateien.
Ich habe keine E-Mail mit Wiederherstellungslink bekommen. Was nun?
Erst den Spam-Ordner der Admin-Adresse prüfen. Kommt wirklich nichts an (veraltete Adresse, Server verschickt keine Mails), führst du die Reparatur per FTP durch: den Ordner wp-content/plugins umbenennen, um alle Plugins zu deaktivieren, danach gegebenenfalls das Theme auf ein Standard-Theme zurücksetzen und das Speicherlimit in der wp-config.php erhöhen.
Wie finde ich heraus, welches Plugin den kritischen Fehler verursacht?
Drei Wege: Die Wiederherstellungs-Mail benennt den Verursacher oft direkt. Im Wiederherstellungsmodus markiert WordPress die fehlerhafte Erweiterung im Backend. Und das Debug-Log (WP_DEBUG_LOG in der wp-config.php aktivieren) zeigt den Fatal Error mit Dateipfad, aus dem der Plugin- oder Theme-Name hervorgeht.
Tritt der kritische Fehler nur beim Login oder im Backend auf. Warum?
Dann stürzt eine Erweiterung ab, die nur im Admin-Bereich lädt, etwa ein Backend-Tool oder ein Dashboard-Widget. Die Lösung ist dieselbe: per Wiederherstellungslink oder FTP die Plugins deaktivieren und den Verursacher einkreisen. Dass das Frontend weiterläuft, ist dabei dein Glück, die Besucher merken nichts.
Kann ich den kritischen Fehler einfach durch ein Backup lösen?
Ein Backup vom Stand vor dem Fehler bringt die Website zwar zurück, aber die Ursache gleich mit: Beim nächsten Update desselben Plugins passiert dasselbe nochmal. Besser: Verursacher identifizieren (Mail, Wiederherstellungsmodus oder Debug-Log), dann gezielt deaktivieren oder ersetzen. Das Backup bleibt der Rettungsanker für den Fall, dass bei der Reparatur etwas schiefgeht.
Was ist der Unterschied zwischen weißer Seite und „kritischer Fehler“?
Technisch dasselbe Problem, ein fataler PHP-Fehler. Neuere WordPress-Versionen fangen viele dieser Abstürze ab und zeigen statt des leeren Bildschirms die Meldung „Es gab einen kritischen Fehler auf deiner Website“, inklusive einer E-Mail mit Wiederherstellungslink an die Admin-Adresse. Siehst du diese Meldung, ist der Wiederherstellungsmodus aus der Mail dein schnellster Weg.
Wie komme ich ins Backend, wenn alles weiß ist?
Gar nicht, und das brauchst du auch nicht: Die Reparatur läuft per FTP. Benenne den Ordner wp-content/plugins um, um alle Plugins zu deaktivieren, oder den Ordner deines aktiven Themes, um aufs Standard-Theme zurückzufallen. In den meisten Fällen ist das Backend danach sofort wieder erreichbar. Wichtig: Öffne im Backend einmal die Seite Plugins, solange der Ordner noch umbenannt ist. Erst dadurch trägt WordPress die Plugins wirklich aus. Benennst du vorher zurück, sind alle wieder aktiv.
