WordPress mostra una pagina bianca o un errore critico: cosa fare?

Invece del tuo sito web WordPress, all'improvviso appare solo una pagina bianca o il messaggio che si è verificato un errore critico sul sito web. Spesso si è verificato un grave errore PHP che impedisce a WordPress di eseguire completamente la pagina richiesta.

La causa può essere, ad esempio, un plugin difettoso o incompatibile, un tema, codice PHP personalizzato, una versione di PHP non idonea o un limite di memoria esaurito.

L'importante ora è non cancellare file a caso o modificare più impostazioni contemporaneamente. Con una ricerca sistematica degli errori, la causa può essere solitamente circoscritta molto più rapidamente.

Breve spiegazione: Verifica prima cosa è stato modificato immediatamente prima dell'errore e se WordPress ha inviato un'email di ripristino all'indirizzo dell'amministratore. Dopodiché, dovresti esaminare in modo mirato plugin, tema, versione di PHP, limite di memoria e registri degli errori. Se possibile, modifica sempre una sola cosa alla volta.

Che cosa significa „Auf deiner Website ist ein kritischer Fehler aufgetreten“? #

WordPress è in grado di rilevare errori PHP gravi che impediscono l'esecuzione normale di una richiesta.

Invece di mostrare ai visitatori messaggi di errore PHP tecnici, su un sito web WordPress di produzione appare spesso solo un messaggio generico su un errore critico.

La vera causa tecnica risulta quindi inizialmente invisibile nel browser.

Le cause tipiche sono:

• plugin difettoso o incompatibile
• Conflitto tra plugin
• tema difettoso o incompatibile
• Errore nel codice PHP inserito autonomamente
• versione PHP non idonea
• limite di memoria PHP raggiunto
• file danneggiate dopo un aggiornamento
• Problemi con i file di base di WordPress

Cos'è la „Schermata Bianca della Morte“? #

Come Schermata bianca della morte, spesso con WSOD chiamata abbreviata, indica una pagina bianca completamente o prevalentemente vuota in cui WordPress non restituisce alcun messaggio di errore utile.

Una simile pagina bianca può anche essere causata da errori PHP o del database.

Le versioni moderne di WordPress dispongono di un gestore degli errori irreversibili e di una modalità di recupero. Per questo motivo, in presenza di determinati errori, oggi compare più frequentemente il messaggio di errore critico anziché la classica pagina completamente bianca.

Il problema di fondo rimane tuttavia simile: WordPress non è riuscito a completare normalmente la richiesta a causa di un errore irreversibile.

1. Pensa prima di tutto: cosa è stato modificato immediatamente prima? #

Il primo e più importante passo diagnostico spesso non è tecnico.

Pensa a cosa è successo immediatamente prima che si verificasse l'errore.

Per esempio:

• WordPress è stato aggiornato
• un plugin è stato aggiornato
• diversi plugin sono stati aggiornati contemporaneamente
• è stato installato un nuovo plugin
• un plugin è stato attivato
• Il tema è stato aggiornato
• è stato attivato un nuovo tema
• la versione di PHP è stata modificata
• Il codice è stato inserito in functions.php inserito
• wp-config.php è stato modificato
• è stato attivato un frammento di codice

Se l'errore si è verificato immediatamente dopo una determinata modifica, questa modifica è il primo punto di partenza logico per la diagnostica.

Consiglio pratico: Prendi nota delle modifiche che fai durante la ricerca degli errori. Se modifichi contemporaneamente la versione di PHP, il tema e cinque plugin e il sito web riprende a funzionare, non saprai quale sia stata la vera causa.

2. Verifica se è interessata una sola pagina o l'intero sito web #

Un errore critico non deve necessariamente riguardare l'intera installazione di WordPress.

Testa quindi diverse sezioni del sito web:

• Pagina iniziale
• una pagina secondaria normale
• un post del blog
• Accesso a WordPress
• Pannello di amministrazione di WordPress

L'area di amministrazione è solitamente accessibile tramite un indirizzo che segue questo schema:

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

Ad esempio, se si guasta una sola pagina, la causa potrebbe risiedere in un determinato blocco, shortcode, template o plugin utilizzato solo su quella pagina.

Se invece non funzionano né il frontend né l'area di amministrazione, probabilmente c'è un problema più di fondo.

3. Verifica l'e-mail dell'amministratore di WordPress #

In caso di determinati errori irreversibili, WordPress attiva automaticamente la sua modalità di recupero e tenta di inviare un messaggio all'indirizzo email dell'amministratore configurato in WordPress.

Controlla quindi:

• Posta in arrivo dell'indirizzo dell'amministratore
• cartella spam o posta indesiderata
• eventualmente ulteriori filtri dell'account di posta elettronica

Il messaggio può contenere informazioni su quale plugin o tema ha causato l'errore, oltre a un link speciale per la modalità di recupero di WordPress.

Importante: Se non arriva alcuna e-mail di recupero, non significa che non vi sia un errore critico di WordPress. Il messaggio potrebbe non essere recapitato, ad esempio, a causa di un problema di posta elettronica oppure l'errore specifico potrebbe verificarsi al di fuori delle condizioni in cui WordPress attiva la modalità di recupero.

4. Utilizzo della modalità di recupero di WordPress #

Se hai ricevuto un'email corrispondente da WordPress, puoi utilizzare il link di recupero in essa contenuto.

Dopo il login, WordPress indica che la modalità di recupero è attiva.

