WordPress: Kritischer Fehler auf der Website — Ursachen und Lösung Schritt für Schritt

Die Meldung „Es gab einen kritischen Fehler auf deiner Website” (in älteren Übersetzungen „Auf dieser Website ist ein kritischer Fehler aufgetreten”) ist WordPress’ höfliche Art zu sagen: Irgendein PHP-Code ist abgestürzt, und ich zeige lieber diesen Satz als eine leere Seite. Was abgestürzt ist, verrät sie nicht. Das steht woanders — und dorthin führt dieser Beitrag, in der Reihenfolge, in der wir selbst vorgehen, wenn ein solcher Anruf hereinkommt.

Was die Meldung bedeutet — und was nicht

Seit WordPress 5.2 gibt es einen Absturzfänger: Stürzt PHP ab, fängt WordPress den Fehler ab, zeigt die bekannte Meldung und schreibt sich, wenn möglich, eine Notiz, welches Plugin oder Theme es war. Vorher sah man den berühmten weißen Bildschirm. Technisch ist beides dasselbe — ein Fatal Error, also ein Abbruch, bei dem PHP nicht weiterlaufen kann.

Drei Dinge, die die Meldung nicht bedeutet:

• Kein Hinweis auf einen Hack. In den allermeisten Fällen steckt ein Update dahinter, kein Angreifer. Es gibt aber Anzeichen, bei denen Sie aufhören sollten zu reparieren — dazu unten mehr.
• Kein Datenverlust. Die Inhalte liegen in der Datenbank und sind von einem PHP-Abbruch nicht betroffen. Es wird nichts gelöscht, es wird nur nichts mehr angezeigt.
• Kein Grund, WordPress neu zu installieren. Der Kern ist selten die Ursache. Wer ihn überschreibt, verliert die Spur zum eigentlichen Verursacher.

Erstdiagnose in 60 Sekunden

Bevor Sie irgendetwas ändern: drei Adressen aufrufen, das grenzt die Ursache schon stark ein.

Was Sie sehen	Was das heißt	Wo Sie weitermachen
Startseite tot, /wp-admin/ tot	Ein Plugin, das überall lädt, oder der Kern	Schritt 1, die Notfallmail kommt hier am ehesten
Startseite tot, /wp-admin/ läuft	Eher das Theme oder ein reines Frontend-Plugin	Schritt 2, und im Backend unter Design das Theme testweise wechseln
Nur eine einzelne Seite tot	Ein Baustein auf genau dieser Seite, oft aus dem Page-Builder	Schritt 2, danach die Seite im Builder öffnen
Alles tot, auch nach Plugin-Ausbau	Hosting, PHP-Version, Speicher oder ein abgebrochenes Update	Die Tabelle der Fehlermeldungen weiter unten

Prüfen Sie dabei mit einem frisch geleerten Cache oder in einem privaten Fenster. Ein Caching-Plugin oder der Hoster-Cache liefert sonst minutenlang die alte Fehlerseite aus, obwohl die Reparatur längst gewirkt hat — das kostet regelmäßig eine halbe Stunde Suche am falschen Ende.

Der Notfall-Ablauf in acht Schritten

Wer es eilig hat, arbeitet diese Liste von oben nach unten ab. Jeder Schritt wird unten ausführlich erklärt.

1. Startseite und /wp-admin/ im privaten Fenster aufrufen — was lebt noch?
2. Ins Postfach der Administrator-Adresse sehen: Kam eine Mail von WordPress?
3. Wenn ja: Link anklicken, das benannte Plugin deaktivieren, Seite prüfen.
4. Wenn nein: Fehlerprotokoll einschalten oder das Protokoll beim Hoster öffnen.
5. Die letzte Fatal error-Zeile lesen — sie nennt Ordner, Datei und Zeile.
6. Den Verursacher stilllegen: Ordner umbenennen oder per WP-CLI deaktivieren.
7. Alle Seitentypen prüfen, Caches leeren, Debug-Zeilen wieder entfernen.
8. Ursache klären: Update des Herstellers, Ersatz oder PHP-Version anpassen.

