Website-Fehler finden: Debugging-Checkliste für WordPress

Kritischer Fehler, 500er oder Datenbankfehler? Die 10-Schritte-Checkliste findet die Ursache systematisch: Logs lesen, Plugin-Bisektion in 4–5 Runden statt 20.

Montagmorgen, 8:40 Uhr. Du willst eine Kleinigkeit auf deiner Website ändern und siehst stattdessen: "Es gab einen kritischen Fehler auf deiner Website." Keine Fehlernummer, kein Hinweis auf die Ursache. Das Backend lädt auch nicht mehr, und um 11 Uhr schaut ein Interessent auf dein Angebot.

In dieser Situation fangen die meisten Site-Betreiber an zu raten: Cache leeren, ein Plugin deaktivieren, einen Forum-Tipp ausprobieren, zur Sicherheit noch ein Reparatur-Plugin installieren. Drei Stunden später ist die Site immer noch down, aber jetzt weiß niemand mehr, was alles verändert wurde. Dieser Artikel gibt dir das Gegenteil: einen festen Diagnose-Workflow von Symptom über Test zu Fix, den du jedes Mal in derselben Reihenfolge abarbeitest.

Erst dokumentieren, dann sichern, dann anfassen

Bevor du das erste Plugin deaktivierst, beantworte drei Fragen schriftlich. Wie lautet die exakte Fehlermeldung, Wort für Wort oder als Screenshot? Seit wann tritt der Fehler auf? Und was wurde zuletzt an der Site geändert?

Die dritte Frage ist die wichtigste. In den Reparatur-Fällen, die bei uns landen, korreliert der Fehler in den meisten Fällen mit der letzten Änderung: ein Plugin-Update am Vorabend, ein neu installiertes Theme, ein PHP-Versionswechsel, den der Hoster automatisch durchgeführt hat. Auch Änderungen, die du nicht selbst gemacht hast, zählen. Auto-Updates laufen nachts, und Hoster heben PHP-Versionen ohne Rückfrage an. Wer die letzte Änderung kennt, hat einen Hauptverdächtigen, bevor das erste Log geöffnet ist.

Hilfreich ist außerdem ein dauerhaftes Änderungsprotokoll: ein simples Dokument, in dem du Updates, neue Plugins und Konfigurationsänderungen mit Datum festhältst. Beim nächsten Fehler beantwortet es die Frage nach der letzten Änderung in Sekunden. Wer die Wartung ausgelagert hat, sollte ein solches Protokoll vom Dienstleister bekommen.

Danach, und zwar vor jedem Eingriff: Backup ziehen. Das wirkt widersinnig bei einer Site, die gerade kaputt ist. Der Grund: Wenn beim Debugging etwas schiefgeht, etwa eine Datenbank-Reparatur mit Nebenwirkungen oder eine versehentlich gelöschte Datei, willst du auf den Stand von vor 10 Minuten zurück, nicht auf den von letzter Woche. Dateien sicherst du per FTP oder über den Dateimanager im Hosting-Panel, die Datenbank per Export in phpMyAdmin. Wie du Backups dauerhaft automatisierst, steht in unserem Guide zu automatischen Backups für WordPress.

Symptom, wahrscheinlichste Ursache, erster Test

Jedes Fehlerbild hat einen Test, der die Ursache am schnellsten eingrenzt. Die Tabelle ist deine Abkürzung; die Details zu jedem Fehlerbild folgen weiter unten.

Symptom	Wahrscheinlichste Ursache	Erster Test
"Es gab einen kritischen Fehler"	PHP Fatal Error durch Plugin oder Theme	Recovery-Mail öffnen, debug.log lesen
500 Internal Server Error	Korrupte .htaccess oder Plugin-Konflikt	Server-Error-Log im Hosting-Panel
"Fehler beim Aufbau einer Datenbankverbindung"	Falsche Zugangsdaten oder DB-Server down	wp-config.php mit Panel-Daten abgleichen
404 auf allen Unterseiten, Startseite läuft	Defekte Rewrite-Regeln	Permalinks neu speichern
Browser-Warnung, Schloss-Symbol fehlt	Mixed Content nach HTTPS-Umstellung	DevTools-Console (F12)
"Allowed memory size exhausted"	WP-Memory-Limit von 40 MB erreicht	WP_MEMORY_LIMIT in wp-config.php prüfen
Diffuse Aussetzer ohne klare Meldung	Plugin-Konflikt	Troubleshooting Mode + Bisektion
Fatal Error direkt nach PHP-Update	Plugin nutzt entfernte PHP-Funktionen	PHP-Version im Panel zurückstellen
Komplett weiße Seite	White Screen of Death	Eigener WSOD-Guide
Spam-Redirects, fremde Admin-User	Site wurde gehackt	Soforthilfe in 7 Schritten

