WordPress zeigt eine weisse Seite oder einen kritischen Fehler: Was tun?

Statt deiner WordPress-Website erscheint plötzlich nur noch eine weisse Seite oder die Meldung, dass auf der Website ein kritischer Fehler aufgetreten ist. Häufig ist dann ein schwerwiegender PHP-Fehler aufgetreten, durch den WordPress die angeforderte Seite nicht mehr vollständig ausführen kann.

Die Ursache kann beispielsweise ein fehlerhaftes oder inkompatibles Plugin, ein Theme, eigener PHP-Code, eine ungeeignete PHP-Version oder ein ausgeschöpftes Speicherlimit sein.

Wichtig ist jetzt, nicht wahllos Dateien zu löschen oder mehrere Einstellungen gleichzeitig zu verändern. Mit einer systematischen Fehlersuche lässt sich die Ursache meistens wesentlich schneller eingrenzen.

Kurz erklärt: Prüfe zuerst, was unmittelbar vor dem Fehler geändert wurde und ob WordPress eine Recovery-E-Mail an die Administrator-Adresse gesendet hat. Danach solltest du Plugins, Theme, PHP-Version, Speicherlimit und Fehlerprotokolle gezielt untersuchen. Ändere möglichst immer nur eine Sache gleichzeitig.

Was bedeutet „Auf deiner Website ist ein kritischer Fehler aufgetreten“? #

WordPress kann schwerwiegende PHP-Fehler erkennen, die verhindern, dass eine Anfrage normal ausgeführt wird.

Statt Besuchern technische PHP-Fehlermeldungen anzuzeigen, erscheint auf einer produktiven WordPress-Website häufig lediglich eine allgemeine Meldung über einen kritischen Fehler.

Die eigentliche technische Ursache ist dadurch im Browser zunächst nicht sichtbar.

Typische Ursachen sind:

• fehlerhaftes oder inkompatibles Plugin
• Plugin-Konflikt
• fehlerhaftes oder inkompatibles Theme
• Fehler in selbst eingefügtem PHP-Code
• ungeeignete PHP-Version
• erreichtes PHP-Speicherlimit
• fehlerhafte Dateien nach einem Update
• Probleme mit WordPress-Core-Dateien

Was ist die „White Screen of Death“? #

Als White Screen of Death, häufig mit WSOD abgekürzt, wird eine vollständig oder weitgehend leere weisse Seite bezeichnet, bei der WordPress keine hilfreiche Fehlermeldung ausgibt.

Eine solche weisse Seite kann ebenfalls durch PHP- oder Datenbankfehler verursacht werden.

Moderne WordPress-Versionen verfügen über einen Fatal Error Handler und einen Recovery Mode. Deshalb erscheint bei bestimmten Fehlern heute häufiger die Meldung über einen kritischen Fehler anstelle der klassischen vollständig weissen Seite.

Das Grundproblem bleibt jedoch ähnlich: WordPress konnte die Anfrage aufgrund eines schwerwiegenden Fehlers nicht normal abschliessen.

1. Überlege zuerst: Was wurde unmittelbar vorher geändert? #

Der wichtigste erste Diagnoseschritt ist häufig nicht technisch.

Überlege, was unmittelbar vor Auftreten des Fehlers passiert ist.

Beispielsweise:

• WordPress wurde aktualisiert
• ein Plugin wurde aktualisiert
• mehrere Plugins wurden gleichzeitig aktualisiert
• ein neues Plugin wurde installiert
• ein Plugin wurde aktiviert
• das Theme wurde aktualisiert
• ein neues Theme wurde aktiviert
• die PHP-Version wurde geändert
• Code wurde in functions.php eingefügt
• wp-config.php wurde bearbeitet
• ein Code-Snippet wurde aktiviert

Wenn der Fehler unmittelbar nach einer bestimmten Änderung auftrat, ist diese Änderung der erste sinnvolle Ansatzpunkt für die Diagnose.

Praxis-Tipp: Schreibe dir bei der Fehlersuche auf, was du veränderst. Wenn du gleichzeitig PHP-Version, Theme und fünf Plugins änderst und die Website danach wieder funktioniert, weisst du nicht, was die eigentliche Ursache war.

2. Prüfe, ob nur eine Seite oder die gesamte Website betroffen ist #