Was Sie nicht tun sollten, bevor Schritt 5 erledigt ist: WordPress neu installieren, ein Backup einspielen oder alle Plugins auf einmal löschen. Alle drei verwischen die Spur zum eigentlichen Verursacher — und beim Backup verlieren Sie zusätzlich alles, was seither passiert ist.

Schritt 1: Die Notfallmail und der Wiederherstellungsmodus

Beim ersten Auftreten schickt WordPress eine Mail an die Administrator-Adresse (Einstellungen → Allgemein) mit dem Betreff „Auf deiner Website gibt es ein technisches Problem”. Darin stehen zwei wertvolle Dinge: der Name des Plugins oder Themes, das abgestürzt ist, und ein Link, der Sie in den Wiederherstellungsmodus einloggt — eine Sonderanmeldung, in der genau dieser Verursacher pausiert ist.

Das ist in gut der Hälfte der Fälle schon die ganze Reparatur: Link klicken, Plugin deaktivieren, Seite prüfen, fertig.

Drei Gründe, warum die Mail ausbleibt — und alle drei bedeuten nicht, dass Ihre Seite anders kaputt ist als beschrieben:

1. Der Fehler passiert nur im Frontend. WordPress verschickt die Mail nur, wenn der Absturz in einem geschützten Bereich auftritt: Backend, Login, Cron. Eine Seite, die ausschließlich beim Besucher abstürzt, erzeugt die Fehlerseite, aber weder Mail noch Wiederherstellungsmodus. Rufen Sie in diesem Fall einmal /wp-admin/ auf — stürzt es dort auch ab, ist die Mail danach oft da.
2. Der Mailversand der Seite ist kaputt. Sehr verbreitet und meist unbemerkt, weil niemand testet, ob Kontaktformulare wirklich ankommen (dazu unser Beitrag WordPress-Mails landen im Spam).
3. Die Sperre greift. Pro Fehler und Tag verschickt WordPress höchstens eine Mail. Beim zweiten Anlauf am selben Tag kommt also nichts mehr.

Der Link aus der Mail gilt außerdem nur 24 Stunden und nur einmal. Eine alte Mail von gestern nützt nichts mehr.

Schritt 2: Die echte Fehlermeldung holen

Kommt keine Mail, holen Sie sich die Meldung selbst. Dafür brauchen Sie Zugriff auf die Dateien: per FTP, über den Dateimanager im Kundenmenü des Hosters oder per SSH. Öffnen Sie wp-config.php und ergänzen Sie oberhalb der Zeile /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );   // Fehler NICHT den Besuchern zeigen

Danach die Seite einmal aufrufen und wp-content/debug.log ansehen. Dort steht jetzt der eigentliche Fehler:

PHP Fatal error: Uncaught Error: Call to undefined function
muster_slider_render_slides() in
/var/www/html/wp-content/plugins/muster-slider-pro/muster-slider-pro.php:14

So lesen Sie diese Zeile: Nach wp-content/ steht, wo der Absturz passiert ist. plugins/<name>/ heißt Plugin, themes/<name>/ heißt Theme. Die Zahl nach dem Doppelpunkt ist die Zeilennummer — bei eigenem Code führt sie direkt zum Tippfehler.

Zwei Abkürzungen für Eilige:

• Der Hoster hat das Protokoll meist schon. Im Kundenmenü unter „Logs” oder „Fehlerprotokoll” steht derselbe Eintrag, ganz ohne Dateiänderung.
• Fehler direkt im Browser sehen: define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); zusammen mit WP_DEBUG_DISPLAY auf true schaltet den Absturzfänger ab, und die Seite zeigt statt des höflichen Satzes die rohe Meldung. Nur kurz verwenden — solange das aktiv ist, sehen auch Besucher den internen Pfad Ihrer Installation.

Wichtig: Entfernen Sie die Debug-Zeilen hinterher wieder. debug.log wächst sonst unbegrenzt und ist, wenn der Ordner nicht geschützt ist, öffentlich abrufbar.

Beim Hoster: Protokoll finden, PHP umstellen

Die Menüs heißen überall etwas anders, aber es gibt sie überall. Die beiden Dinge, die Sie brauchen, sind das Fehlerprotokoll und die PHP-Version.