Dein Werkzeugkasten: Logs, Debug-Modus, DevTools

WordPress sagt dir, was kaputt ist. Du musst nur die Stellen kennen, an denen es das tut.

WP_DEBUG: das Fehlerprotokoll aktivieren

Der Debug-Modus schreibt jeden PHP-Fehler in eine Logdatei. Öffne die wp-config.php im Hauptverzeichnis deiner Installation und füge diese Zeilen vor dem Kommentar "That's all, stop editing!" ein:

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

Die ersten beiden Zeilen aktivieren das Logging in die Datei debug.log. Die letzten beiden verhindern, dass Fehlermeldungen für Besucher sichtbar auf der Seite erscheinen, denn die enthalten Serverpfade und Plugin-Namen. Rufe danach die fehlerhafte Seite einmal auf, damit der Fehler ins Log geschrieben wird.

So liest du das Log: Eine typische Zeile lautet "PHP Fatal error: Uncaught Error: Call to undefined function xyz() in /var/www/html/wp-content/plugins/beispiel-plugin/init.php on line 42". Drei Informationen daraus zählen. Der Fehlertyp sagt dir die Schwere: Ein Fatal Error legt die Seite lahm, Warnings und Notices meist nicht. Der Pfad verrät das verantwortliche Plugin oder Theme. Die Zeilennummer brauchst du erst, wenn du den Fehler an den Entwickler meldest.

Kaum jemand hat auf dem Schirm, dass die debug.log per Default unter /wp-content/debug.log liegt und damit öffentlich über den Browser abrufbar ist. Sicherheits-Scanner prüfen diesen Pfad routinemäßig, weil dort Serverpfade, Plugin-Versionen und manchmal sensible Daten stehen. Lege das Log deshalb außerhalb des Webroots ab:

define( 'WP_DEBUG_LOG', '/pfad/ausserhalb/webroot/wp-debug.log' );

Und genauso wichtig: Nach dem Debugging stellst du alle Werte zurück auf false. Der Debug-Modus ist ein Diagnose-Werkzeug, kein Dauerzustand für Live-Sites.

Server-Error-Log: funktioniert auch, wenn WordPress nicht mehr bootet

Bei einem 500er oder einem Fehler so früh im Ladevorgang, dass WordPress selbst nichts mehr loggen kann, hilft das Error-Log des Webservers. Du findest es im Hosting-Panel, je nach Anbieter unter "Error Log", "Logs" oder "Protokolle". Dort stehen Fatal Errors mit Zeitstempel und Dateipfad, auch wenn deine Site nur noch eine leere Seite ausliefert.

Recovery Mode: die Mail, die im Spam landet

Seit Version 5.2 erkennt WordPress Fatal Errors selbst und schickt dem Admin eine E-Mail mit einem Link in den Recovery Mode. Darin läuft das Backend mit pausiertem Fehlverhalten: Das Plugin oder Theme, das den Fehler verursacht, ist deaktiviert, und du kannst es regulär updaten oder entfernen.

Dabei gibt es zwei Stolperfallen. Erstens landet die Mail oft im Spam-Ordner, weil sie über die Server-Mail-Funktion rausgeht. Der Fehler tritt auf, bevor dein SMTP-Plugin überhaupt geladen wird, also greift deine sonst saubere Mail-Konfiguration hier nicht. Prüfe den Spam-Ordner aller Adressen, die als Admin-Mail hinterlegt sein könnten. Zweitens ist der Link laut offizieller WordPress-Dokumentation nur 1 Tag gültig. Ist er abgelaufen, kannst du den Recovery Mode manuell auslösen, indem du /wp-login.php?action=entered_recovery_mode an deine Domain anhängst.

Query Monitor und Health Check

Zwei Plugins gehören in jeden Debugging-Werkzeugkasten. Query Monitor zeigt dir in der Admin-Leiste Datenbank-Queries, PHP-Fehler, Hooks und welche Plugins eine Seite ausbremsen. Es ist auch das Werkzeug der Wahl, wenn die Site nicht kaputt, sondern nur langsam ist. Health Check & Troubleshooting bringt den Troubleshooting Mode mit, der bei der Plugin-Bisektion den entscheidenden Vorteil liefert.

