Kurz gesagt: Prüfe zuerst die Administrator-E-Mail und den Zeitpunkt der letzten Änderung. Ein Recovery-Link oder ein passender Eintrag im PHP-Fehlerprotokoll kann auf die betroffene Erweiterung hinweisen. Ändere anschließend gezielt eine Sache und teste die zuvor fehlerhafte Seite erneut.
Bevor du anfängst
- Fehlertext, betroffene Adresse und Uhrzeit festhalten; keine weiteren Updates starten.
- Postfach der WordPress-Administratoradresse einschließlich Spamordner prüfen.
- Klären, ob unmittelbar davor ein Plugin, Theme, PHP oder eigener Code geändert wurde.
1. Kläre, welche Teile der Website ausfallen
Öffne die Startseite, eine betroffene Unterseite und die WordPress-Anmeldung getrennt. Verwende zusätzlich ein privates Browserfenster, damit eine bestehende Anmeldung das Ergebnis nicht verfälscht. Notiere, ob der Fehler überall, nur auf einer bestimmten Seite oder erst bei einer Aktion wie dem Absenden eines Formulars auftritt.
Diese Unterscheidung spart Zeit: Ein Fehler nur im Warenkorb lenkt die Prüfung auf andere Komponenten als ein Ausfall direkt nach einer PHP-Umstellung. Dass die Startseite noch funktioniert, beweist allerdings nicht, dass WordPress gesund ist. Sie könnte aus einem Cache kommen, während neu erzeugte Seiten bereits scheitern. Ein Bildschirmfoto und die konkrete fehlerhafte Aktion sind deshalb hilfreicher als die Beschreibung „alles kaputt“.
2. Nutze den Recovery-Link, falls WordPress ihn gesendet hat
WordPress kann bei bestimmten schwerwiegenden PHP-Fehlern eine Nachricht an die hinterlegte Administratoradresse senden. Sie enthält häufig Angaben zum Fehler und einen besonderen Anmeldelink. Prüfe, ob die Nachricht wirklich zu deiner Domain und dem aktuellen Vorfall gehört. Teile den Link nicht öffentlich: Er ist für den Zugang zur Fehlerbehebung gedacht.
Im Wiederherstellungsmodus werden betroffene Komponenten für deine Sitzung pausiert. Dadurch kannst du möglicherweise das Dashboard öffnen, obwohl normale Besucher weiterhin eine Fehlermeldung sehen. Lies den Fehlerhinweis und öffne bei einem benannten Plugin „Plugins → Installierte Plugins“. Deaktiviere dort genau diese Erweiterung, wenn ihre vorübergehend fehlende Funktion vertretbar ist. Verlasse anschließend den Wiederherstellungsmodus über den angebotenen Link in der Adminleiste und teste die betroffene Seite abgemeldet. Erst dann weißt du, ob die Änderung auch Besuchern hilft.
Keine E-Mail angekommen?: Das schließt einen PHP-Fehler nicht aus. Der Versand kann ebenfalls gestört sein oder der Fehler außerhalb eines normalen Seitenaufrufs auftreten. Prüfe dann das Hosting-Fehlerprotokoll.
3. Suche den passenden Fehler statt irgendeiner Warnung
Wähle im Hosting-Kundenbereich die betroffene Website. Suche dort nach einem Bereich wie „Protokolle“, „Logs“ oder „PHP-Fehlerprotokoll“; die Bezeichnung hängt vom Anbieter ab. Rufe die kaputte Seite einmal auf und öffne danach die neuesten Einträge. Vergleiche Uhrzeit und Zeitzone mit deinem Test. Suche zunächst nach „Fatal error“ oder „Uncaught“, nicht nur nach beliebigen älteren Warnungen.
Ein Dateipfad innerhalb eines Plugin- oder Theme-Ordners ist eine Spur, aber noch kein vollständiger Beweis: Die Komponente kann auch an ungültigen Daten oder einer fehlenden Abhängigkeit scheitern. Bei Meldungen über ausgeschöpften Speicher sollte geklärt werden, welche Aktion so viel Speicher verbraucht. Das Limit immer weiter anzuheben kann den eigentlichen Fehler verdecken.
Im folgenden erfundenen Beispiel zeigt die erste Zeile auf einen Abbruch im Ordner beispiel-plugin. Die zweite Zeile ist nur ein Hinweis und für sich genommen kein Nachweis des Absturzes. Der Dateipfad liefert den genauen Ordnernamen für den nächsten gezielten Test; er ist kein Auftrag, die genannte Zeile wahllos zu löschen.
Beispiel, keine Diagnose deiner Website:
[14-Oct-2026 09:12:03 UTC] PHP Fatal error: Uncaught Error: Call to undefined function beispiel_funktion() in /website/wp-content/plugins/beispiel-plugin/start.php:42
[14-Oct-2026 09:12:04 UTC] PHP Notice: Beispiel fuer einen nicht fatalen Hinweis
4. Optional: Ein Fehlerprotokoll in einer geschützten Testkopie aktivieren
Wenn das Hostingprotokoll nicht weiterhilft, kannst du den Fehler in einer mit Zugriffsschutz versehenen Testkopie aufzeichnen. Öffne deren wp-config.php über SFTP oder den Hosting-Dateimanager und lade vorher eine Sicherung auf deinen Computer. Lege diese Sicherung nicht als öffentlich erreichbare wp-config.php.bak neben die Website.
Suche in der Datei nach WP_DEBUG, WP_DEBUG_LOG und WP_DEBUG_DISPLAY. Ändere vorhandene Definitionen; füge dieselbe Konstante nicht ein zweites Mal hinzu. Fehlende Zeilen stehen vor dem Kommentar zum Ende der Bearbeitung beziehungsweise vor der Zeile, die wp-settings.php lädt. Füge kein zusätzliches öffnendes PHP-Tag ein.
Der Pfad im Beispiel muss durch einen vom Hoster bestätigten absoluten, beschreibbaren Dateipfad außerhalb des öffentlich erreichbaren Website-Verzeichnisses ersetzt werden. Er ist kein fertiger Wert zum unveränderten Kopieren. Fehlt dir ein solcher Speicherort, nutze das Hostingprotokoll. Die Einstellung WP_DEBUG_DISPLAY auf false verhindert die normale WordPress-Fehlerausgabe im Seiteninhalt; sie schützt keine öffentlich abgelegte Protokolldatei.
- Fehler einmal nachstellen Speichere die geänderte Konfiguration der Testkopie und rufe genau die betroffene Seite auf. Lade anschließend die neu erzeugte Protokolldatei über den geschützten Dateizugang herunter. Bleibt sie aus, prüfe den Pfad und die Schreibberechtigung; ein leeres Protokoll beweist keine Fehlerfreiheit.
- Diagnose wieder ausschalten Setze die geänderten Diagnosewerte nach dem Test auf ihren vorherigen Stand zurück, üblicherweise WP_DEBUG auf false. Entferne die Diagnose-Protokolldatei vom Server, sobald du sie nicht mehr benötigst. Teile nur den relevanten Ausschnitt und schwärze personenbezogene Daten, Schlüssel und vertrauliche Pfade.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/ABSOLUTER/HOSTER-PFAD/wordpress-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );
5. Ein konkret verdächtiges Plugin vorübergehend abschalten
Sichere den aktuellen Stand, bevor du Dateien oder Einstellungen änderst. Ein vorhandenes Backup ist nur dann eine echte Rückfallebene, wenn es zur richtigen Website gehört und sich wiederherstellen lässt. Bei einem Shop müssen außerdem neue Bestellungen seit dem Sicherungszeitpunkt berücksichtigt werden.
Wenn das Dashboard erreichbar ist, nutze „Plugins → Installierte Plugins → Deaktivieren“ bei der benannten Erweiterung. Ohne Dashboard kannst du den folgenden Ablauf über SFTP oder den Dateimanager ausführen. Er ist für ein im Fehlerprotokoll identifiziertes normales Plugin gedacht. Für Themes, Must-use-Plugins oder unbekannte Ordner ist er nicht unverändert geeignet.
- Den richtigen Plugin-Ordner finden Öffne das Verzeichnis der betroffenen WordPress-Installation und darin wp-content/plugins. Vergleiche den Unterordner exakt mit dem Fehlerpfad. Im obigen Beispiel wäre das beispiel-plugin. Sichere diesen Ordner vor der Änderung. Prüfe, welche Funktionen durch sein Abschalten fehlen, etwa Zahlungen oder Zugriffsschutz.
- Nur diesen einen Ordner umbenennen Benenne beispielsweise wp-content/plugins/beispiel-plugin in wp-content/plugins/beispiel-plugin.deaktiviert um. Lösche nichts und ändere nicht den übergeordneten Ordner plugins. Öffne anschließend die zuvor kaputte Seite in einem privaten Browserfenster.
- Ergebnis festhalten und Ordnernamen zurückstellen Bleibt der Fehler gleich, stelle den ursprünglichen Ordnernamen wieder her und prüfe den nächsten passenden Protokolleintrag. Ist das Dashboard wieder erreichbar, öffne zuerst „Plugins → Installierte Plugins“, damit WordPress die fehlende Erweiterung erkennt und deaktiviert. Stelle danach den Originalnamen wieder her und kontrolliere, dass das Plugin in der Liste deaktiviert bleibt. Aktiviere es erst nach der Korrektur; sonst kann der Fehler sofort zurückkehren.
Falls zuletzt eigener Code geändert wurde: Stelle stattdessen gezielt die geänderte Datei aus der passenden vorherigen Version wieder her. Entferne nicht bloß die im Fehler genannte Zeile: Sie kann von weiterem Code abhängen. Prüfe die korrigierte Version zuerst in der Testkopie.
6. Prüfe mehr als die Startseite
Wiederhole genau die Aktion, die den Fehler ausgelöst hat. Teste anschließend Anmeldung, wichtige Unterseiten, Kontaktformular und bei einem Shop den Bestellablauf in einer geeigneten Testumgebung. Kontrolliere auch die mobile Ansicht, wenn du ein Theme oder einen Seiteneditor geändert hast. Eine erreichbare Startseite allein ist keine vollständige Entwarnung.
Vergleiche das Fehlerprotokoll vor und nach dem Test. Wenn derselbe neue Fehler nicht mehr auftritt und die benötigten Funktionen wieder arbeiten, hast du eine belastbare Zwischenlösung. Ein dauerhaft deaktiviertes benötigtes Plugin ist dagegen noch keine abgeschlossene Reparatur. Halte fest, was deaktiviert oder zurückgesetzt wurde und wie eine kompatible, gepflegte Version wieder eingesetzt werden soll.
Wann du die Fehlersuche abgeben solltest
Wenn weder ein passender Protokolleintrag noch eine letzte Änderung bekannt ist, führen weitere spontane Eingriffe häufig zu einem unübersichtlichen Zustand. Hole Unterstützung, wenn Kundendaten, Bestellungen oder mehrere gleichzeitig ausgefallene Systeme betroffen sind – oder wenn du keinen verlässlichen Rückweg hast.
Für eine erste Einschätzung reichen Website-Adresse, Fehlertext, Beginn des Problems und die letzten bekannten Änderungen. Ergänze, ob Dashboard und Hosting erreichbar sind und von wann das letzte Backup stammt. Zugangsdaten gehören nicht in ein normales Kontaktformular oder einen Screenshot. Übermittle sie erst über den dafür vorgesehenen geschützten Weg.
Häufige Fragen
Sind meine Inhalte bei einem kritischen Fehler gelöscht?
Aus der Meldung lässt sich kein Datenverlust ableiten. Häufig scheitert die Ausführung von Code, während Inhalte weiterhin in der Datenbank liegen. Sichere den vorhandenen Stand und prüfe die Ursache, bevor du eine Neuinstallation oder Wiederherstellung startest.
Soll ich einfach alle Plugins deaktivieren?
Das kann bei einer kontrollierten Konfliktprüfung sinnvoll sein, sollte auf einer laufenden Website aber nicht der erste unvorbereitete Schritt sein. Beginne mit der konkret verdächtigen Komponente. Breite Tests gehören möglichst in eine Testkopie, insbesondere bei Shops und Mitgliederbereichen.
Hilft ein höheres PHP-Speicherlimit?
Nur wenn tatsächlich ein Speicherproblem vorliegt und das verfügbare Limit für die Aufgabe zu niedrig ist. Eine Endlosschleife oder ungewöhnlich große Verarbeitung wird durch mehr Speicher nicht zuverlässig behoben. Der aktuelle Fehler muss zur Maßnahme passen.
Warum funktioniert die Website für mich, aber nicht für Besucher?
Recovery-Modus, Anmeldung und verschiedene Cache-Stände können unterschiedliche Ergebnisse erzeugen. Teste abgemeldet in einem privaten Fenster und prüfe betroffene dynamische Seiten. So trennst du eine funktionierende Administratorsitzung von einer tatsächlich wieder erreichbaren Website.