How to Fix the WordPress White Screen of Death Step-by-Step

The WordPress White Screen of Death (WSOD) occurs when a fatal PHP error or exhausted memory limit halts script execution before WordPress can render any HTML output. You can fix it by enabling WP_DEBUG in your wp-config.php file to identify the failing code, raising your server’s PHP memory limit, or temporarily deactivating conflicting plugins via FTP. Always back up your site files and database before attempting any manual repairs.

What You Are Seeing (and What It Means)

Few things panic a site owner more than visiting their website and seeing nothing—just a plain, stark white screen. There are no error messages, no branding, and no admin toolbar. In some variations, the white screen appears across the entire website, while in others, it only affects the WordPress admin dashboard (/wp-admin) or a single landing page.

Since WordPress 5.2, many fatal PHP errors trigger a built-in protection system that displays a message stating, "There has been a critical error on this website." However, severe environment crashes, memory exhaustion, database timeouts, or older WordPress installations still present as a completely blank page. If you are seeing a critical error screen instead of a blank page, our guide to fixing WordPress critical errors covers those specific recovery workflows.

Because PHP fails quietly without writing details to the browser by default, the plain white screen is simply your browser rendering the empty response it received from your server. To fix it, you need to force WordPress to show you what failed.

The 4 Primary Causes of the White Screen of Death

While the symptom is always an empty screen, the root cause usually falls into one of four technical categories:

• Exhausted PHP Memory Limit: A script or plugin requested more RAM than your server allocation allows, causing PHP to kill the process instantly.
• Plugin or Theme Code Failure: A syntax error, missing function, or fatal incompatibility introduced after a plugin update, theme tweak, or PHP version upgrade.
• Corrupted Core Files: An auto-update interrupted mid-process, leaving missing or incomplete core files in wp-includes or wp-admin.
• Server Configuration or Database Timeouts: Strict file permission errors, broken .htaccess rules, or database query failures that block execution before header output.

Step 0: Perform a Manual Backup Before Editing Anything

When your admin dashboard is inaccessible, you cannot rely on standard backup plugins like UpdraftPlus or All-in-One WP Migration. Instead, log into your hosting account's cPanel, Plesk, or custom control panel (such as MyKinsta or SiteTools) and execute two safety steps:

1. File Backup: Open the File Manager, navigate to your site's root directory (usually public_html), select all files, and compress them into a .zip archive. Download this file to your local computer.
2. Database Backup: Open phpMyAdmin from your host dashboard, select your site's database, click the Export tab, and download a standard SQL dump.

Step 1: Enable WP_DEBUG to Identify the Fatal Error

To fix the screen, you must make the hidden error visible. WordPress includes a built-in debugging tool that writes PHP errors directly to the screen or to a private log file.

Connect to your site using an FTP client (like FileZilla) or your host’s File Manager. Open the wp-config.php file located in your site’s root folder.

Scroll down near the bottom where you see the line /* That's all, stop editing! Happy publishing. */. Directly above that line, look for define('WP_DEBUG', false);. If it exists, replace it with the following code snippet. If it doesn't exist, paste this snippet in:

// Enable WordPress debugging mode
define( 'WP_DEBUG', true );

// Write errors to /wp-content/debug.log
define( 'WP_DEBUG_LOG', true );

// Suppress error display on the front end to keep sensitive data hidden
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Save the file and refresh your broken website. Rather than a blank screen, you can now check the newly generated log file located at /wp-content/debug.log. Open this file and look at the bottom entries. You will likely see a line structured like this:

PHP Fatal error: Uncaught Error: Call to undefined function... in /home/user/public_html/wp-content/plugins/bad-plugin/bad-plugin.php on line 42

This single log entry tells you exactly which plugin or theme file crashed the site.

Step 2: Increase the PHP Memory Limit

If your debug.log file mentions an error like Fatal error: Allowed memory size of 67108864 bytes exhausted, your site simply ran out of memory. This often occurs when heavy plugins (like WooCommerce, Elementor, or translation tools) run concurrently.

You can request more memory directly in your configuration files:

Method A: Edit wp-config.php

Add this line near the top of your wp-config.php file, right after the opening <?php tag:

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

Method B: Edit .htaccess

If editing wp-config.php doesn't resolve the limit, open your .htaccess file (located in your root directory) and add the following line at the very end:

php_value memory_limit 256M

Note: Some budget shared hosts lock memory limits at the server level. If raising the limit in configuration files does not work, you may need your host to increase the account's allocation.

Step 3: Isolate and Deactivate the Faulty Plugin

If the error log points to a specific plugin—or if you cannot access debug logs—the fastest way to regain access is to systematically disable plugins outside the WordPress dashboard.

1. Open your FTP client or host File Manager and navigate to /wp-content/.
2. Locate the plugins folder.
3. Rename the plugins folder to plugins_deactivated.

Renaming this folder instantly forces WordPress to disable every active plugin. Try refreshing your website. If it loads normally (albeit unstyled or lacking features), a plugin was definitely responsible.

To identify the exact offender:

1. Rename plugins_deactivated back to plugins.
2. Open the plugins directory.
3. Rename individual plugin folders inside it one by one (e.g., append _old to elementor) until the site comes back online.

Once isolated, you can safely log back into your admin panel, delete the problematic plugin, or consult our guide on how to downgrade a plugin safely to restore a stable version.

Step 4: Switch to a Default WordPress Theme

If disabling plugins does not restore your site, an active theme may be executing broken code in its functions.php file. To force WordPress to drop back to a default fallback theme (like Twenty Twenty-Four):

1. Navigate to /wp-content/themes/ via FTP.
2. Locate your currently active theme folder.
3. Rename the active theme's folder (e.g., rename my-custom-theme to my-custom-theme_disabled).

When WordPress cannot find the active theme, it automatically reverts to an official default theme installed in the directory. If the site loads, your theme code is corrupted or incompatible with your current PHP version.

Step 5: Replace Corrupted Core Files

If plugin and theme deactivation fails, core WordPress system files may have been corrupted during an update or file upload.

1. Download a clean .zip copy of WordPress from WordPress.org.
2. Unpack the ZIP file on your computer.
3. Delete the wp-content folder inside the extracted files on your computer (this prevents overwriting your uploads, themes, and plugins).
4. Upload the clean wp-admin and wp-includes folders via FTP to your web server, selecting "Overwrite" when prompted.

This process refreshes all fundamental WordPress operational code without altering your database, user files, or site configuration.

How to Prevent the WSOD in the Future

Once your site is operational again, implement these precautionary measures to protect against future downtime:

When to Call a Senior WordPress Engineer

While most WSOD incidents can be resolved using the steps above, complex scenarios require expert intervention—especially if:

• The error log shows database corruption or unexplained PDO exceptions.
• Your site is an active WooCommerce store where manual troubleshooting risks dropping orders.
• Disabling plugins and re-uploading core files yields no change, suggesting severe server environment or object caching conflicts.
• You are uncomfortable editing configuration files via FTP or cPanel.

If you need your site fixed rapidly without taking on technical risk, consider hiring Mend's Quick Fix service. Our senior engineers isolate and resolve errors fast using safe, backup-first workflows. If your site is currently offline and losing revenue, submit an Emergency Rescue request or connect your site securely to get back online today.