Browser DevTools: F12 drücken

Wenn die Site lädt, aber etwas nicht funktioniert (ein Slider bleibt stehen, ein Formular sendet nicht), liegt der Fehler oft im Browser statt auf dem Server. Die DevTools öffnest du mit F12. Die Console zeigt JavaScript-Fehler und Mixed-Content-Warnungen mit der exakten URL der Problemquelle. Der Network-Tab zeigt dir rot markiert, welche Ressourcen mit 4xx- oder 5xx-Status fehlschlagen.

Die 10-Schritte-Checkliste

Arbeite die Schritte der Reihe nach ab und spring nur, wenn ein Schritt für dein Fehlerbild nicht zutrifft.

1. Symptom dokumentieren. Exakte Fehlermeldung, Zeitpunkt des ersten Auftretens, letzte Änderung an der Site (Update, neues Plugin, PHP-Wechsel durch den Hoster). Die letzte Änderung ist dein Hauptverdächtiger.
2. Backup ziehen. Dateien per FTP, Datenbank per phpMyAdmin. Erst danach wird etwas angefasst.
3. Recovery-Mail prüfen. Auch im Spam-Ordner. Der Link führt direkt zum Verursacher und ist 1 Tag gültig.
4. Logs lesen. debug.log aktivieren und auslesen, parallel das Server-Error-Log im Hosting-Panel. Die Zeile "PHP Fatal error" mit Dateipfad benennt das schuldige Plugin oder Theme.
5. Browser-Console checken. Bei Layout- oder Funktionsproblemen ohne Fatal Error: F12, Console und Network-Tab.
6. Plugin-Bisektion. Im Troubleshooting Mode oder per FTP die Plugin-Hälften gegeneinander testen, bis der Verursacher feststeht.
7. Theme testen. Auf ein Default-Theme wie Twenty Twenty-Five wechseln. Verschwindet der Fehler, liegt er im Theme.
8. .htaccess zurücksetzen. Bei 404- und 500-Fehlern: Datei umbenennen, Permalinks neu speichern, WordPress erzeugt eine frische Version.
9. Memory und PHP-Version prüfen. WP_MEMORY_LIMIT erhöhen, PHP-Version gegen die Anforderungen deiner Plugins halten.
10. Eskalieren. Wenn der Fehler wiederkehrt oder Anzeichen für einen Hack sprechen, übergibst du an einen Profi. Die Kriterien stehen im letzten Abschnitt.

Die acht häufigsten Fehlerbilder und ihre Fixes

Für den weißen Bildschirm und gehackte Sites haben wir eigene Schritt-für-Schritt-Guides: White Screen of Death und WordPress gehackt: Soforthilfe in 7 Schritten. Hier kommen die übrigen acht Fehlerbilder, jeweils mit Ursache und Fix.

1. "Es gab einen kritischen Fehler auf deiner Website"

Diese Meldung zeigt WordPress seit Version 5.2, wenn ein PHP Fatal Error auftritt. Dahinter steckt in der Regel ein Plugin oder Theme, das nach einem Update crasht oder mit deiner PHP-Version nicht zurechtkommt. Der Fix: Recovery-Mail nutzen (siehe oben), alternativ debug.log lesen. Die Zeile mit "PHP Fatal error" enthält einen Dateipfad, und wenn darin /wp-content/plugins/plugin-name/ steht, kennst du den Verursacher. Kommst du nicht mehr ins Backend, benennst du den Plugin-Ordner per FTP um, zum Beispiel von plugin-name in plugin-name-aus. WordPress deaktiviert das Plugin dann automatisch und die Site lädt wieder.

2. 500 Internal Server Error

Der 500er ist eine Sammelmeldung des Servers ohne Details. Die vier üblichen Ursachen: eine korrupte .htaccess, ein Plugin-Konflikt, erschöpftes Memory oder eine inkompatible PHP-Version. Der erste Blick gehört dem Server-Error-Log im Hosting-Panel, denn dort steht meist die konkrete Ursache. Steht dort nichts Brauchbares, setzt du die .htaccess zurück: per FTP umbenennen, dann im Backend unter Einstellungen > Permalinks einmal speichern, und WordPress schreibt eine saubere neue Datei. Bleibt der Fehler, geht es weiter mit der Plugin-Bisektion.

