How to Fix the WordPress White Screen of Death

You open your WordPress site and get a blank white page. No error message, no broken layout, just white. The admin panel does the same thing. Everything was working an hour ago and now there’s nothing.

This is the WordPress White Screen of Death (WSOD), and despite the dramatic name, it’s one of the most common WordPress errors. It’s also one of the most fixable. The white screen means PHP hit a fatal error and couldn’t produce any output. WordPress tried to load, something broke during execution, and the page came back empty.

The fix depends on what caused it. In most cases, it’s a plugin, a theme, or a memory limit. This guide walks through each possibility in order, starting with the most likely cause.

What causes the White Screen of Death#

The WSOD happens when PHP encounters a fatal error that prevents WordPress from rendering any output. Four things cause this in practice:

Plugin conflicts. This is the cause the majority of the time. A plugin update introduces a bug, two plugins conflict with each other, or a plugin isn’t compatible with your PHP version. Since WordPress loads all active plugins on every page request, one broken plugin takes down the entire site.

Theme errors. A theme with a PHP syntax error or an incompatible function call will crash WordPress just as effectively as a bad plugin. This typically happens after a theme update or when switching to a new theme.

PHP memory exhaustion. WordPress and its plugins need memory to run. If a page request exceeds the PHP memory limit (often set to 128MB or lower by default), PHP terminates execution and produces a white screen. Complex pages, large plugins, or inefficient code can push memory usage over the limit.

Corrupted core files. Less common, but possible. A failed update, a disk error, or a compromised file can corrupt WordPress core files in wp-includes or wp-admin , causing fatal errors on every request.

Before you start: enable error display#

By default, WordPress hides PHP errors to avoid showing them to visitors. That’s good for production but terrible for debugging. Before you start troubleshooting, turn errors on so you can see what’s actually failing.

Connect to your server via FTP or your hosting provider’s file manager, open wp-config.php in the root directory, and find this line:

define('WP_DEBUG', false);

Change it to:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);

Now reload the white screen. Instead of a blank page, you should see a PHP error message pointing to the specific file and line number that caused the crash. That error message often tells you exactly what to fix.

If you’d rather not display errors publicly, leave WP_DEBUG_DISPLAY as false and check the log file at wp-content/debug.log instead. Errors will be written there silently.

Important: Turn WP_DEBUG back to false once you’ve resolved the issue. You don’t want PHP errors visible to your visitors on a live site.

Step 1: Back up your site#

Before changing anything, back up your files and database. If your hosting provider offers snapshot-based backups or a control panel backup tool, create one now. If not, download your files via FTP and export your database through phpMyAdmin.

This takes a few minutes but saves you from turning a fixable problem into a catastrophic one.

Step 2: Check if it's a plugin#

Plugins are the most common WSOD cause, so start here.

If you can see the PHP error message from enabling WP_DEBUG, it will typically reference a file path like /wp-content/plugins/plugin-name/some-file.php . That tells you exactly which plugin is the problem. Deactivate or delete that plugin’s folder via FTP.

If you can’t see an error or aren’t sure which plugin, deactivate all plugins at once:

1. Connect to your site via FTP or file manager
2. Navigate to  wp-content/
3. Rename the  plugins  folder to  plugins_disabled
4. Load your site

If the site comes back, a plugin was the cause. Now narrow it down:

1. Rename  plugins_disabled  back to  plugins  (this won’t reactivate them; WordPress deactivated them when the folder disappeared)
2. Log into the WordPress admin panel
3. Reactivate plugins one at a time, reloading your site after each one
4. When the white screen returns, you’ve found the culprit

Once you identify the problem plugin, you have a few options: check if there’s a newer version that fixes the issue, contact the plugin developer, find an alternative plugin, or remove it if it’s not essential.

Step 3: Check the theme#

If deactivating all plugins didn’t fix it, the theme is the next suspect.

1. Via FTP, navigate to  wp-content/themes/
2. Rename your active theme’s folder (e.g., rename  theme-name  to  theme-name_disabled )
3. Load your site

WordPress will fall back to a default theme (Twenty Twenty-Five, Twenty Twenty-Four, etc.) if one is installed. If the site loads with the default theme, your original theme has a fatal error.

If no default theme is installed, download one from wordpress.org/themes and upload it to the themes directory via FTP.

Common theme fixes:

• Update the theme to the latest version
• If you recently edited theme files (functions.php, template files), revert those changes
• Check that the theme is compatible with your PHP version. Themes built for PHP 7 may break on PHP 8 due to deprecated functions

