WordPress shows a white screen or a critical error: What to do?

Instead of your WordPress website, suddenly only a white page appears or the message that a critical error has occurred on the website. Often, a fatal PHP error has occurred, which prevents WordPress from fully executing the requested page.

For example, the cause can be a faulty or incompatible plugin, a theme, custom PHP code, an unsuitable PHP version, or an exhausted memory limit.

The important thing now is not to delete files at random or change multiple settings at once. With systematic troubleshooting, the cause can usually be narrowed down much faster.

Briefly explained: First, check what was changed immediately before the error occurred and whether WordPress sent a recovery email to the administrator address. After that, you should specifically investigate plugins, the theme, the PHP version, the memory limit, and error logs. Whenever possible, change only one thing at a time.

There has been a critical error on your website #

WordPress can detect fatal PHP errors that prevent a request from executing normally.

Instead of displaying technical PHP error messages to visitors, a productive WordPress website often simply shows a generic message about a critical error.

As a result, the actual technical cause is not immediately visible in the browser.

Typical causes are:

• faulty or incompatible plugin
• Plugin conflict
• faulty or incompatible theme
• Error in self-inserted PHP code
• incompatible PHP version
• reached PHP memory limit
• corrupted files after an update
• Issues with WordPress core files

What is the „White Screen of Death“? #

As White Screen of Death, often with WSOD abbreviated, it refers to a completely or largely empty white page where WordPress does not output a helpful error message.

Such a white page can also be caused by PHP or database errors.

Modern WordPress versions feature a fatal error handler and a recovery mode. That is why today, in the event of certain errors, the message about a critical error appears more frequently instead of the classic completely white screen.

However, the underlying problem remains similar: WordPress could not complete the request normally due to a fatal error.

1. Think first: What was changed immediately before? #

The most important initial diagnostic step is often not technical.

Consider what happened immediately before the error occurred.

For example:

• WordPress has been updated
• a plugin was updated
• several plugins were updated simultaneously
• a new plugin has been installed
• a plugin has been activated
• The theme has been updated
• a new theme has been activated
• the PHP version has been changed
• Code was in functions.php inserted
• wp-config.php has been edited
• a code snippet has been activated

If the error occurred immediately after a specific change, that change is the first logical starting point for diagnosis.

Practical Tip: Note down what you change during troubleshooting. If you change the PHP version, theme, and five plugins all at once and the website works again afterwards, you won't know what the actual cause was.

2. Check if only one page or the entire website is affected #

A critical error does not necessarily have to affect the complete WordPress installation.

Therefore, test different areas of the website:

• Home
• a normal subpage
• a blog post
• WordPress Login
• WordPress admin area

The admin area is usually accessible via an address following this pattern:

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

For example, if only a single page fails, the cause may lie in a specific block, shortcode, template, or plugin that is used only on that page.

If neither the frontend nor the admin area works against this, there is likely a more fundamental problem.

Check WordPress administrator email #

In the event of certain fatal errors, WordPress automatically activates its recovery mode and attempts to send a message to the administrator email address stored in WordPress.

Therefore, check:

• Inbox of the administrator address
• spam or junk folder
• if applicable, further email account filters

The message may contain information about which plugin or theme triggered the error, as well as a special link for the WordPress recovery mode.

Important: If no recovery email arrives, it does not mean that there is no critical WordPress error. For example, the message may not be delivered due to a mail issue, or the specific error may occur outside the conditions under which WordPress activates Recovery Mode.

4. Use WordPress Recovery Mode #

If you received a corresponding email from WordPress, you can use the recovery link contained within it.

After logging in, WordPress indicates that recovery mode is active.

A faulty plugin or theme can be paused for your recovery session so that you can regain access to the admin area and investigate the cause.

WordPress can display notices there indicating which component caused an error.

Depending on the cause, you can, for example:

• disable a problematic plugin
• change a faulty theme
• investigate a problematic update
• correct flawed own code

Do not exit Recovery Mode until you have addressed the suspected cause and checked the website.

5. Does the WordPress admin area still work? #

If you can still open the admin area normally, troubleshooting is much easier.