3. "Fehler beim Aufbau einer Datenbankverbindung"

WordPress erreicht seine Datenbank nicht. Entweder stimmen die Zugangsdaten in der wp-config.php nicht mehr (etwa nach einem Hosting-Umzug oder Passwort-Reset), der Datenbank-Server ist down, oder die Datenbank ist korrupt. Gleiche zuerst DB_NAME, DB_USER, DB_PASSWORD und DB_HOST in der wp-config.php mit den Angaben in deinem Hosting-Panel ab. Stimmen die Daten, kannst du die eingebaute Reparatur nutzen. Trage dazu in die wp-config.php ein:

define( 'WP_ALLOW_REPAIR', true );

Dann rufst du deine-domain.de/wp-admin/maint/repair.php auf und startest die Reparatur. Danach entfernst du die Zeile sofort wieder, denn die Reparatur-Seite ist ohne Login erreichbar. Solange die Konstante gesetzt ist, kann jeder Besucher sie aufrufen.

4. 404 auf allen Unterseiten, Startseite funktioniert

Wenn die Startseite lädt, aber jede Unterseite einen 404 wirft, sind die Rewrite-Regeln defekt, also die .htaccess (Apache/LiteSpeed) oder die Rewrite-Konfiguration. Der Fix ist meistens in 30 Sekunden erledigt: Einstellungen > Permalinks öffnen und ohne Änderung auf Speichern klicken. WordPress schreibt die Rewrite-Regeln dabei neu. Hilft das nicht, ist die .htaccess nicht beschreibbar oder von einem Plugin überschrieben worden, dann hilft der .htaccess-Reset aus dem 500er-Abschnitt.

5. Mixed Content: Schloss-Symbol fehlt

Nach einer HTTPS-Umstellung laden manche Ressourcen (Bilder, Skripte, Stylesheets) noch über http. Browser blockieren diese Inhalte oder zeigen Warnungen, das Schloss-Symbol verschwindet. Die DevTools-Console listet jede betroffene URL einzeln auf. Der Fix ist ein Search-Replace in der Datenbank, der alle http://deine-domain.de-Vorkommen durch https://deine-domain.de ersetzt. Das Plugin Better Search Replace erledigt das inklusive der serialisierten Daten, an denen ein manuelles SQL-Statement scheitern würde. Vorher gilt Schritt 2 der Checkliste: Datenbank-Backup. Bleiben nach dem Search-Replace einzelne Warnungen übrig, stammen die URLs meist aus fest im Theme oder in Widgets hinterlegten Links; die DevTools-Console zeigt dir auch dafür die Quelle.

6. "Allowed memory size exhausted"

WordPress gönnt sich per Default nur 40 MB PHP-Memory (64 MB bei Multisite). Das reichte 2010, aber ein modernes Theme plus WooCommerce plus Page Builder sprengt das Limit. Der Fix in der wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Die erste Konstante gilt fürs Frontend, die zweite für Admin-Bereich und rechenintensive Tasks. Wichtig: WordPress kann das Memory-Limit des Servers nicht übersteigen. Wenn dein Hosting-Tarif bei 128 MB dichtmacht, bleibt es bei 128 MB, egal was in der wp-config.php steht. Dann hilft nur ein Anruf beim Hoster oder ein Tarifwechsel. Welches Limit dein Server tatsächlich vorgibt, zeigt dir das Dashboard unter Werkzeuge > Website-Zustand > Bericht im Abschnitt Server.

7. Plugin-Konflikt mit diffusen Symptomen

Nicht jeder Fehler wirft eine Meldung. Manchmal sendet das Kontaktformular nicht mehr, der Checkout hängt, oder das Backend lädt zäh, und nichts davon taucht im Log auf. Das klassische Muster dahinter: zwei Plugins, die sich gegenseitig stören, oft nach einem Update von einem der beiden. Hier kommt der Troubleshooting Mode des Health-Check-Plugins ins Spiel, kombiniert mit der Bisektion aus dem nächsten Abschnitt.

8. Fatal Error nach PHP-Update durch den Hoster