Step 4: Increase PHP memory limit#

If your site loads some pages but crashes on others (especially complex pages or the admin dashboard), PHP memory exhaustion is likely the cause.

Open wp-config.php and add this line before /* That's all, stop editing! */ :

define('WP_MEMORY_LIMIT', '256M');

For the admin area specifically, you can set a higher limit:

define('WP_ADMIN_MEMORY_LIMIT', '512M');

Save the file and reload your site.

If this fixes the problem, something on your site is using more memory than it should. This is worth investigating even after the immediate fix. Common memory hogs:

• Image-heavy pages loading all images at full resolution
• Plugins that load large datasets into memory (some analytics, logging, or import/export plugins)
• Poorly written theme functions that run expensive database queries on every page load

You can also increase the memory limit in php.ini or .htaccess if your host allows it:

php.ini:

memory_limit = 256M

Apache .htaccess:

php_value memory_limit 256M

Note that some hosting providers set a hard memory cap that can’t be overridden from WordPress or php.ini. If the increase doesn’t take effect, check with your host about the maximum allowed limit on your plan.

Step 5: Replace core files#

If plugins and theme aren’t the issue and memory is sufficient, corrupted core files might be the cause. This is uncommon but worth trying when nothing else works.

1. Download a fresh copy of WordPress from wordpress.org
2. Extract the archive on your computer
3. Via FTP, upload the  wp-includes  and  wp-admin  folders from the fresh download to your server, overwriting the existing ones
4. Do not overwrite  wp-content  (that’s your content, themes, and plugins) or  wp-config.php  (that’s your configuration)

This replaces every core file without touching your content or settings. If a corrupted core file was the cause, this resolves it cleanly.

Step 6: Check for a PHP upgrade issue#

Sometimes the WSOD appears after your hosting provider upgrades PHP. Code that worked on PHP 7.4 might throw fatal errors on PHP 8.0 or 8.1 due to removed functions or stricter type handling.

Check your PHP error log for messages like:

• Uncaught Error: Call to undefined function
• Fatal error: Cannot use string offset as an array
• Deprecated: Function xxx is deprecated

If the errors reference deprecated or removed PHP functions, the fix is updating the plugin or theme that uses them. If that’s not possible, ask your host to switch your site back to the previous PHP version temporarily while you sort out compatibility.

Step 7: Check server error logs#

If none of the above steps resolve the WSOD, the problem might be at the server level rather than WordPress itself. Check your server’s error log:

Apache:

tail -50 /var/log/apache2/error.log

Nginx:

tail -50 /var/log/nginx/error.log

Look for entries timestamped around when the WSOD started. Common server-level causes include:

• PHP-FPM crashing or running out of worker processes
• File permission issues preventing PHP from reading WordPress files
• Disk space running out (PHP can’t write temporary files or session data)
• .htaccess  errors (Apache) or server configuration errors (Nginx)

Step 8: Get help#

If you’ve worked through every step and the white screen persists, something unusual is going on. At this point:

• Contact your hosting provider’s support team. They can check server-level logs and resource limits that you might not have access to
• If you have a staging environment or local development copy, try reproducing the issue there
• Consider hiring a WordPress developer for a one-time diagnostic. An experienced developer can usually identify stubborn WSOD causes in under an hour

Preventing the WSOD in the future#

The WSOD is almost always caused by something that changed. An update, a new plugin, an edited file. A few habits minimize the risk:

Update in stages, not all at once. Update one plugin at a time and check your site after each one. If something breaks, you know exactly what caused it. Updating everything at once makes it much harder to isolate the problem.

Keep a staging environment. Test updates on a copy of your site before applying them to production. This catches breaking changes before your visitors see them.

Monitor your PHP error log. Even when your site is working, PHP warnings and deprecation notices in the log can signal problems that will become fatal errors later, especially before a PHP version upgrade.

Use reputable plugins and themes. Plugins with active development, recent updates, and large user bases are less likely to contain code that crashes your site. Abandoned plugins with no updates in over a year are a risk.

Keep backups current. When the WSOD hits, a recent backup means the worst-case scenario is a few hours of lost work, not a lost website. Automated daily backups are ideal.

Check out the WordPress troubleshooting documentation for additional reference.

Try Hostney web hosting free for 14 days. Every plan includes daily backups, one-click plugin management, and support from a team that actually knows WordPress.