Hoster	Fehlerprotokoll	PHP-Version
IONOS	im Hosting-Menü unter „Logfiles”, außerdem als Datei im Paket	je Domain im Hosting-Menü umstellbar
Strato	Protokolldateien im Ordner logs/ per FTP	in der Paketverwaltung je Domain
All-inkl	im KAS unter „Statistik”, dazu logs/ per FTP	im KAS je Domain
Hetzner (konsoleH)	unter „Statistiken/Logfiles”	in den Einstellungen je Domain
Plesk oder cPanel	„Logs” beziehungsweise „Errors”	„PHP-Einstellungen” je Abonnement
Managed WordPress (Raidboxes, Mittwald)	im eigenen Dashboard je Installation	im Dashboard, oft mit Testlauf davor

Zwei Hinweise, die viel Zeit sparen: Das Protokoll des Hosters enthält oft schon die Zeile, für die Sie sonst wp-config.php anfassen müssten. Und ein PHP-Wechsel wirkt sofort — stellt er die Seite wieder her, war die Ursache die PHP-Version und nichts anderes.

Im Protokoll steht viel — nur eine Zeile zählt

Ein frisch eingeschaltetes Protokoll ist nach wenigen Aufrufen voll. Das meiste darin ist harmlos:

• PHP Notice und PHP Warning sind Hinweise. Sie stehen auf fast jeder Seite und haben mit Ihrem Ausfall nichts zu tun.
• PHP Deprecated heißt: Ein Plugin nutzt etwas, das in einer künftigen PHP-Version wegfällt. Seit PHP 8 kommen davon hunderte Zeilen. Auch das ist kein Absturz — aber ein Hinweis darauf, welches Plugin als Nächstes Ärger macht.
• PHP Fatal error ist der Abbruch. Nur diese Zeile erklärt Ihren Ausfall.

Suchen Sie also gezielt nach Fatal, und nehmen Sie den letzten Treffer: Das Protokoll wird unten angehängt, der jüngste Eintrag steht am Ende. Der Zeitstempel am Zeilenanfang hilft beim Abgleich — passt er zu dem Moment, in dem Sie die Seite aufgerufen haben, ist es der richtige.

Schritt 3: Den Verursacher stilllegen, auch ohne Backend

Ins Backend kommen Sie bei einem kritischen Fehler oft nicht. Das ist kein Problem, denn WordPress lädt nur, was tatsächlich in wp-content/plugins/ liegt. Benennen Sie den Ordner des Plugins um, etwa von muster-slider-pro in muster-slider-pro-aus. WordPress findet es nicht mehr, deaktiviert es intern, die Seite lädt wieder.

Kennen Sie den Verursacher nicht, hilft das Halbierungsverfahren: den gesamten plugins-Ordner umbenennen. Läuft die Seite, war es ein Plugin. Ordner zurückbenennen und die Plugins im Backend in zwei Hälften einschalten — die Hälfte, in der der Fehler wiederkommt, noch einmal halbieren. Bei dreißig Plugins sind Sie so in fünf Durchgängen am Ziel statt in dreißig.

Beim Theme genauso: Ordner umbenennen, WordPress fällt auf ein Standard-Theme zurück — sofern eines installiert ist. Ist keines da, laden Sie vorher twentytwentyfive hoch, sonst tauschen Sie einen Fehler gegen den nächsten.

Wer SSH und WP-CLI hat, ist schneller:

wp plugin list --status=active --skip-plugins --skip-themes
wp plugin deactivate muster-slider-pro --skip-plugins --skip-themes

Die beiden --skip-Schalter sind hier keine Feinheit, sondern Pflicht: Ohne sie lädt WP-CLI dieselben Plugins und stirbt am selben Fehler.

So benennen Sie den Ordner konkret um

Mit einem FTP-Programm (zum Beispiel FileZilla): verbinden, in den Ordner wp-content/plugins/ wechseln, den betroffenen Ordner anklicken, F2 drücken oder Rechtsklick → Umbenennen, -aus anhängen. Fertig.

Ohne FTP-Programm: Fast jeder Hoster hat einen Dateimanager im Kundenmenü. Der kann dasselbe — Ordner suchen, umbenennen. Wenn Sie den Zugang zum Hosting nicht haben, führt kein Weg an demjenigen vorbei, der ihn hat.