Hoster heben PHP-Versionen regelmäßig automatisch an, und alte Plugins, die entfernte PHP-Funktionen nutzen, crashen dann mit einem Fatal Error. Du hast nichts geändert, die Site ist trotzdem down. Der Fix läuft in drei Zügen ab. Erstens stellst du die PHP-Version im Hosting-Panel temporär auf die vorherige zurück, damit die Site wieder läuft. Zweitens liest du in der debug.log nach, welches Plugin den Fatal Error wirft, und updatest oder ersetzt es. Drittens stellst du die PHP-Version wieder hoch, denn die alte Version bleibt nicht ewig verfügbar und bekommt keine Sicherheits-Patches.

Plugin-Bisektion: 20 Verdächtige, fünf Testrunden

Der naive Weg, einen Plugin-Konflikt zu finden: alle 20 Plugins einzeln deaktivieren und nach jedem testen. Das sind bis zu 20 Testrunden. Die Bisektion halbiert stattdessen: Du deaktivierst die erste Hälfte der Plugins und testest. Ist der Fehler weg, sitzt der Verursacher in der deaktivierten Hälfte; ist er noch da, in der aktiven. Die verdächtige Hälfte halbierst du erneut, und so weiter. Bei 20 Plugins bist du nach 4–5 Runden beim Schuldigen: 20, 10, 5, 3, 1.

Für die Durchführung gibt es zwei Wege:

• Troubleshooting Mode (Plugin Health Check & Troubleshooting): Deaktiviert Plugins und Theme nur für deine eigene Session. Besucher sehen die Site weiterhin normal, mit allen Plugins aktiv. Damit kannst du auf einer Live-Site mit laufendem Traffic bisektieren, ohne dass jemand etwas merkt.
• Per FTP: Wenn das Backend nicht mehr erreichbar ist, benennst du Plugin-Ordner unter /wp-content/plugins/ um. Ein umbenannter Ordner gilt für WordPress als deaktiviertes Plugin. Funktioniert immer, betrifft aber auch deine Besucher.

Bei der Bisektion lauern zwei Fallstricke. Erstens: Leere zwischen den Testrunden jedes Mal den Cache (Page Cache des Caching-Plugins, Server-Cache, im Zweifel auch den Browser-Cache), sonst testest du gegen eine zwischengespeicherte Version der Seite und ziehst falsche Schlüsse. Zweitens: Halte vor dem Start fest, welche Plugins aktiv waren, ein Screenshot der Plugin-Liste reicht. Nach der Diagnose willst du den Ausgangszustand exakt wiederherstellen, minus den Verursacher.

Ein Detail für WooCommerce-Shops und Sites mit Buchungsfunktion: Teste außerhalb der Stoßzeiten oder im Troubleshooting Mode, denn ein per FTP deaktiviertes Shop-Plugin bedeutet einen offline geschalteten Checkout.

Wann du aufhörst zu basteln

Die Checkliste löst die typischen Fehlerbilder. Es gibt aber Situationen, in denen Weiterbasteln teurer wird als Abgeben. Der Hintergrund: Laut Patchstack wurden 2025 insgesamt 11.334 neue WordPress-Sicherheitslücken registriert, 91 % davon in Plugins und nur 2 im Core. Ein wiederkehrender "Fehler" ist deshalb häufiger ein Sicherheitsproblem in einem Plugin, als man denkt.

Der grüne Balken ist kein Darstellungsfehler: 2 von 11.334 neuen Lücken betrafen den WordPress-Core. Das Risiko sitzt fast komplett in dem, was du installierst.

Übergib an einen Profi, wenn eines davon zutrifft:

• Der Fehler kehrt nach der Bereinigung wieder, obwohl du den Verursacher entfernt hast
• Du findest unbekannte Admin-User oder PHP-Dateien an Orten, wo keine hingehören, etwa in /wp-content/uploads/
• Die Google Search Console zeigt eine Sicherheitswarnung für deine Domain
• Besucher werden auf Spam-Seiten weitergeleitet, die du nie verlinkt hast
• Die Datenbank ist korrupt und die eingebaute Reparatur schlägt fehl
• Es geht um einen Shop mit Kundendaten, bei dem jeder Fehlgriff Folgen für Dritte hat

Die ersten vier Punkte deuten auf einen Hack. Dann gilt unser Guide WordPress gehackt: Soforthilfe in 7 Schritten, denn ein gehacktes System bereinigt man anders als ein kaputtes. Für alles andere gibt es unsere Website-Reparatur: Wir diagnostizieren mit genau diesem Workflow, nur mit mehr Routine und den passenden Server-Zugriffen.