Was die Meldung eigentlich bedeutet
Die Meldung erscheint, wenn PHP beim Aufbau der Seite auf einen „Fatal Error" stößt und die Ausführung abbricht. WordPress fängt diesen Fehler seit Version 5.2 über den sogenannten „Fatal Error Protection"- bzw. Recovery-Mode ab und zeigt statt einer leeren Seite die verständliche Meldung. An die im WordPress hinterlegte Admin-E-Mail geht parallel eine Nachricht mit einem speziellen Login-Link, über den du die Seite im Recovery-Mode betreten kannst — dort ist das fehlerhafte Plugin oft schon markiert. Diese E-Mail ist dein wichtigster erster Anlaufpunkt.
Prüfe die E-Mail an deine WordPress-Admin-Adresse (Betreff enthält oft „Deine Website hat ein technisches Problem"). Der enthaltene Link führt dich in den Recovery-Mode, wo du das auslösende Plugin/Theme gezielt deaktivieren kannst — ganz ohne FTP.
Die häufigsten Ursachen
In der Praxis stecken fast immer dieselben Auslöser hinter der Meldung. An erster Stelle stehen Plugin- und Theme-Konflikte, meist direkt nach einem Update. Zweithäufig ist ein Wechsel der PHP-Version durch den Hoster: Code, der unter PHP 7 lief, wirft unter PHP 8 einen Fatal Error. Ebenfalls verbreitet ist ein überschrittenes PHP-Memory-Limit sowie fehlerhafter Code in der functions.php (oft ein kopiertes Snippet aus einem Tutorial).
- Plugin-Konflikt oder Bug nach einem Plugin-Update
- Theme inkompatibel nach Theme- oder Core-Update
- PHP-Version vom Hoster gewechselt (7.x → 8.x)
- PHP-Memory-Limit überschritten
- Fehlerhaftes Snippet in der functions.php
- Beschädigte Core-Datei nach abgebrochenem Update
Schritt für Schritt zur Lösung
Arbeite die folgenden Schritte der Reihe nach ab — nach jedem Schritt die Seite neu laden. Wichtig: Bevor du an Dateien änderst, sichere den aktuellen Stand (Backup). Zuerst der einfachste Weg über den Recovery-Mode-Link aus der E-Mail. Falls du keine E-Mail hast oder nicht ins Backend kommst, brauchst du FTP-/Hosting-Zugang.
- Recovery-Mode-Link aus der E-Mail öffnen und das markierte Plugin deaktivieren
- Ohne E-Mail: per FTP den Ordner /wp-content/plugins/ zu /plugins_off/ umbenennen (deaktiviert alle Plugins). Läuft die Seite → schrittweise wieder aktivieren
- Aktives Theme per FTP umbenennen — WordPress fällt auf ein Standard-Theme zurück
- PHP-Memory-Limit erhöhen (siehe Code) und Seite testen
- Im Hosting-Panel testweise die vorherige PHP-Version einstellen
- Debug-Logging aktivieren, um die exakte Fehlerdatei und -zeile zu sehen
// in wp-config.php vor der Zeile "/* That's all, stop editing! */"
define( 'WP_MEMORY_LIMIT', '256M' );
// Debug-Log aktivieren (Fehler landen in /wp-content/debug.log)
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Das Debug-Log richtig lesen
Sobald WP_DEBUG_LOG aktiv ist, schreibt WordPress jeden Fatal Error in die Datei /wp-content/debug.log. Die letzte „Fatal error"-Zeile nennt dir Datei und Zeilennummer — und damit fast immer das verantwortliche Plugin oder Theme (der Pfad enthält den Ordnernamen, z. B. /plugins/xyz/). Das erspart dir das blinde Durchprobieren. Deaktiviere WP_DEBUG_DISPLAY im Live-Betrieb, damit Besucher keine Fehlermeldungen sehen.
Setze WP_DEBUG_DISPLAY immer auf false auf Produktivseiten. Sichtbare PHP-Fehler verraten Angreifern Pfade und Versionen — ein unnötiges Sicherheitsrisiko.
Wann du besser einen Profi holst
Wenn du keinen Zugang zu Recovery-Mode, Backend oder Server hast, wenn das Debug-Log auf tief liegende Ursachen (Datenbank, Server-Konfiguration, mehrere verkettete Fehler) zeigt oder wenn deine Seite Umsatz bringt und jede Stunde offline zählt, lohnt sich der schnelle Profi-Fix. Eine gezielte Log-Analyse führt in Minuten zur Ursache, für die ohne Erfahrung schnell ein halber Tag draufgeht.
Wir bringen deine Seite zurück — schnell.
Reaktion in unter 2 Stunden, Festpreis, Pay-after-fix. Schildere kurz dein Problem — wir kümmern uns.