Per SSH, wenn vorhanden: mv wp-content/plugins/name wp-content/plugins/name-aus.

Den Wiederherstellungsmodus wieder verlassen

Waren Sie über die Notfallmail im Wiederherstellungsmodus, beenden Sie ihn über den Knopf oben in der Leiste — sonst arbeiten Sie weiter in einer Sonderansicht, in der pausierte Plugins anders behandelt werden als im Normalbetrieb. Wichtig: Das Pausieren allein ist keine dauerhafte Lösung. Erst das Deaktivieren im Pluginmenü oder das Umbenennen des Ordners hält den Fehler auch für Besucher fern.

Wenn das Abschalten nichts ändert: die vergessenen Ecken

Manchmal ist der ganze plugins-Ordner umbenannt und die Seite bleibt tot. Dann liegt der Code an einer Stelle, die von der normalen Plugin-Verwaltung gar nicht erfasst wird. Diese vier Ecken sehen wir regelmäßig:

mu-plugins — die Muss-Plugins. Alles im Ordner wp-content/mu-plugins/ lädt WordPress immer, ohne dass es in der Pluginliste steht und ohne dass es sich abschalten lässt. Hoster legen dort gern eigene Werkzeuge ab, manche Sicherheits-Plugins ebenso. Prüfen: Ordner ansehen, verdächtige Datei umbenennen.

Drop-ins — der blinde Fleck. Dateien wie advanced-cache.php, object-cache.php oder db.php liegen direkt in wp-content/ und werden noch vor den Plugins geladen. Bleibt so eine Datei nach dem Löschen eines Caching-Plugins liegen, sucht sie Code, den es nicht mehr gibt — und die Seite stirbt, egal wie viele Plugins Sie abschalten. Im Backend stehen sie unter Plugins → Drop-in. Reparatur: Datei löschen oder umbenennen.

Das Child-Theme. Ein Fehler in der functions.php des Child-Themes überlebt jeden Theme-Wechsel im Backend, solange das Child-Theme aktiv bleibt. Hier hilft nur, den Theme-Ordner umzubenennen.

Snippet-Plugins und Server-Cronjobs. Code aus einem Snippet-Plugin liegt in der Datenbank und kommt zurück, sobald das Plugin wieder an ist. Und ein Cronjob beim Hoster kann eine Datei regelmäßig neu schreiben — dann repariert man dreimal dasselbe.

Schritt 4: Beweisen, dass der Fehler weg ist

„Sieht wieder gut aus” reicht nicht — ein kritischer Fehler kommt oft nur auf bestimmten Seitentypen. Gehen Sie nach der Reparatur diese fünf Punkte durch:

1. Startseite, ein Beitrag, eine Seite mit Formular, der Shop-Warenkorb (falls vorhanden), /wp-admin/ — jeweils im privaten Fenster.
2. Werkzeuge → Website-Zustand öffnen. Dort tauchen kritische Meldungen auf, die im Frontend unsichtbar bleiben.
3. debug.log noch einmal ansehen: Steht dort nach dem Neuladen ein neuer Fatal Error, läuft die Seite zwar, aber ein zweites Problem wartet schon.
4. Caches leeren — Plugin-Cache, Hoster-Cache, CDN.
5. Debug-Zeilen aus wp-config.php entfernen.

Kritischer Fehler, weiße Seite, 500 — was ist der Unterschied?

Nicht jede kaputte Seite ist derselbe Fall. Was im Browser steht, grenzt die Ursache schon deutlich ein.