Ein kritischer Fehler muss nicht zwingend die komplette WordPress-Installation betreffen.

Teste deshalb verschiedene Bereiche der Website:

• Startseite
• eine normale Unterseite
• einen Blogbeitrag
• WordPress-Login
• WordPress-Adminbereich

Der Adminbereich ist normalerweise über eine Adresse nach diesem Muster erreichbar:

https://deine-domain.ch/wp-admin

Wenn beispielsweise nur eine einzelne Seite ausfällt, kann die Ursache in einem bestimmten Block, Shortcode, Template oder Plugin liegen, das nur auf dieser Seite verwendet wird.

Funktioniert dagegen weder Frontend noch Adminbereich, liegt wahrscheinlich ein grundlegenderes Problem vor.

3. Administrator-E-Mail von WordPress prüfen #

Bei bestimmten fatalen Fehlern aktiviert WordPress automatisch seinen Recovery Mode und versucht, eine Nachricht an die in WordPress hinterlegte Administrator-E-Mail-Adresse zu senden.

Kontrolliere deshalb:

• Posteingang der Administrator-Adresse
• Spam- beziehungsweise Junk-Ordner
• gegebenenfalls weitere Filter des E-Mail-Kontos

Die Nachricht kann Informationen darüber enthalten, welches Plugin oder Theme den Fehler ausgelöst hat, sowie einen speziellen Link für den WordPress-Wiederherstellungsmodus.

Wichtig: Wenn keine Recovery-E-Mail ankommt, bedeutet das nicht, dass kein kritischer WordPress-Fehler vorliegt. Die Nachricht kann beispielsweise aufgrund eines Mailproblems nicht zugestellt werden oder der konkrete Fehler kann ausserhalb der Bedingungen auftreten, unter denen WordPress den Recovery Mode aktiviert.

4. WordPress Recovery Mode verwenden #

Wenn du eine entsprechende E-Mail von WordPress erhalten hast, kannst du den darin enthaltenen Recovery-Link verwenden.

Nach dem Login zeigt WordPress an, dass der Wiederherstellungsmodus aktiv ist.

Ein fehlerhaftes Plugin oder Theme kann für deine Recovery-Sitzung pausiert werden, damit du wieder Zugriff auf den Adminbereich erhältst und die Ursache untersuchen kannst.

WordPress kann dort Hinweise anzeigen, welche Komponente einen Fehler verursacht hat.

Je nach Ursache kannst du beispielsweise:

• ein problematisches Plugin deaktivieren
• ein fehlerhaftes Theme wechseln
• ein problematisches Update untersuchen
• fehlerhaften eigenen Code korrigieren

Verlasse den Recovery Mode erst, wenn du die vermutete Ursache behandelt und die Website kontrolliert hast.

5. Funktioniert der WordPress-Adminbereich noch? #

Wenn du den Adminbereich noch normal öffnen kannst, ist die Fehlersuche deutlich einfacher.

Öffne:

Plugins → Installierte Plugins

Wenn der Fehler nach Installation, Aktivierung oder Aktualisierung eines Plugins begonnen hat, deaktiviere zunächst dieses Plugin.

Kontrolliere danach die betroffene Seite erneut.

Verschwindet der Fehler, hast du einen starken Hinweis auf die Ursache. Das bedeutet allerdings noch nicht zwangsläufig, dass das Plugin grundsätzlich fehlerhaft ist. Möglich ist beispielsweise auch ein Konflikt mit einem anderen Plugin, dem Theme, der WordPress-Version oder der verwendeten PHP-Version.

Eine ausführliche Diagnose behandeln wir im Artikel Plugin- oder Theme-Konflikte in WordPress erkennen und beheben.

6. Adminbereich nicht erreichbar: Plugin manuell deaktivieren #

Wenn ein Plugin einen fatalen Fehler verursacht und du nicht mehr auf den WordPress-Adminbereich zugreifen kannst, lässt sich das betroffene Plugin gegebenenfalls über den Dateizugriff deaktivieren.

WordPress-Plugins befinden sich normalerweise unter:

wp-content/plugins/

Wenn das Fehlerprotokoll beispielsweise eindeutig auf ein Plugin mit dem Verzeichnis

wp-content/plugins/beispiel-plugin/

