Die 30-Sekunden-Einordnung

Sehen Besucher und Administratoren die Meldung „Es gab einen kritischen Fehler auf Ihrer Website“, hat WordPress einen schwerwiegenden PHP-Fehler erkannt. Notieren Sie den Wortlaut, den Zeitpunkt und die letzte Änderung. Prüfen Sie anschließend die Administrator-E-Mail-Adresse auf eine Nachricht von WordPress mit dem Betreff zur technischen Schwierigkeit.

Ein einzelner betroffener Bereich deutet eher auf ein Plugin oder Theme. Ist auch das Backend nicht erreichbar, brauchen Sie Recovery Mode, Hosting-Dateizugriff oder ein Server-Protokoll.

Vor jedem Eingriff

  • Aktuelles Backup von Dateien und Datenbank prüfen.
  • Letztes Plugin-, Theme-, WordPress- oder PHP-Update notieren.
  • Keine Zugangsdaten per normaler E-Mail versenden.
  • Bei Shop oder Buchungssystem ein Wartungsfenster einplanen.
Schwierigkeit: Einfach

Recovery-Mail und letzte Änderung prüfen

Öffnen Sie den Wiederherstellungslink nur aus der echten WordPress-Nachricht. WordPress pausiert die als fehlerhaft erkannte Erweiterung für Ihre Administratorsitzung. Prüfen Sie den genannten Fehler und deaktivieren oder aktualisieren Sie das betroffene Plugin beziehungsweise Theme kontrolliert.

Fehlt die E-Mail, prüfen Sie Spam-Ordner und die hinterlegte Administrator-Adresse. Wiederholtes Aktualisieren repariert den Fehler nicht.

Schwierigkeit: Mittel

Plugin oder Theme ohne Backend eingrenzen

Mit einem vorhandenen Hosting-Dateimanager oder SFTP-Zugang können Sie den Ordner des zuletzt geänderten Plugins unter wp-content/plugins vorübergehend umbenennen. Laden Sie die Website danach erneut. Wird sie wieder erreichbar, ist die Erweiterung ein starker Verdächtiger.

Benennen Sie nicht den gesamten wp-content-Ordner um. Dokumentieren Sie jeden Schritt und stellen Sie den ursprünglichen Namen wieder her, bevor Sie andere Ursachen testen.

Schwierigkeit: Schwer

Fehlerprotokoll kontrolliert lesen

WP_DEBUG_LOG kann PHP-Fehler in wp-content/debug.log schreiben. Auf einer öffentlichen Website darf die Ausgabe nicht sichtbar werden. Das Protokoll kann Pfade und andere sensible technische Informationen enthalten. Schalten Sie Debugging nach der Analyse wieder aus und entfernen oder schützen Sie die Logdatei.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Diese Kombination schreibt Fehler in die Logdatei, statt sie Besuchern anzuzeigen. Verwenden Sie sie nur vorübergehend und niemals ohne geschützten Dateizugriff.

Wann persönliche Hilfe sinnvoll ist

Rufen Sie an, wenn der Fehler nach einem Update die gesamte Website oder einen umsatzrelevanten Prozess blockiert, wenn Recovery Mode nicht erreichbar ist oder wenn mehrere Änderungen gleichzeitig passiert sind. Dann grenzen wir zuerst Ursache, Risiko und realistischen Umfang ein.

Häufige Fragen

Was bedeutet „Es gab einen kritischen Fehler auf Ihrer Website“?

WordPress hat einen schwerwiegenden PHP-Fehler erkannt. Häufig sind ein Plugin, ein Theme, ein Update oder eine unpassende PHP-Version beteiligt.

Kann ich die Website über den Wiederherstellungsmodus reparieren?

Oft ja. WordPress sendet bei bestimmten fatalen Fehlern einen speziellen Link an die Administrator-E-Mail. In dieser Sitzung wird die fehlerhafte Erweiterung pausiert, damit Sie sie prüfen oder deaktivieren können.

Soll ich WP_DEBUG auf einer öffentlichen Website aktivieren?

Nicht mit sichtbarer Fehlerausgabe. Protokolle können sensible technische Angaben enthalten. Aktivieren Sie Debugging nur gezielt, speichern Sie Ausgaben geschützt und schalten Sie es danach wieder aus.

Quellen

Die technischen Aussagen wurden gegen die verlinkte WordPress-Core-Dokumentation geprüft.