Was Sie sehen	Was dahintersteckt	Was zuerst hilft
„Es gab einen kritischen Fehler auf deiner Website”	PHP ist abgestürzt, WordPress hat den Absturz abgefangen	Dieser Beitrag, ab Schritt 1
Komplett weiße Seite, kein Text	Derselbe Absturz, aber ohne Fänger — sehr alte Installation, abgeschalteter Handler oder ein Fehler, bevor WordPress überhaupt lädt	Fehlerprotokoll (Schritt 2), zusätzlich .htaccess prüfen
„HTTP 500 Internal Server Error” in der Server-Gestaltung	Der Fehler kommt vom Webserver, nicht von WordPress: kaputte .htaccess, PHP-Konfiguration, Prozessgrenze	Protokoll beim Hoster, .htaccess testweise umbenennen
„Fehler beim Aufbau einer Datenbankverbindung”	Zugangsdaten, Datenbankserver oder Tabellen — nicht PHP	Eigener Beitrag dazu
„Kurzzeitig nicht verfügbar wegen geplanter Wartungsarbeiten”	Ein Update ist abgebrochen, die Datei .maintenance im Hauptordner ist liegen geblieben	Datei .maintenance löschen, danach Updates einzeln nachholen
„HTTP 503 Service Unavailable”	Server überlastet oder PHP-Dienst gestoppt	Beim Hoster nachsehen, oft nach wenigen Minuten von selbst weg

Die letzten beiden sind die angenehmen Fälle: Eine liegen gebliebene .maintenance-Datei ist in zehn Sekunden gelöscht, und ein 503 verschwindet oft von allein. Wer das nicht weiß, sucht stundenlang in Plugins.

Die Fehlermeldung lesen: was welche Zeile bedeutet

Fast jeder kritische Fehler gehört zu einem dieser Muster. Die Tabelle spart das Raten.

Meldung im Protokoll	Was dahintersteckt	Nächster Schritt
Allowed memory size of … exhausted	Das PHP-Speicherlimit ist zu klein, oft bei Import, Backup oder Shop	define( 'WP_MEMORY_LIMIT', '256M' ); und beim Hoster das PHP-Limit prüfen
Call to undefined function …	Eine erwartete Funktion fehlt: halb eingespieltes Update oder fehlende PHP-Erweiterung	Plugin neu installieren, beim Hoster die PHP-Erweiterungen prüfen
Call to a member function … on null	Ein Plugin erwartet Daten, die es nicht gibt — typisch nach Datenbank- oder Theme-Wechsel	Verursacher abschalten, Hersteller-Update suchen
Uncaught TypeError: … must be of type string, null given	Klassischer PHP-8-Fall: alter Code, strenge neue Regeln	PHP-8-Migration oder Plugin ersetzen
syntax error, unexpected …	Tippfehler in eingefügtem Code, meist in functions.php	Zeilennummer im Protokoll ansteuern, Schnipsel entfernen
Cannot redeclare function …	Dieselbe Funktion zweimal geladen, etwa Snippet zusätzlich im Child-Theme	Eine der beiden Stellen entfernen
Class "…" not found	Abgebrochenes Update, vendor-Ordner unvollständig	Plugin komplett löschen und neu installieren
Maximum execution time … exceeded	Zeitlimit, oft bei Cron, Import oder Suchlauf	Limit beim Hoster anheben, auslösenden Vorgang identifizieren

Was wurde zuletzt geändert? Die Spur zurückverfolgen

Der Verursacher ist meistens die letzte Änderung vor dem Ausfall. Vier Wege, sie zu finden, auch wenn niemand etwas zugeben will:

1. Der Zeitstempel im Protokoll. Er sagt auf die Sekunde, wann es das erste Mal krachte.
2. Das Änderungsdatum der Dateien. Per SSH zeigt find wp-content -mtime -3 -type f alles, was in den letzten drei Tagen angefasst wurde. Im FTP-Programm genügt es, nach Datum zu sortieren.
3. Die Update-Historie. Viele Plugins hinterlassen ihr Änderungsprotokoll, und im Backend steht unter Aktualisierungen, was zuletzt eingespielt wurde. Automatische Updates laufen oft nachts — dann ist die Seite morgens tot, obwohl abends noch alles lief.
4. Das Protokoll des Hosters. Dort steht auch, ob am fraglichen Tag die PHP-Version gewechselt oder ein Dienst neu gestartet wurde.

Wer eine Wartung hat, spart sich das: Dort ist protokolliert, was wann aktualisiert wurde, und das Backup davor liegt bereit.

Die fünf häufigsten Ursachen in der Praxis

