The dreaded WordPress White Screen of Death (WSOD) is a blank, empty digital space. It is a catastrophic sight for any website owner. While it looks bad, the problem is almost always solvable.
This guide is your roadmap. We will go beyond simple fixes. We will explain not just what to do, but also why you are doing it. By the end, you will have the confidence to fix the WSOD and bring your site back online.
What Is the WordPress White Screen of Death?
The WSOD happens because of a fatal PHP error. Your WordPress site is like a play. PHP is the script the actors (plugins, themes, core files) follow. If an actor messes up their lines or gets a nonsensical instruction, the entire show stops. The script stops running. You are left with a silent, empty stage, which is the white screen
WSOD vs. the Critical Error Screen
WordPress versions 5.2 and newer might show a more helpful message: “There has been a critical error on this website.” This is a good sign. It means the WordPress error protection system caught the fatal error. It loaded a basic error page. The true, classic WSOD means the error happened so early or was so severe that even WordPress’s error handler could not run. The steps to fix both are the same.
When you see a critical error message instead of a white screen, WordPress is actually trying to help. It means Recovery Mode caught the crash before it went blank. You can follow our step-by-step Critical Error Fix guide to use Recovery Mode effectively — or handle the issue manually if the email never arrives.
Why the WSOD Happens
Knowing the root cause is critical. The problem almost always comes from one of five areas.
- Plugin Incompatibility: This is the most common cause. A plugin might conflict with another plugin, your theme, or your WordPress version. This often happens after an update. Two pieces of code try to do the same thing in different ways.
- A Faulty Theme: Your theme could be the problem. Bad code, a syntax error in the functions.php file, or a corrupted theme file can take your site down. This is common when you add custom code snippets.
- Exhausted PHP Memory Limit: Your website gets a certain amount of server memory (RAM) to run. A script or a resource-heavy plugin might need more memory than is available. It will then crash. Think of it like a computer program freezing because it ran out of RAM.
- File Permission Issues: Your server has a permission system. It controls who can read, write, and run files. If these permissions are wrong, WordPress might be blocked from using the files it needs. This causes a WSOD.
- Corrupted Core Files or .htaccess: Sometimes, a WordPress update gets interrupted. This can corrupt a core file. The .htaccess file controls your site’s permalinks. It can also get corrupted. This will stop pages from loading.
The Action Plan: A Step-by-Step Guide
Work through these steps in order, from simplest to most complex. Before you start, if you have a recent backup, make sure it is safe.
Method 1: The Basics – Clearing All Caches
Skill Level: Beginner | Risk Level: Low
Caching makes your site faster. A corrupted cache file, however, can serve a broken version of your site. You need to clear caches in multiple places.
- Browser Cache: Your browser stores old versions of websites. Force a hard refresh (Windows: Ctrl+F5, Mac: Cmd+Shift+R). You can also clear your browser’s cache through its settings. This makes sure you are not seeing a broken, cached error.
- Plugin Cache: If you use a caching plugin like WP Rocket, you must purge its cache. If you cannot get to your admin dashboard, you will have to use FTP. Connect to your server. Delete the contents of the wp-content/cache/ folder.
- Server Cache: Many managed hosts (like Kinsta, WP Engine, SiteGround) have their own server-level caching. Log in to your hosting control panel. Look for an option like “Purge Cache” or “Clear Varnish.”
- CDN Cache: If you use a CDN like Cloudflare, log in to your CDN dashboard and purge the cache from there.
Method 2: Check for WordPress Recovery Mode
Skill Level: Beginner | Risk Level: Low
Modern WordPress has a built-in safety net.
- Check Your Admin Email: Go to the inbox for the administrator email address. Check the spam folder.
- Find the Email: The subject line will be “Your Site is Experiencing a Technical Issue.”
- Use the Recovery Link: This email has a unique, secure link. It lets you log in to your dashboard in “Recovery Mode.” This mode automatically turns off the plugin or theme causing the error. You can get to your site again.
- Follow the Instructions: Once you are logged in, WordPress will tell you what caused the problem. You can then fix it by updating or deleting the faulty plugin or theme.
If you do not get this email, the error is likely happening before the WordPress mail function can even load. Go on to the next step.
Method 3: Increase PHP Memory Limit
Skill Level: Intermediate | Risk Level: Medium
This is a very common fix. It is helpful for growing sites or those using complex plugins like WooCommerce. You will edit wp-config.php, your site’s core file. Always make a backup of this file before editing.
- Connect via FTP/File Manager: Use an FTP client like FileZilla or your host’s cPanel File Manager to get to your site’s files.
- Locate wp-config.php: This file is in the main directory of your WordPress site.
- Edit the File: Open wp-config.php. Find the line: /* That’s all, stop editing! Happy blogging. */.
Add the Code: Just before that line, add this code:
define(‘WP_MEMORY_LIMIT’, ‘256M’);
If this line already exists, just increase the value. 256M is a good starting point. Large e-commerce sites might need 512M. - Save and Upload: Save your changes. Upload the file back to the server. Check your site.
If this does not work, your host may have a hard limit on memory. You can try adding php_value memory_limit 256M to your .htaccess file. The best way is to contact your hosting provider. Ask them to increase the PHP memory limit for your account.
Method 4: The Plugin Purge (The Most Common Fix)
Skill Level: Intermediate | Risk Level: Medium
If the memory fix did not work, check for a plugin conflict. The strategy is to turn off all plugins. See if the site comes back.
Scenario A: You Can Access /wp-admin
- Go to Plugins → Installed Plugins.
- Click the checkbox at the top to select all plugins.
- From the “Bulk Actions” dropdown, select Deactivate. Hit Apply.
- If your site returns, a plugin is the cause. Now, turn them on one by one. Reload the site after each one. The one that brings back the white screen is the problem.
Scenario B: You Cannot Access /wp-admin
You will need to use FTP for this.
- Connect to your server via FTP. Go to your wp-content folder.
- Find the plugins folder.
- Right-click. Rename it to plugins_disabled. This turns off all plugins.
- Check your site. It should now be visible. It might look broken because plugin features are missing.
- If the site is back, you know it is a plugin. Go back to your FTP client. Rename plugins_disabled back to plugins.
- Log in to your WordPress dashboard. All plugins will be off. Turn them on one by one until you find the one causing the white screen.
Method 5: Test Your Theme
Skill Level: Intermediate | Risk Level: Medium
If plugins are not the issue, your theme is the next suspect. The goal is to go back to a default WordPress theme.
- Connect via FTP. Go to wp-content/themes/.
- If you have a default theme folder (like twentytwentyfour), go to step 3. If not, download a fresh copy from WordPress.org. Upload the folder here first.
- Find the folder of your current theme. Rename it to mytheme_disabled.
- This will force WordPress to use the available default theme.
- Check your site. If it is back online, the problem is in your theme.
If your theme was the cause, check its functions.php file. Look for any new custom code or blank spaces at the beginning or end of the file. If you are not sure, contact the theme’s developer. You could also restore the theme from a fresh download.
Method 6: Unleash the Debug Mode
Skill Level: Advanced | Risk Level: Low
If you are still stuck, it is time to stop guessing. WordPress’s debug mode will show you the exact PHP error.
- Open your wp-config.php file again using FTP.
- Find the line: define( ‘WP_DEBUG’, false );.
- Change false to true.
- Right below it, add these lines. This logs the errors to a private file instead of showing them on your live site. It is much more secure.
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false ); - Save the file and reload your broken website. The screen will likely still be white.
- Now, go to your wp-content folder using FTP. You will find a new file called debug.log.
- Download and open this file. It will contain the specific error message. It will also show the file path and the exact line number.
An example error might look like this:
Fatal error: Call to undefined function some_function() in /home/user/public_html/wp-content/plugins/bad-plugin/bad-file.php on line 55
This tells you everything: the error is in a plugin called “bad-plugin.” It is inside bad-file.php on line 55. This information is very helpful.
Once you enable debugging, your debug.log file will show what’s causing the issue. If you’re not sure how to read that file, here’s a complete guide to using WordPress error logs for debugging.
CRITICAL: When you are done, always change WP_DEBUG back to false in your wp-config.php file.
Method 7: Fix a Corrupted .htaccess File
Skill Level: Advanced | Risk Level: Medium
The .htaccess file manages your site’s URL structure. If it is corrupted, it can cause a site-wide WSOD.
- Connect via FTP. Find the .htaccess file in your main directory.
- Rename the file to .htaccess_old.
- Now, try to load your site. If it works, you have found the issue. Some internal links might be broken.
- To fix it, log in to your WordPress dashboard. Go to Settings → Permalinks. Just click the Save Changes button. This will create a fresh, clean .htaccess file.
Method 8: The Failsafe – Restore From a Backup
Skill Level: Intermediate | Risk Level: Medium
If you have tried all other options, restoring from a backup is the most reliable way to get your site back.
- Log in to your hosting control panel (cPanel, Plesk, etc.).
- Go to your host’s backup tool (e.g., JetBackup, SiteBackup).
- Select a restoration point from a date before the white screen appeared.
- Make sure you restore both the files and the database for a full restoration.
- Follow the on-screen instructions. The process can take a few minutes or up to an hour.
This will undo any changes made since the backup was created. But it will fix the problem.
Prevention: How to Stop the WSOD
Fixing is good, but preventing is better. Follow these practices.
- Automated Backups: Use a trusted plugin like UpdraftPlus or your host’s backup service. Make sure backups run daily. Store them off-site.
- Use a Staging Environment: A staging site is a private clone of your live site. Before you update any plugin, theme, or WordPress core on your live site, test it on the staging site first. Many managed hosts offer one-click staging.
- Vet Your Plugins/Themes: Do not install software blindly. Check reviews. See when it was last updated. Make sure it is compatible with your WordPress version.
- Enable Auto-Updates (Wisely): Auto-updates are a good idea for minor security releases of WordPress core. They are also good for well-regarded plugins. For big updates, it is always better to test on staging first.
By being methodical and understanding the “why” behind each step, you can change the White Screen of Death from a crisis into a puzzle you can solve. You now have the full toolkit to find the issue, fix it, and get your website back online.
The White Screen of Death is just one of many common WordPress issues. For a full list of frequent problems and solutions, check out our complete guide on the 20 most common WordPress errors and how to fix them.
