WordPress White Screen of Death: How to Fix It, Step by Step

You open your site and see nothing. No error text, no message, just an empty white surface. The admin area at /wp-admin often stays just as white. Welcome to the WordPress white screen of death, usually shortened to WSoD.

The good news first: the WSoD is rarely a sign of destroyed data or a hacked server. In most cases a single PHP error is behind it, one that forces WordPress to abort before it can even output an error message. This article walks through how to find the cause systematically and get your site back online.

What the white screen of death actually is

Technically the white screen is not an error type of its own. It is the visible symptom of a fatal error in PHP: a plugin or theme calls a function that does not exist, exceeds the memory limit, or aborts in some other way. Error output is disabled by default on production WordPress sites so that visitors never see internal server paths.

That is exactly the problem. Without that output the page aborts cleanly but gives you no hint about what went wrong. The WSoD looks opaque at first for that reason alone, even though the cause is almost always clearly identifiable as soon as you switch error output back on.

Step 1: Stay calm and check your backup

Before you change anything, a short but important intermediate step: check whether and when a backup of your site was last created. Most hosts offer automatic daily backups, and many backup plugins do the same. A current backup is your safety net and lets you jump back to the last working state instead of searching for hours. If none exists, trigger one manually now, as far as your host or plugin still allows, before you start editing files or the database.

Step 2: Enable WP_DEBUG and read debug.log

This is the single most important move. Using FTP or your host's file manager, open wp-config.php in the WordPress root directory and find the line define('WP_DEBUG', false);. Replace it with the following block, directly above the line /* That's all, stop editing! */:

• define('WP_DEBUG', true); switches on debug mode in general
• define('WP_DEBUG_LOG', true); writes all errors to a log file instead of only displaying them
• define('WP_DEBUG_DISPLAY', false); prevents errors from appearing live on the site for every visitor

Save the file, reload the site once, and then open the newly created file at wp-content/debug.log. It normally states exactly which file, which function and which line triggered the fatal error, usually with a message such as "Fatal error: Uncaught Error: Call to undefined function" or "Allowed memory size exhausted". That one line is the key to the solution.

Set WP_DEBUG back to false once you have fixed the problem. A permanently enabled debug log is an unnecessary security and performance risk.

Step 3: Look at your host's error log

If you cannot reach wp-config.php by FTP or file manager at all, or if debug.log stays empty, there is a second place to look: your host's server-side error log. Almost every hosting panel, whether Plesk, cPanel or a custom customer area, offers an error log section that records PHP errors independently of WordPress.

This source is particularly valuable when the error occurs so early that WordPress has not been able to process its own configuration yet. If you find nothing there, ask your host's support directly for the most recent PHP error entries for your domain.

Step 4: Isolate the plugin conflict

The vast majority of white screen cases trace back to a single plugin, frequently right after an update. Here is how to go about it:

• 1. Deactivate all plugins: connect by FTP and rename the folder wp-content/plugins, for example to plugins-off. WordPress no longer recognises the plugins and effectively deactivates all of them at once.
• 2. Test the site: if your site loads again, a plugin was the cause. Rename the folder back to plugins, and they stay deactivated for now.
• 3. Reactivate one by one: in the admin area under Plugins, activate one after another and reload after each step. As soon as the white screen returns, you have found the culprit.
• 4. Alternative via the database: if FTP is not an option either, you get the same effect through phpMyAdmin by setting the active_plugins entry in the wp_options table to a:0:{}.

Once you have identified the plugin responsible, update it to the latest version or check the support forum for other users reporting the same error. If the problem persists, a leaner alternative is usually a more durable solution than a permanently deactivated plugin.

Step 5: Switch to a default theme

If plugin isolation does not solve it, the active theme is next. FTP or phpMyAdmin works here too if the admin area is unreachable: rename the folder of your active theme in wp-content/themes. WordPress then falls back automatically to an installed default theme such as Twenty Twenty-Four. If the site loads now, the error was in the theme, for example in functions.php or an outdated child theme. Check whether a theme update is available, or contact the developer.