Un plugin o tema difettoso può essere messo in pausa per la tua sessione di recupero, in modo da consentirti di accedere nuovamente all'area di amministrazione e di investigare sulla causa.

WordPress può mostrare lì indicazioni su quale componente ha causato un errore.

A seconda della causa, puoi ad esempio:

• disattivare un plugin problematico
• cambiare un tema difettoso
• indagare su un aggiornamento problematico
• correggere il proprio codice difettoso

Esci dalla modalità di ripristino solo dopo aver affrontato la presunta causa e aver controllato il sito web.

5. Funziona ancora l'area di amministrazione di WordPress? #

Se riesci ancora ad aprire normalmente l'area di amministrazione, la ricerca degli errori è decisamente più semplice.

Apri:

Plugin → Plugin installati

Se l'errore è iniziato dopo l'installazione, l'attivazione o l'aggiornamento di un plugin, disattiva prima quel plugin.

Controlla poi di nuovo la pagina interessata.

Se l'errore scompare, hai un forte indizio sulla causa. Tuttavia, questo non significa necessariamente che il plugin sia fondamentalmente difettoso. Ad esempio, è anche possibile che vi sia un conflitto con un altro plugin, con il tema, con la versione di WordPress o con la versione di PHP utilizzata.

Trattiamo una diagnosi dettagliata nell'articolo Rilevare e risolvere i conflitti di plugin o temi in WordPress.

6. Area amministrativa non accessibile: disattivare manualmente il plugin #

Se un plugin provoca un errore fatale e non riesci più ad accedere all'area di amministrazione di WordPress, il plugin interessato può eventualmente essere disattivato tramite l'accesso ai file.

I plugin di WordPress si trovano normalmente in:

wp-content/plugins/

Se ad esempio il registro degli errori indica chiaramente un plugin con la directory

wp-content/plugins/beispiel-plugin/

rimanda, la sua cartella può essere temporaneamente rinominata.

Per esempio:

plugin-di-esempio-disattivato

WordPress non riesce più a trovare il plugin nel percorso precedente e non riesce a caricarlo normalmente.

Attenzione: Non rinominare ciecamente tutte le directory dei plugin. Se hai già un sospetto specifico o una voce chiara nel registro degli errori, inizia esattamente con quel componente.

7. Cosa fare se non si conosce un plugin specifico? #

Se non è disponibile alcun registro degli errori e non sai quale plugin stia causando l'errore, come misura diagnostica potrebbe essere necessaria una disattivazione controllata dei plugin.

Se l'area di amministrazione è accessibile, dovresti farlo lì.

Se non è raggiungibile, avendo la necessaria esperienza, è possibile rinominare temporaneamente anche la directory dei plugin tramite l'accesso ai file.

La cartella di solito è:

wp-content/plugins/

Se l'intera cartella viene rinominata temporaneamente, WordPress non può più caricare i normali plugin in essa contenuti al percorso previsto.

Se il sito web funziona nuovamente in seguito, ciò indica fortemente che uno dei plugin è coinvolto.

Successivamente, i plugin devono essere riattivati in modo controllato o esaminati per trovare il vero responsabile.

Importante: „Il sito web funziona senza plugin“ non identifica ancora il plugin difettoso. La vera diagnosi inizia solo allora: controllare i plugin riattivandoli singolarmente o in gruppi sensati e testando dopo ogni modifica.

8. Verificare i temi come causa di errore #

Non solo i plugin possono causare un errore critico. Anche un tema può contenere codice PHP difettoso o incompatibile con l'ambiente corrente.

Un tema è particolarmente sospetto se l'errore si verifica immediatamente dopo:

• un aggiornamento del tema
• un cambio di tema
• di una modifica a functions.php
• di una personalizzazione di un child theme

si è verificato.

Se riesci ad accedere all'area di amministrazione, puoi attivare, a titolo di prova, un tema predefinito di WordPress aggiornato.

Affinché il sito Web funzioni di nuovo, il tema precedente dovrebbe essere esaminato più attentamente.

9. Verifica il tema se l'area di amministrazione non è raggiungibile #

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 Modificare la versione di PHP per WordPress e verificare la compatibilità.

Consiglio pratico: 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:

Dimensione di memoria consentita ... esaurita

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 limite di memoria, WordPress-Speichergrenzen und einer tatsächlichen Fehlerursache erklären wir im Artikel Limite di memoria PHP in WordPress: individuare e risolvere gli errori.

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 Attivare il debug di WordPress e utilizzare i log degli errori.

Attenzione: 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
• Percorso file
• Nome file
• Numero di riga
• betroffene Funktion oder Klasse
• Momento dell'errore

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

o:

wp-config.php

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

Importante: 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.

Verifica:

• 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.

Raccomandazione: 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:

• Cache del browser
• 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? #

No.

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.

Uno Errore interno del server 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 Risolvere l'errore 500 in WordPress.

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:

• Dominio
• DNS
• Server web
• SSL
• Hosting
• Netzwerk

Für diesen Fall verwenden wir eine breitere Diagnose im Artikel Sito WordPress non raggiungibile: verificare le cause in modo sistematico.

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

Non necessariamente.

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.

Ad esempio, sono utili:

• dominio interessato
• genaue sichtbare Fehlermeldung
• Zeitpunkt, seit dem der Fehler auftritt
• letzte Änderung vor Auftreten des Fehlers
• zuletzt aktualisiertes Plugin oder Theme
• versione PHP utilizzata
• 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.

Quando dovresti contattare il supporto di CURIAWEB? #

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.

Riepilogo #

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.