1. Update-Unverträglichkeit. Ein Plugin verträgt sich nach dem Update nicht mehr mit einem anderen oder mit der WordPress-Version. Häufigster Fall von allen, besonders wenn zehn Updates auf einmal eingespielt wurden — danach weiß niemand mehr, welches es war.
2. Die PHP-Version hat gewechselt. Der Hoster stellt von 7.4 oder 8.0 auf 8.2/8.3 um, und ein altes Plugin nutzt Funktionen, die es nicht mehr gibt. Die alte Version kurz zurückzustellen ist ein Aufschub, keine Lösung: alte PHP-Versionen bekommen keine Sicherheitsupdates mehr.
3. Speicherlimit erreicht. Meist bei Shops, großen Medienbibliotheken oder Backup-Läufen. Erkennbar an der memory size-Zeile.
4. Abgebrochenes Update. Speicherplatz voll oder Verbindung weg, Dateien halb ersetzt. Der Kern lässt sich sauber ersetzen — alles außer wp-content und wp-config.php.
5. Selbst eingefügter Code. Ein Schnipsel aus einem Forum in der functions.php, ein fehlendes Semikolon. Die Zeilennummer führt direkt hin.

Sonderfälle, die anders laufen

Page-Builder (Elementor, Divi, WPBakery). Stürzt nur eine einzelne Seite ab, liegt es oft an einem Widget, dessen Plugin fehlt. Der Builder speichert seine Inhalte in der Datenbank, nicht in Dateien — das Umbenennen von Ordnern hilft hier also nur für das auslösende Plugin. Mehr dazu unter Elementor-Probleme lösen und Divi-Probleme lösen.

Multisite. Ein netzwerkweit aktiviertes Plugin legt alle Seiten gleichzeitig lahm, und der Wiederherstellungsmodus gilt pro Seite. Hier führt der Weg fast immer über die Dateiebene.

Managed Hosting mit Objekt-Cache. Nach der Reparatur bleibt der Fehler manchmal noch minutenlang stehen, weil Redis oder Memcached die alte Ausgabe halten. Cache leeren gehört deshalb zur Reparatur, nicht zur Nacharbeit.

Wenn die Seite ein Shop ist

Bei einem Shop ist derselbe Fehler teurer, und er fällt später auf. Der Grund: Startseite und Kategorien werden oft aus dem Cache ausgeliefert und sehen gesund aus, während Warenkorb und Kasse — die nie zwischengespeichert werden — längst tot sind. Wer nur die Startseite prüft, hält einen laufenden Ausfall für behoben.

Was Sie nach jeder Reparatur durchgehen, in dieser Reihenfolge: ein Produkt in den Warenkorb legen, zur Kasse gehen, eine Zahlungsart auswählen, die Versandkosten prüfen und eine Testbestellung bis zur Bestätigungsseite durchziehen. Dazu die Bestell-Mails: Sie sind der Teil, der am häufigsten still kaputt ist, weil niemand sie vermisst, bevor sich ein Kunde beschwert.

Bestellungen während des Ausfalls. Der unangenehmste Fall ist die Zahlung, die durchging, während der Shop abstürzte: Beim Zahlungsanbieter ist Geld eingegangen, in WooCommerce fehlt die Bestellung. Gleichen Sie deshalb nach einem Ausfall das Konto bei PayPal, Stripe oder dem Zahlungsdienstleister mit den Bestellungen im Shop ab — Zahlungen ohne passende Bestellnummer sind genau diese Fälle, und die Kunden warten dort auf Ware, von der niemand weiß.

Typische Auslöser im Shop sind ein Zahlungs- oder Versand-Plugin nach dem Update, ein Gateway, das mit der neuen PHP-Version nicht mehr kann, und Erweiterungen, deren Lizenz abgelaufen ist und die deshalb keine Updates mehr bekommen haben. Wer einen Shop betreibt, sollte Updates deshalb nie am Wochenende und nie ohne Sichtprüfung der Kasse einspielen.

Drei Fälle, wie sie bei uns hereinkommen