Step 6: Raise the PHP memory limit

If debug.log or the error log contains a message such as "Allowed memory size of X bytes exhausted", the cause is clear: WordPress requested more memory than it is allowed, often triggered by several memory hungry plugins running at the same time. Add the following line to wp-config.php, above the line /* That's all, stop editing! */:

• define('WP_MEMORY_LIMIT', '256M'); raises the WordPress memory limit to 256 megabytes

If that is not enough, the server-side PHP limit is often lower than the WordPress limit and has to be raised additionally through your host's php.ini. Note that a raised memory limit only treats the symptom, not the cause. A plugin that regularly hits the memory ceiling is generally just written too greedily.

Step 7: Check your PHP version

The white screen not infrequently appears right after your host switches PHP versions, because an older plugin or theme is not compatible with the new one. Check in your hosting control panel which PHP version is active and compare it with the minimum requirements of your plugins. If in doubt, switching back to the previous version as a test confirms whether that was really the cause.

Step 8: Use recovery mode and the recovery email

Since WordPress 5.2 the core ships with a built-in lifeline. When WordPress detects a fatal error, it automatically sends an email to the stored administrator address containing a link to recovery mode. That link gets you into the admin area even while the site stays white for visitors, and shows you directly which plugin or theme caused the error, including an option to deactivate it as a test. Check your inbox and your spam folder first. The solution is often two clicks away.

Step 9: Reset .htaccess

Considerably rarer, but possible: a faulty .htaccess file can also produce a white screen or a 500 server error, for example after a manual edit or a failed plugin update. Rename the file by FTP as a test, for example to htaccess-backup, and reload the site. If it works now, WordPress generates a new, clean file automatically under Settings, Permalinks as soon as you save there once.

Afterwards, make sure no internal links suddenly lead nowhere. Our comparison of free WordPress redirect plugins covers how to catch the resulting 404 errors and route them to sensible targets.

When to bring in your host

Most white screen cases can be solved with the steps above. There are clear limits, though: when you have no FTP or file manager access at all, when the error log points to a server problem rather than PHP code, when memory limits are locked down server side, or when you are unsure about editing the database directly. A good host can usually look into the server log within minutes and tell you the exact cause, often faster than trying every possibility yourself.

The real cause: why the WSoD happens at all

For all the step by step guidance, it is worth looking at the root. In our experience as a plugin vendor the most common trigger is almost always the same: badly written, overloaded or outdated plugins and themes that become incompatible after a PHP update, or throw a fatal error because internal functions are not properly guarded. The more plugins are running, the more of them are all-rounders with an enormous feature set, and the longer one of them has gone without an update, the higher the probability of the next white screen.

An honest note in our own interest, since as a plugin vendor we are not entirely neutral: lean, well maintained plugins reduce that risk noticeably. A plugin that solves exactly one job cleanly carries far less code that can break than a bloated all-rounder dragging every feature along whether you need it or not. That is the principle behind Linkjet, MemberJet and Adjet: free, lean GPLv2 plugins, actively maintained and deliberately limited to a clear functional core. Our theme Hafen carries the same thinking through to the theme layer. Every plugin comes with a free tier, so you can check the footprint before you spend anything, and the pricing overview shows what the paid tiers add.

For more on keeping your site lean and stable overall, see our guide on speeding up a slow WordPress site in ten steps.

What to take away

The WordPress white screen of death looks like a total failure at first glance, but it is almost always a single, clearly identifiable fatal error. Enable WP_DEBUG, read debug.log or the error log, isolate plugins and theme systematically, check the memory limit and the PHP version, and use recovery mode and the recovery email if in doubt. With these nine steps you can usually get your site back online yourself, and with lean, well maintained plugins you make sure the next white screen does not happen in the first place.

Frequently asked questions