Kritischer Fehler in WordPress: Ursachen finden und die Website reparieren

Ein kritischer Fehler in WordPress bedeutet, dass die Verarbeitung einer Seite abgebrochen wurde. Statt deiner Inhalte erscheint nur noch eine Fehlermeldung. Das kann die gesamte Website betreffen – oder nur einen bestimmten Aufruf, etwa ein Formular oder die Anmeldung. Mit einer geordneten Fehlersuche lässt sich eingrenzen, welche Komponente den Abbruch verursacht und welche Reparatur wirklich hilft.

Dieser Leitfaden zeigt dir, wie der Fehler entsteht, wie du wieder Zugang bekommst und wie du anschließend prüfst, ob deine Website vollständig funktioniert.

Wie entsteht ein kritischer Fehler in WordPress?

WordPress setzt eine Seite aus vielen Bausteinen zusammen: dem WordPress-Kern, aktiven Plugins, dem Theme und eventuell individuell ergänztem Code. Diese Bausteine laufen auf dem Server überwiegend mit PHP. Fordert beispielsweise ein Plugin eine nicht verfügbare Funktion an, kann PHP die Ausführung nicht fortsetzen. WordPress zeigt dann unter Umständen den Hinweis auf einen kritischen Fehler.

Ein vereinfachtes Beispiel: Ein individuell programmiertes Seitentemplate ruft eine Funktion eines Zusatzplugins auf. Wird dieses Plugin deaktiviert, fehlt die Funktion beim nächsten Seitenaufruf. Das Template bricht ab, obwohl WordPress selbst unverändert ist. Ähnlich können inkompatible Schnittstellen, falsche Datentypen oder unvollständige Updates einen Abbruch auslösen.

• Plugin-Konflikte: Zwei Erweiterungen erwarten unterschiedliche Voraussetzungen oder beeinflussen denselben Ablauf.
• Theme und eigener Code: Ein fehlerhaftes Snippet oder eine Änderung an der functions.php verhindert die Ausführung.
• Geänderte Serverumgebung: Nach einem PHP-Wechsel ist veralteter Code möglicherweise nicht mehr kompatibel.
• Fehlende Dateien: Ein unterbrochener Upload oder ein unvollständiges Update kann benötigte Programmdateien zurücklassen.
• Erschöpfte Ressourcen: Ein Vorgang benötigt mehr Arbeitsspeicher, als PHP verwenden darf.

Die Meldung allein verrät die Ursache noch nicht. Sie beweist auch keinen Hackerangriff. Unbekannte Administratoren, unerwartete Weiterleitungen oder fremde PHP-Dateien sind dagegen Gründe, zusätzlich die Sicherheit der Installation untersuchen zu lassen.

Vor der Reparatur: Zustand sichern und Änderungen eingrenzen

Notiere die betroffene Adresse, den Zeitpunkt und die letzte bekannte Änderung. War unmittelbar vorher ein Update, ein neuer Code-Schnipsel oder eine Hosting-Umstellung erfolgt? Prüfe auch, ob Startseite, Anmeldung und einzelne Unterseiten unterschiedlich reagieren.

Sichere vor Eingriffen Dateien und Datenbank beziehungsweise lass den Hoster einen aktuellen Sicherungsstand erstellen. Bewahre vorhandene Fehlerprotokolle auf. Auch der defekte Zustand kann bei der Diagnose helfen. Ändere danach möglichst nur eine Sache auf einmal und halte fest, was sich dadurch verändert.

Bei einem laufenden Shop sollten Eingriffe abgestimmt erfolgen. Das Abschalten von Plugins kann Zahlungsarten, Versandregeln oder Buchungsfunktionen verändern. Nutze für die Untersuchung möglichst eine abgeschirmte Staging-Kopie.

Das Fehlerprotokoll liefert den entscheidenden Hinweis