Der Update-Stapel. Anruf am Montagmorgen: „Ich habe am Freitag alle Updates gemacht, jetzt ist die Seite weg.” Im Protokoll steht ein Plugin, das es seit zwei Jahren nicht mehr gibt und das mit der neuen WordPress-Version nicht mehr kann. Reparatur: Plugin abschalten, Ersatz suchen, die Funktion nachbauen. Dauer bis die Seite läuft: zehn Minuten. Dauer bis alles wieder vollständig ist: eine Stunde.

Der stille PHP-Wechsel. Die Seite lief jahrelang, niemand hat etwas angefasst — und trotzdem ist sie tot. Ursache: Der Hoster hat die PHP-Version angehoben, angekündigt in einer Mail, die niemand gelesen hat. Im Protokoll steht ein TypeError aus einem alten Theme. Kurzfristig hilft, die alte PHP-Version zurückzustellen. Richtig ist die PHP-8-Migration, denn alte PHP-Versionen bekommen keine Sicherheitsupdates mehr.

Der Schnipsel aus dem Forum. Jemand wollte die Suche anpassen und hat Code in die functions.php kopiert. Ein fehlendes Semikolon, syntax error in Zeile 412, Seite und Backend gleichzeitig tot. Reparatur: zwei Minuten, sobald man weiß, wo man hinschauen muss. Wer eigene Schnipsel einsetzt, tut das besser in einem Snippet-Plugin als direkt in der functions.php — dort lässt sich ein Fehler auch ohne Dateizugriff wieder abschalten.

Wann Sie aufhören sollten

Zwei Situationen, in denen jeder weitere Handgriff den Schaden vergrößert:

Verdacht auf Einbruch. Im Protokoll stehen Dateien, die Sie nicht kennen, das abgestürzte Plugin haben Sie nie installiert, oder im Ordner liegen Dateien mit zufälligen Namen und frischem Datum. Dann ist der kritische Fehler nur das Symptom, und jede Reparatur verwischt Spuren. Was Sie stattdessen prüfen, steht in WordPress gehackt erkennen.

Kein aktuelles Backup und die Suche führt in die Datenbank. Solange nur Dateien im Spiel sind, ist jeder Schritt umkehrbar. Ab der ersten Datenbankänderung ohne Sicherung ist er es nicht mehr.

Bevor der Kunde anruft: merken, dass die Seite weg ist

Der unangenehmste Teil eines Ausfalls ist selten der Ausfall selbst, sondern die Frage „seit wann eigentlich?”. Eine Seite, die freitagabends stirbt und montags auffällt, kostet ein Wochenende voller Anfragen, die nie ankamen — und bei einem Shop den Umsatz gleich mit.

Was hilft, ist banal: eine Überwachung, die alle paar Minuten die Startseite aufruft und meldet, wenn statt HTTP 200 etwas anderes kommt. Kostenlose Dienste reichen dafür. Wichtig ist nur, dass die Meldung bei jemandem ankommt, der reagieren kann — eine Mail an ein Postfach, das niemand liest, ist keine Überwachung.

Bei unseren Wartungskunden läuft das mit: Wir sehen den Ausfall, bevor der Kunde ihn meldet, und in vielen Fällen ist er repariert, bevor jemand anruft.

Updates testen, bevor sie live gehen

Die häufigste Ursache für einen kritischen Fehler ist ein Update, das direkt auf der laufenden Seite eingespielt wurde. Das lässt sich vermeiden, und es ist weniger Aufwand, als die meisten denken.

Wer eine Testumgebung hat, ohne es zu wissen. Managed-WordPress-Anbieter liefern sie mit, bei Plesk gibt es die Funktion zum Klonen einer Website, und für alle anderen gibt es Plugins, die eine Kopie in einem Unterverzeichnis anlegen. Eine Kopie ist in wenigen Minuten erzeugt.

Der Ablauf, der sich bewährt hat: Kopie ziehen, dort alle Updates einspielen, dann fünf Seiten ansehen — Startseite, ein Beitrag, das Kontaktformular, eine Seite aus dem Page-Builder und, falls vorhanden, die Kasse. Läuft alles, spielen Sie dieselben Updates live ein, in Blöcken von drei bis fünf, mit kurzem Blick dazwischen. Bricht dann doch etwas, wissen Sie sofort, welcher Block schuld war.