verweist, kann dessen Ordner vorübergehend umbenannt werden.

Beispielsweise:

beispiel-plugin-deaktiviert

WordPress findet das Plugin dann nicht mehr unter seinem bisherigen Pfad und kann es nicht normal laden.

Achtung: Benenne nicht wahllos sämtliche Plugin-Verzeichnisse um. Wenn du bereits einen konkreten Verdacht oder einen eindeutigen Eintrag im Fehlerprotokoll hast, beginne mit genau dieser Komponente.

7. Was tun, wenn kein bestimmtes Plugin bekannt ist? #

Wenn kein Fehlerprotokoll vorhanden ist und du nicht weisst, welches Plugin den Fehler verursacht, kann als Diagnosemassnahme eine kontrollierte Deaktivierung der Plugins notwendig sein.

Ist der Adminbereich erreichbar, solltest du dies dort durchführen.

Ist er nicht erreichbar, kann bei entsprechender Erfahrung über den Dateizugriff auch das Plugin-Verzeichnis vorübergehend umbenannt werden.

Der Ordner lautet normalerweise:

wp-content/plugins/

Wird der gesamte Ordner vorübergehend umbenannt, kann WordPress die darin befindlichen normalen Plugins nicht mehr unter dem erwarteten Pfad laden.

Funktioniert die Website anschließend wieder, deutet dies stark darauf hin, dass eines der Plugins beteiligt ist.

Danach müssen die Plugins kontrolliert wieder aktiviert beziehungsweise untersucht werden, um den tatsächlichen Verursacher zu finden.

Wichtig: „Website funktioniert ohne Plugins“ identifiziert noch nicht das fehlerhafte Plugin. Die eigentliche Diagnose beginnt dann erst: Plugins kontrolliert einzeln beziehungsweise in sinnvollen Gruppen wieder aktivieren und nach jeder Änderung testen.

8. Theme als Fehlerursache prüfen #

Nicht nur Plugins können einen kritischen Fehler verursachen. Auch ein Theme kann fehlerhaften oder mit der aktuellen Umgebung inkompatiblen PHP-Code enthalten.

Ein Theme ist besonders verdächtig, wenn der Fehler unmittelbar nach:

• einem Theme-Update
• einem Theme-Wechsel
• einer Änderung an functions.php
• einer Anpassung eines Child-Themes

aufgetreten ist.

Wenn der Adminbereich erreichbar ist, kannst du testweise ein aktuelles WordPress-Standardtheme aktivieren.

Funktioniert die Website damit wieder, sollte das bisherige Theme genauer untersucht werden.

9. Theme prüfen, wenn der Adminbereich nicht erreichbar ist #

Themes befinden sich normalerweise unter:

wp-content/themes/

Bei einer manuellen Diagnose kann das Verzeichnis des aktiven Themes vorübergehend umbenannt werden.

Damit WordPress anschließend auf ein anderes Theme zurückgreifen kann, muss allerdings ein geeignetes anderes Theme installiert sein.

Eine solche Änderung kann die Darstellung der Website erheblich verändern und sollte deshalb gezielt zur Diagnose eingesetzt werden.

10. Fehler nach Änderung der PHP-Version #

Wenn der kritische Fehler unmittelbar nach einer Änderung der PHP-Version aufgetreten ist, sollte die Kompatibilität der WordPress-Installation geprüft werden.

WordPress selbst, Plugins und Themes müssen mit der verwendeten PHP-Version zusammenarbeiten.

Besonders ältere Plugins, Themes oder eigener Code können Funktionen verwenden, die unter einer neueren PHP-Version verändert oder entfernt wurden.

Umgekehrt kann moderne Software Funktionen voraussetzen, die in einer sehr alten PHP-Version noch nicht verfügbar sind.

Die systematische Vorgehensweise behandeln wir ausführlich in PHP-Version für WordPress ändern und Kompatibilität prüfen.

Praxis-Tipp: Wenn eine Website unmittelbar nach einem PHP-Wechsel ausfällt, dokumentiere die bisherige und die neue PHP-Version. Diese Information ist für die Fehlersuche wesentlich hilfreicher als die allgemeine Aussage „WordPress funktioniert nicht mehr“.

11. PHP Memory Limit als mögliche Ursache #