Open:

Plugins → Installed Plugins

If the error started after installing, activating, or updating a plugin, first deactivate that plugin.

Check the affected page again afterwards.

If the error disappears, you have a strong indication of the cause. However, this does not necessarily mean that the plugin is fundamentally faulty. For example, a conflict with another plugin, the theme, the WordPress version, or the PHP version used is also possible.

We cover a detailed diagnosis in the article Identifying and Resolving Plugin or Theme Conflicts in WordPress.

6. Admin area not accessible: Manually deactivate plugin #

If a plugin causes a fatal error and you can no longer access the WordPress admin area, the affected plugin can possibly be deactivated via file access.

WordPress plugins are usually located under:

wp-content/plugins/

If the error log, for example, clearly points to a plugin with the directory

wp-content/plugins/beispiel-plugin/

refers, its folder can be temporarily renamed.

For example:

example-plugin-deactivated

WordPress will then no longer find the plugin under its previous path and cannot load it normally.

Attention: Do not randomly rename all plugin directories. If you already have a specific suspicion or a clear entry in the error log, start with that exact component.

7. What to do if no specific plugin is known? #

If there is no error log and you do not know which plugin is causing the error, a controlled deactivation of the plugins may be necessary as a diagnostic measure.

If the admin area is accessible, you should do this there.

If he is unreachable, the plugin directory can also be temporarily renamed via file access, provided you have the appropriate experience.

The folder is usually:

wp-content/plugins/

If the entire folder is temporarily renamed, WordPress can no longer load the regular plugins located inside it under the expected path.

If the website works again afterwards, this strongly indicates that one of the plugins is involved.

After that, the plugins must be reactivated in a controlled manner or investigated in order to find the actual culprit.

Important: „Website works without plugins does not yet identify the faulty plugin. The actual diagnosis only begins then: reactivate plugins individually or in sensible groups and test after each change.

8. Check themes as a cause of error #

Not only plugins can cause a critical error. A theme can also contain faulty PHP code or code that is incompatible with the current environment.

A theme is particularly suspicious if the error occurred immediately after:

• a theme update
• a theme change
• to a change in functions.php
• an adaptation of a child theme

occurred.

If the admin area is accessible, you can activate a current WordPress default theme for testing purposes.

If the website works again with this, the previous theme should be examined more closely.

9. Check theme if admin area is inaccessible #

Themes are usually located at:

wp-content/themes/

During a manual diagnosis, the active theme's directory can be temporarily renamed.

For WordPress to then be able to fall back on a different theme, a suitable alternative theme must be installed.

Such a change can significantly alter the appearance of the website and should therefore be used specifically for diagnosis.

10. Error after changing the PHP version #

If the critical error occurred immediately after a change of the PHP version, the compatibility of the WordPress installation should be checked.

WordPress itself, plugins, and themes must be compatible with the PHP version being used.

Especially older plugins, themes, or custom code may use functions that have been modified or removed in a newer PHP version.

Conversely, modern software may require features that are not yet available in a very old PHP version.

We cover the systematic approach in detail in Change PHP version for WordPress and check compatibility.

Practical Tip: If a website fails immediately after a PHP version change, document the previous and the new PHP version. This information is much more helpful for troubleshooting than the general statement „WordPress is no longer working“.

11. PHP Memory Limit as a potential cause #

WordPress, plugins, and themes require memory during execution. If a PHP process exceeds the allowed memory limit, processing can abort with a fatal error.

For example, a message containing the following element may then appear in the error log:

Allowed memory size ... exhausted

In this case, the storage limit should not automatically just be increased.

An unusually high memory consumption can be caused by, for example:

• a resource-intensive plugin
• a programming error
• a very complex operation
• an unfavorable plugin combination
• an import or export operation

be caused.

The differences between PHP memory_limit, WordPress memory limits, and an actual cause of the error are explained in the article PHP Memory Limit in WordPress: Identify and fix errors.

12. Use error logs instead of assumptions #

When the obvious cause is not apparent, error logs are often the most important next step.

A log can show, for example:

• which PHP file triggered the error
• which plugin is affected
• whether the error comes from the theme
• which PHP function is involved
• whether the storage limit has been reached
• in which file and on which line the error occurred

A typical entry might contain a path like this, for example:

/wp-content/plugins/sample-plugin/...

This is much more meaningful than just the visible critical error message.

13. Enable WordPress debugging selectively #

WordPress has its own debugging functions. These can be used to log PHP errors, warnings, and notices.

Among the most important constants are:

• WP_DEBUG
• WP_DEBUG_LOG
• WP_DEBUG_DISPLAY

For a production website, detailed error messages should generally not be displayed publicly in the frontend. They can contain internal paths, technical details, or other information that visitors should not see.

How to use debugging safely and debug.log you evaluate, we will discuss in detail in Enable WordPress debugging and use error logs.

Attention: Do not simply enable the permanent public output of all PHP errors on a production website. For troubleshooting, controlled logging is usually more sensible than making technical error messages visible to every visitor.

14. Where is the WordPress debug log located? #

When WordPress debugging has been configured accordingly, the default debug log is normally created at the following path:

wp-content/debug.log

Whether the file exists and which entries it contains depends on the debug configuration and the errors that actually occur.

A log should not remain unnecessarily publicly accessible after troubleshooting is completed.

15. How to correctly read a Fatal Error #

A PHP error message can seem complicated at first glance. For the initial diagnosis, however, a few components are often particularly interesting:

• Type of error
• File path
• Filename
• Line number
• affected function or class
• Time of the error

For example, if the path says:

wp-content/plugins/...

a plugin is involved.

Does it say:

wp-content/themes/...

leads in the direction of the theme or child theme.

However, a file path alone does not always prove that this exact component is the actual cause. For example, an error may have been triggered by a call from another component.

16. Syntax error after manual code modification #

If you manually edited PHP code immediately before the failure, this change should be checked first.

A small syntax error can be enough to trigger a fatal PHP error.

Changes to files such as the following are particularly critical:

functions.php

or:

wp-config.php

If you still know exactly which change caused the error, restore the previous working code.

Important: Do not blindly copy PHP code from forums, videos, or AI outputs into a production WordPress website. Check what the code is intended for, whether it fits your current environment, and whether you have a way to restore it.

17. Errors immediately after a WordPress update #

A critical error after a WordPress update does not automatically mean that WordPress itself is faulty.

For example, an update can reveal that:

• an older plugin is no longer compatible
• a theme uses deprecated code
• own code is no longer compatible
• an update was not fully completed

Therefore, first check the specific error message or error log.

An immediate downgrade without diagnosis can merely mask the problem and additionally cause security or compatibility issues.

18. Error immediately after a plugin update #

If the website crashes immediately after updating a specific plugin, that plugin is an obvious starting point.

Check:

• whether the plugin is mentioned in the error log
• whether another update is available
• whether the developer documents known issues
• whether the used WordPress and PHP version is supported
• whether there is a conflict with another extension

Temporarily deactivate the plugin if necessary to make the website accessible again and further isolate the cause.

19. Error after activating a new plugin #

If a critical error appears immediately after activating a new plugin, the diagnosis is comparatively straightforward to begin.

Deactivate the newly activated plugin again.

If the website works normally afterwards, it should be checked before reactivation why the plugin is causing the error.

Possible reasons are:

• Incompatibility with PHP
• Incompatibility with WordPress
• Conflict with another plugin
• Theme conflict
• missing PHP extension
• Programming error in the 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.

Recommendation: 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? #

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.

A 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 How to fix WordPress error 500.

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 not accessible: systematically check causes.

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

Not necessarily.

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. Fix the root cause specifically.
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.

For example, the following are helpful:

• affected domain
• genaue sichtbare Fehlermeldung
• Zeitpunkt, seit dem der Fehler auftritt
• letzte Änderung vor Auftreten des Fehlers
• zuletzt aktualisiertes Plugin oder Theme
• verwendete PHP-Version
• whether the frontend and admin area are affected
• 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.

When should you contact CURIAWEB support? #

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.

Summary #

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.