Sieh zuerst im Hosting-Kundenmenü nach einem PHP-Fehlerprotokoll. Suche nach dem Zeitpunkt des fehlgeschlagenen Aufrufs. Entscheidend sind Fehlertyp, Dateipfad und Aufrufkette. Eine im Protokoll genannte Datei ist ein Ausgangspunkt für die Untersuchung; sie muss nicht die eigentliche Ursache enthalten.

Typische Meldungen helfen bei der Einordnung:

• Uncaught TypeError: Ein Wert hat einen unerwarteten Datentyp. Prüfe die beteiligten Komponenten und ihre Kompatibilität.
• Call to undefined function: Eine benötigte Funktion fehlt. Möglicherweise ist eine Erweiterung inaktiv oder eine Abhängigkeit nicht vorhanden.
• Parse error oder syntax error: Der PHP-Code enthält einen Syntaxfehler. Prüfe zuletzt bearbeitete Dateien und die angegebene Zeile samt Umgebung.
• Failed opening required: Eine benötigte Datei kann nicht geladen werden. Kontrolliere Dateibestand, Pfade und Berechtigungen.
• Allowed memory size … exhausted: Das Speicherlimit wurde erreicht. Untersuche den auslösenden Vorgang und den tatsächlichen Speicherbedarf.

Fehlt ein brauchbares Hosting-Protokoll, lässt sich vorübergehend das WordPress-Debugging nutzen. Bearbeite dafür die vorhandenen Definitionen in der wp-config.php; füge dieselben Konstanten nicht mehrfach ein. Der Abschnitt gehört vor die Zeile, die zum Beenden der Bearbeitung auffordert:

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

Rufe die betroffene Seite einmal auf und kontrolliere anschließend wp-content/debug.log. Bevorzuge eine Testumgebung; auf der produktiven Website sollte diese Diagnose kurz bleiben. Danach Debugging und Logging wieder deaktivieren und die Protokolldatei nach sicherer Aufbewahrung entfernen. Protokolle können sensible Informationen enthalten. Die Einstellungen sind in der offiziellen WordPress-Dokumentation zum Debugging beschrieben.

Wieder Zugang zum Backend bekommen

Prüfe das Postfach der administrativen Website-Adresse einschließlich Spam-Ordner. WordPress kann bei bestimmten schweren Fehlern eine Nachricht mit einem besonderen Anmeldelink versenden. Über diesen Link lässt sich der Wiederherstellungsmodus öffnen.

Dort werden betroffene Plugins oder Themes für deine Sitzung pausiert. Das verschafft dir Zugang für die Reparatur, behebt den Fehler aber noch nicht automatisch für Besucher. Deaktiviere die identifizierte Erweiterung regulär oder spiele eine geprüfte Korrektur ein. Verlasse anschließend den Wiederherstellungsmodus und teste die öffentliche Website. Weitere Einzelheiten erklärt die WordPress-Hilfe zum Wiederherstellungsmodus.

Kommt keine Nachricht an, brauchst du nicht auf sie zu warten: Nutze den Dateimanager deines Hosters oder einen SFTP-Zugang. Benenne gezielt den Ordner des verdächtigen Plugins unter wp-content/plugins/ um, beispielsweise von beispiel-plugin in beispiel-plugin-pausiert. Lösche den Ordner nicht.

Ist die Ursache noch unbekannt, kann die vorübergehende Umbenennung des gesamten normalen Plugin-Verzeichnisses beim Eingrenzen helfen. Rufe danach im erreichbaren Backend die Plugin-Verwaltung auf, bevor du den ursprünglichen Ordnernamen wiederherstellst. Prüfe den Aktivierungsstatus und aktiviere benötigte Plugins kontrolliert einzeln. Must-Use-Plugins unter mu-plugins und spezielle Drop-ins werden dadurch nicht ausgeschaltet.

Die passende Reparatur auswählen

Bei einem Plugin-Problem prüfst du verfügbare Korrekturen, Abhängigkeiten und Kompatibilitätsangaben. Teste das Update mit der vorhandenen WordPress-, PHP- und Theme-Konfiguration. Ein deaktiviertes Plugin kann eine sinnvolle Zwischenlösung sein; benötigte Funktionen müssen anschließend bewusst wiederhergestellt werden.