WordPress, Plugins und Themes benötigen während der Ausführung Arbeitsspeicher. Überschreitet ein PHP-Prozess das zulässige Speicherlimit, kann die Verarbeitung mit einem fatalen Fehler abbrechen.

Im Fehlerprotokoll kann dann beispielsweise eine Meldung mit folgendem Bestandteil erscheinen:

Allowed memory size ... exhausted

In diesem Fall sollte nicht automatisch nur das Speicherlimit erhöht werden.

Ein ungewöhnlich hoher Speicherverbrauch kann beispielsweise durch:

• ein ressourcenintensives Plugin
• einen Programmierfehler
• eine sehr aufwendige Operation
• eine ungünstige Plugin-Kombination
• einen Import- oder Exportvorgang

verursacht werden.

Die Unterschiede zwischen PHP memory_limit, WordPress-Speichergrenzen und einer tatsächlichen Fehlerursache erklären wir im Artikel PHP Memory Limit in WordPress: Fehler erkennen und beheben.

12. Fehlerprotokolle statt Vermutungen verwenden #

Wenn die offensichtliche Ursache nicht erkennbar ist, sind Fehlerprotokolle häufig der wichtigste nächste Schritt.

Ein Log kann beispielsweise zeigen:

• welche PHP-Datei den Fehler ausgelöst hat
• welches Plugin betroffen ist
• ob der Fehler aus dem Theme stammt
• welche PHP-Funktion beteiligt ist
• ob das Speicherlimit erreicht wurde
• an welcher Datei und Zeile der Fehler aufgetreten ist

Ein typischer Eintrag kann beispielsweise einen Pfad wie diesen enthalten:

/wp-content/plugins/beispiel-plugin/...

Das ist wesentlich aussagekräftiger als lediglich die sichtbare Meldung über einen kritischen Fehler.

13. WordPress-Debugging gezielt aktivieren #

WordPress besitzt eigene Debugging-Funktionen. Damit können PHP-Fehler, Warnungen und Hinweise protokolliert werden.

Zu den wichtigsten Konstanten gehören:

• WP_DEBUG
• WP_DEBUG_LOG
• WP_DEBUG_DISPLAY

Für eine produktive Website sollten detaillierte Fehlermeldungen normalerweise nicht öffentlich im Frontend angezeigt werden. Sie können interne Pfade, technische Details oder andere Informationen enthalten, die Besucher nicht sehen sollten.

Wie du Debugging sicher einsetzt und debug.log auswertest, behandeln wir ausführlich in WordPress Debugging aktivieren und Fehlerprotokolle verwenden.

Achtung: Aktiviere nicht einfach dauerhaft die öffentliche Ausgabe sämtlicher PHP-Fehler auf einer produktiven Website. Für die Fehlersuche ist ein kontrolliertes Logging normalerweise sinnvoller als technische Fehlermeldungen für jeden Besucher sichtbar zu machen.

14. Wo befindet sich das WordPress-Debug-Log? #

Wenn WordPress-Debugging entsprechend konfiguriert wurde, wird das Standard-Debug-Protokoll normalerweise unter folgendem Pfad angelegt:

wp-content/debug.log

Ob die Datei vorhanden ist und welche Einträge sie enthält, hängt von der Debug-Konfiguration und den tatsächlich auftretenden Fehlern ab.

Ein Log sollte nach Abschluss der Fehlersuche nicht unnötig öffentlich zugänglich bleiben.

15. Fatal Error richtig lesen #

Eine PHP-Fehlermeldung kann auf den ersten Blick kompliziert wirken. Für die erste Diagnose sind aber häufig wenige Bestandteile besonders interessant:

• Art des Fehlers
• Dateipfad
• Dateiname
• Zeilennummer
• betroffene Funktion oder Klasse
• Zeitpunkt des Fehlers

Steht im Pfad beispielsweise:

wp-content/plugins/...

ist ein Plugin beteiligt.

Steht dort:

wp-content/themes/...

führt die Spur in Richtung Theme beziehungsweise Child-Theme.

Ein Dateipfad allein beweist allerdings nicht immer, dass genau diese Komponente die eigentliche Ursache ist. Ein Fehler kann beispielsweise durch einen Aufruf aus einer anderen Komponente ausgelöst worden sein.

16. Syntaxfehler nach manueller Codeänderung #