Was eine Testumgebung nicht kann. Sie bildet nicht alles ab: Zeitgesteuerte Aufgaben laufen dort anders, Zahlungsanbieter arbeiten im Testmodus, und manche Lizenzen hängen an der Domain und lassen sich in der Kopie nicht aktivieren. Eine Testumgebung ersetzt also weder das Backup davor noch die Sichtprüfung danach — sie verschiebt nur den Absturz an eine Stelle, an der ihn kein Kunde sieht.

Damit es nicht wieder passiert

Ein kritischer Fehler ist fast nie Zufall, sondern das Ergebnis einer Update-Routine, die keine ist. Was zuverlässig hilft:

• Backup vor dem Update, nicht danach, und nicht auf demselben Server.
• Updates in Blöcken statt alle auf einmal, mit kurzer Sichtprüfung dazwischen — so wissen Sie im Fehlerfall sofort, welches Update es war.
• PHP aktuell halten, damit kein Sprung über zwei Hauptversionen ansteht.
• Weniger Plugins. Jedes Plugin ist ein möglicher Absturz. Die Frage „was bricht zusammen, wenn das hier verschwindet” ist eine gute Jahresroutine.

Was der Prüfbericht enthält

Bei uns endet eine Reparatur nicht mit „läuft wieder”. Sie bekommen schriftlich, was der Auslöser war, welche Zeile im Protokoll ihn belegt, was wir geändert haben und was noch offen ist — zum Beispiel ein Plugin, das ersetzt gehört, oder eine PHP-Version, die bald abläuft. Das ist kein Beiwerk: Ohne Beleg wiederholt sich derselbe Fehler beim nächsten Update.

Genau diese Routine nehmen wir Kunden in der WordPress-Wartung ab: Backup vor jedem Update, Sichtprüfung danach, und wenn doch etwas bricht, merken wir es vor dem Kunden.

Kurzes Glossar

Die Begriffe, die in Fehlermeldungen und in Hilfeforen ständig vorkommen — in einem Satz erklärt.

Begriff	Was es bedeutet
PHP	Die Programmiersprache, in der WordPress geschrieben ist. Sie läuft auf dem Server, nicht im Browser des Besuchers.
Fatal Error	Ein Abbruch: PHP kann nicht weiterarbeiten und hört mitten im Seitenaufbau auf. Genau das steckt hinter „kritischer Fehler”.
Frontend / Backend	Frontend ist die Seite, die Besucher sehen. Backend ist der Verwaltungsbereich unter /wp-admin/.
Hook	Ein Haltepunkt im Ablauf von WordPress, an dem sich Plugins einklinken. Stürzt ein Plugin an einem frühen Hook ab, ist die ganze Seite tot.
mu-Plugin	„Must Use”: ein Plugin im Ordner wp-content/mu-plugins/, das immer lädt und sich im Backend nicht abschalten lässt.
Drop-in	Eine Sonderdatei direkt in wp-content/, etwa advanced-cache.php. Wird vor allen Plugins geladen und überlebt deren Deaktivierung.
Child-Theme	Ein Unterbau des Themes für eigene Anpassungen, damit ein Theme-Update sie nicht überschreibt.
FTP / SFTP	Der Dateizugang zum Webspace, etwa mit FileZilla. Damit kommt man an Ordner heran, auch wenn WordPress nicht mehr lädt.
SSH	Ein Kommandozeilenzugang zum Server. Schneller als FTP, aber nicht bei jedem Hoster im Paket enthalten.
WP-CLI	WordPress über die Kommandozeile bedienen — Plugins schalten, Updates einspielen, Datenbank sichern, ohne Backend.
Cache	Zwischenspeicher für fertige Seiten. Sorgt dafür, dass man nach einer Reparatur noch minutenlang die alte Fehlerseite sieht.
Staging	Eine Kopie der Website zum Testen. Dort wird geändert, was danach live eingespielt wird.

Und wenn es gerade jetzt brennt: Das oben Beschriebene ist genau das, was wir in der WordPress-Soforthilfe tun — mit Backup vor jedem Schritt und einem Prüfbericht danach. Eine Stunde für 99 €, Start am selben Werktag, und in den meisten Fällen ist die Seite in dieser Stunde wieder online.