Bei einem Theme-Problem kann ein Wechsel auf ein installiertes, kompatibles Standard-Theme die Diagnose unterstützen. Führe ihn bevorzugt auf Staging aus, da sich Darstellung und Funktionen verändern. Bleibt der Fehler dort aus, untersuche das bisherige Theme einschließlich Child-Theme und eigener Anpassungen.

Bei eigenem Code nimmst du die letzte Änderung gezielt zurück oder korrigierst sie anhand des Protokolls. Bearbeite WordPress-Kerndateien nicht als schnelle Umgehung. Fehlerhafte Anpassungen gehören in ihrem eigentlichen Ursprung behoben.

Bei Speicherproblemen klärst du mit dem Hoster das wirksame PHP-Limit. Eine Erhöhung kann bei legitimem Mehrbedarf helfen, löst aber weder Endlosschleifen noch unnötig große Datenverarbeitung. Ohne entsprechenden Protokolleintrag ist mehr Speicher keine begründete Reparatur.

Bei fehlenden Dateien stelle die betroffene Komponente aus einer vertrauenswürdigen Quelle vollständig wieder her. Sichere eigene Änderungen zuvor. Prüfe bei einem PHP-Wechsel außerdem, welche Versionen alle eingesetzten Komponenten unterstützen; verwende keine nicht mehr sicherheitsgepflegte PHP-Version als Dauerlösung.

Wann hilft ein Backup?

Eine Wiederherstellung kann sinnvoll sein, wenn die Korrektur anders nicht zeitnah gelingt und ein geeigneter Sicherungsstand vorliegt. Entscheide dabei getrennt über Dateien und Datenbank. Ein älterer Datenbankstand kann neuere Bestellungen, Anfragen und redaktionelle Änderungen überschreiben.

Kläre deshalb zuerst, welche Daten seit der Sicherung hinzugekommen sind und wie sie erhalten bleiben. Prüfe anschließend auch den Auslöser: Wird dieselbe fehlerhafte Änderung erneut eingespielt, kann der Ausfall zurückkehren.

Nach der Reparatur: mehr als die Startseite testen

Öffne die Website nach dem Leeren betroffener Caches in einem privaten Browserfenster. Kontrolliere die ursprünglich fehlerhafte Adresse und wichtige Abläufe:

• Anmeldung und Bearbeitung im Backend
• Kontaktformular einschließlich tatsächlichem Nachrichteneingang
• Suche, Navigation und wichtige Unterseiten
• Bei Shops: Warenkorb, Versand und abgestimmte Testbestellung
• Fehlerprotokoll auf neue Abbrüche

Dokumentiere die Ursache, die ausgeführte Korrektur und offene Einschränkungen. Prüfe größere Updates und PHP-Umstellungen künftig auf einer Testkopie. Dazu gehören aktuelle Sicherungen und eine administrative E-Mail-Adresse, deren Postfach tatsächlich gelesen wird.

Unterstützung bei einem kritischen WordPress-Fehler

Wenn wichtige Geschäftsabläufe ausfallen oder die Ursache unklar bleibt, hilft eine gezielte technische Untersuchung. Für die erste Anfrage sind Website-Adresse, Zeitpunkt, genaue Fehlermeldung und letzte Änderungen nützlich. Übermittle Zugangsdaten erst über einen abgestimmten sicheren Weg.

Über unseren Kontakt kannst du die Untersuchung deiner Website anfragen. Für die regelmäßige technische Betreuung findest du weitere Informationen zur WordPress-Wartung. Bei konkreten Anzeichen eines Angriffs lies außerdem unseren Beitrag WordPress Malware gefunden – was kann ich jetzt tun?

Stand: 12. November 2026. Thematischer Ausgangspunkt: Ratgeber von Florian Salman zum kritischen WordPress-Fehler. Eigenständig verfasster Beitrag mit ergänzenden Diagnose- und Prüfschritten. Das Beitragsbild ist eine KI-generierte Illustration.