Wenn du unmittelbar vor dem Ausfall PHP-Code manuell bearbeitet hast, sollte diese Änderung als Erstes geprüft werden.

Ein kleiner Syntaxfehler kann ausreichen, um einen fatalen PHP-Fehler auszulösen.

Besonders kritisch sind Änderungen an Dateien wie:

functions.php

oder:

wp-config.php

Wenn du noch genau weisst, welche Änderung den Fehler ausgelöst hat, stelle den vorherigen funktionierenden Code wieder her.

Wichtig: Kopiere nicht wahllos PHP-Code aus Foren, Videos oder KI-Ausgaben in eine produktive WordPress-Website. Prüfe, wofür der Code gedacht ist, ob er zur aktuellen Umgebung passt und ob du eine Möglichkeit zur Wiederherstellung hast.

17. Fehler unmittelbar nach einem WordPress-Update #

Ein kritischer Fehler nach einem WordPress-Update bedeutet nicht automatisch, dass WordPress selbst fehlerhaft ist.

Ein Update kann beispielsweise sichtbar machen, dass:

• ein älteres Plugin nicht mehr kompatibel ist
• ein Theme veralteten Code verwendet
• eigener Code nicht mehr kompatibel ist
• ein Update nicht vollständig abgeschlossen wurde

Prüfe deshalb zunächst die konkrete Fehlermeldung beziehungsweise das Fehlerprotokoll.

Ein sofortiges Downgrade ohne Diagnose kann das Problem lediglich verdecken und zusätzlich Sicherheits- oder Kompatibilitätsprobleme verursachen.

18. Fehler unmittelbar nach einem Plugin-Update #

Wenn die Website direkt nach Aktualisierung eines bestimmten Plugins ausfällt, ist dieses Plugin ein naheliegender Ausgangspunkt.

Prüfe:

• ob das Plugin im Fehlerprotokoll genannt wird
• ob eine weitere Aktualisierung verfügbar ist
• ob der Entwickler bekannte Probleme dokumentiert
• ob die verwendete WordPress- und PHP-Version unterstützt wird
• ob ein Konflikt mit einer anderen Erweiterung vorliegt

Deaktiviere das Plugin gegebenenfalls vorübergehend, um die Website wieder erreichbar zu machen und die Ursache weiter einzugrenzen.

19. Fehler nach Aktivierung eines neuen Plugins #

Wenn ein kritischer Fehler unmittelbar nach der Aktivierung eines neuen Plugins erscheint, ist die Diagnose vergleichsweise eindeutig zu beginnen.

Deaktiviere das neu aktivierte Plugin wieder.

Funktioniert die Website danach normal, sollte vor einer erneuten Aktivierung geprüft werden, warum das Plugin den Fehler auslöst.

Mögliche Gründe sind:

• Inkompatibilität mit PHP
• Inkompatibilität mit WordPress
• Konflikt mit einem anderen Plugin
• Konflikt mit dem Theme
• fehlende PHP-Erweiterung
• Programmierfehler im Plugin

20. Nicht sofort ein Backup zurückspielen #

Ein Backup ist für die Wiederherstellung einer Website sehr wichtig. Es sollte aber nicht automatisch der allererste Schritt bei jedem kritischen Fehler sein.

Wenn beispielsweise nur ein neu aktiviertes Plugin den Fehler verursacht, kann dessen Deaktivierung wesentlich schneller und sauberer sein als die vollständige Wiederherstellung einer älteren Website-Version.

Ein Backup-Restore kann außerdem neuere Inhalte, Bestellungen, Formulareingaben oder andere seit dem Sicherungszeitpunkt entstandene Daten überschreiben.

Empfehlung: Ermittle nach Möglichkeit zuerst die Ursache. Eine vollständige Wiederherstellung ist besonders dann sinnvoll, wenn Dateien oder Daten beschädigt wurden oder eine kontrollierte Rückkehr zu einem bekannten funktionierenden Zustand erforderlich ist.

21. Wann ein Backup trotzdem die richtige Lösung ist #

Eine Wiederherstellung kann sinnvoll sein, wenn beispielsweise:

• zahlreiche Dateien beschädigt wurden
• eine fehlgeschlagene Änderung nicht sauber rückgängig gemacht werden kann
• mehrere Komponenten gleichzeitig verändert wurden
• Schadcode oder Manipulation vermutet wird
• ein bekannter funktionierender Sicherungsstand benötigt wird

Bei dynamischen Websites wie WooCommerce-Shops muss besonders sorgfältig geprüft werden, welche Daten durch einen Restore überschrieben würden.

22. Cache nach der Fehlerbehebung berücksichtigen #

Wenn die eigentliche Ursache behoben wurde, kann eine zwischengespeicherte Fehlerseite unter Umständen noch sichtbar sein.

Je nach Website können verschiedene Cache-Ebenen beteiligt sein:

• Browser-Cache
• WordPress-Cache-Plugin
• Server- beziehungsweise Page-Cache
• CDN oder Proxy

Leere Cache-Systeme jedoch nicht reflexartig als ersten Diagnoseschritt. Ein PHP-Fatal-Error wird durch das Löschen des Browser-Caches nicht repariert.

23. Ist eine weisse Seite immer ein WordPress-Fehler? #

Nein.

Eine scheinbar leere Seite kann auch andere Ursachen haben, beispielsweise:

• CSS blendet Inhalte aus
• JavaScript verhindert die erwartete Darstellung
• eine leere Template-Ausgabe
• ein Cache liefert fehlerhaften Inhalt
• eine externe Abhängigkeit verursacht Probleme

Deshalb ist es wichtig, zwischen einer tatsächlich leeren Serverantwort, einem PHP-Fatal-Error und einer lediglich optisch leeren Seite zu unterscheiden.

24. Kritischer Fehler oder HTTP 500? #

Ein schwerwiegender PHP-Fehler kann sich je nach Server- und WordPress-Konfiguration auch als HTTP-500-Fehler bemerkbar machen.

Ein 500 Internal Server Error ist allerdings allgemeiner und kann neben PHP-Fehlern weitere Ursachen haben.

Wenn dein Browser ausdrücklich einen Fehler 500 meldet, findest du die gezielte Diagnose im Artikel Fehler 500 in WordPress beheben.

25. Kritischer Fehler oder Website komplett nicht erreichbar? #

Wenn überhaupt keine Verbindung zur Website aufgebaut werden kann, muss WordPress nicht zwingend die Ursache sein.

Auch folgende Bereiche können eine Rolle spielen:

• Domain
• DNS
• Webserver
• SSL
• Hosting
• Netzwerk

Für diesen Fall verwenden wir eine breitere Diagnose im Artikel WordPress-Website nicht erreichbar: Ursachen systematisch prüfen.

26. Website funktioniert wieder – ist das Problem damit erledigt? #

Nicht unbedingt.

Wenn du beispielsweise ein Plugin deaktiviert hast und die Website wieder funktioniert, hast du zunächst das Symptom beseitigt.

Danach solltest du noch klären:

• warum das Plugin den Fehler verursacht hat
• ob eine kompatible Version verfügbar ist
• ob das Plugin weiterhin benötigt wird
• ob ein Konflikt mit einer anderen Komponente besteht
• ob weitere Fehler im Log vorhanden sind

Ein kritischer Fehler sollte nicht dadurch „gelöst“ werden, dass die Ursache vergessen wird, sobald die Startseite wieder erscheint.

27. Debugging nach der Fehlersuche wieder deaktivieren #

Wenn du für die Diagnose WordPress-Debugging aktiviert hast, solltest du die Einstellungen nach Abschluss der Fehlersuche wieder auf einen für die produktive Website geeigneten Zustand zurücksetzen.

Insbesondere detaillierte Fehlermeldungen sollten nicht dauerhaft öffentlich ausgegeben werden.

Auch erzeugte Logdateien sollten hinsichtlich Inhalt, Speicherplatz und Zugriff kontrolliert werden.

28. Reihenfolge für eine systematische Fehlersuche #

Wenn WordPress einen kritischen Fehler oder eine weisse Seite zeigt, kannst du dich grundsätzlich an folgender Reihenfolge orientieren:

1. Ruhe bewahren und keine wahllosen Änderungen durchführen.
2. Prüfen, was unmittelbar vor dem Fehler geändert wurde.
3. Kontrollieren, welche Bereiche der Website betroffen sind.
4. Administrator-E-Mail und Spam-Ordner prüfen.
5. Recovery Mode verwenden, falls verfügbar.
6. Zuletzt geändertes Plugin oder Theme untersuchen.
7. PHP-Version prüfen, insbesondere nach einer Änderung.
8. Fehlerprotokolle auswerten.
9. Bei Bedarf WordPress-Debugging kontrolliert aktivieren.
10. Memory-Limit prüfen, wenn das Log darauf hinweist.
11. Ursache gezielt beheben.
12. Frontend und Adminbereich vollständig testen.
13. Debugging-Einstellungen wieder kontrollieren.

29. Was du bei einem kritischen Fehler besser nicht tun solltest #

• nicht wahllos WordPress-Dateien löschen
• nicht mehrere Plugins gleichzeitig löschen, ohne die Ursache zu dokumentieren
• nicht sofort die Datenbank verändern
• nicht beliebige PHP-Werte erhöhen, ohne die Fehlermeldung zu verstehen
• nicht ungeprüft auf eine alte PHP-Version wechseln
• nicht sämtliche Dateiberechtigungen verändern
• nicht sofort ein altes Backup über eine aktuelle dynamische Website spielen
• nicht detaillierte PHP-Fehler dauerhaft öffentlich anzeigen
• nicht die alte funktionierende Konfiguration vergessen, bevor du Änderungen vornimmst

30. Welche Informationen helfen dem Support? #

Je genauer die Ausgangslage beschrieben wird, desto schneller kann ein technischer Fehler normalerweise eingegrenzt werden.

Hilfreich sind beispielsweise:

• betroffene Domain
• genaue sichtbare Fehlermeldung
• Zeitpunkt, seit dem der Fehler auftritt
• letzte Änderung vor Auftreten des Fehlers
• zuletzt aktualisiertes Plugin oder Theme
• verwendete PHP-Version
• ob Frontend und Adminbereich betroffen sind
• relevanter Eintrag aus dem Error Log
• ob eine WordPress-Recovery-E-Mail angekommen ist

Wenn ein Fehlerprotokoll vorhanden ist, sollte der relevante Abschnitt mit Zeitstempel übermittelt werden. Ein vollständiges Log mit Tausenden alten Meldungen ist für eine gezielte Diagnose häufig weniger hilfreich.

Wann solltest du den CURIAWEB-Support kontaktieren? #

Wenn deine WordPress-Website bei CURIAWEB einen kritischen Fehler oder eine weisse Seite zeigt und du die Ursache nicht eindeutig identifizieren kannst, kann der Support bei der technischen Eingrenzung der Hosting- und WordPress-Umgebung helfen.

Kontaktiere den Support insbesondere, wenn:

• Frontend und Adminbereich nicht mehr erreichbar sind
• du die Fehlermeldung im Log nicht einordnen kannst
• der Fehler nach einer Änderung der PHP-Version auftrat
• ein Speicher- oder PHP-Fehler angezeigt wird
• du unsicher bist, bevor du Dateien oder Einstellungen manuell veränderst

Sende keine Passwörter unaufgefordert mit. Beschreibe stattdessen möglichst genau, wann der Fehler begonnen hat und welche Änderung unmittelbar davor durchgeführt wurde.

Zusammenfassung #

Eine weisse WordPress-Seite oder die Meldung über einen kritischen Fehler weist häufig auf einen schwerwiegenden PHP-Fehler hin. Typische Ursachen sind Plugins, Themes, eigener Code, PHP-Inkompatibilitäten oder ein ausgeschöpftes Speicherlimit.

Prüfe zuerst, was unmittelbar vor dem Fehler geändert wurde. Kontrolliere danach die Administrator-E-Mail auf eine Nachricht zum WordPress Recovery Mode und untersuche verdächtige Plugins oder Themes.

Wenn die Ursache nicht offensichtlich ist, solltest du Fehlerprotokolle verwenden, statt Einstellungen auf Verdacht zu verändern. Dateipfade und Fehlertypen liefern häufig konkrete Hinweise darauf, welche Komponente beteiligt ist.

Eine systematische Diagnose ist dabei wichtiger als eine möglichst schnelle Folge von Änderungen: Ursache identifizieren, gezielt beheben, Website testen und temporär aktivierte Debugging-Massnahmen anschließend wieder zurücksetzen.