WordPress White Screen of Death

You load your website and get absolutely nothing. No error message. No warning. No WordPress. Just an empty white page staring back at you like it pays the hosting bill.

Welcome to the infamous WordPress White Screen of Death, commonly shortened to WSOD.

What Is the White Screen of Death?

A WordPress White Screen of Death usually means PHP encountered a serious error before WordPress was able to finish generating the page.

Instead of showing the actual error, PHP or WordPress may have error display disabled. The result is exactly what you just experienced:

A whole lot of nothing. Blank page. White screen. Zero useful information.

The most common causes include:

A broken or incompatible WordPress plugin
A broken or incompatible theme
A PHP fatal error
An unsupported PHP version
Exhausted PHP memory
A failed WordPress update
Damaged or missing WordPress core files
Bad code added to functions.php
A malformed wp-config.php file
Corrupted cache
File permission or ownership problems

Step-by-Step Troubleshooting

Step 1: Check Whether the Entire Site Is Broken

Before changing anything, determine exactly what is affected.

Try loading:

https://yourdomain.com/ https://yourdomain.com/wp-admin/ https://yourdomain.com/wp-login.php

The result can help narrow things down.

Frontend white, wp-admin works: the problem may be related to the active theme or frontend code.
Frontend works, wp-admin white: an admin-side plugin or PHP error may be involved.
Everything is white: begin looking for a plugin, PHP, configuration, or core WordPress failure.

Before making changes: If possible, create a backup of the site's files and database first.

Step 2: Check the WordPress Recovery Email

Modern versions of WordPress can detect certain fatal PHP errors and send the site administrator an email.

The subject may look similar to:

Your Site is Experiencing a Technical Issue

That email may identify the exact plugin, theme, or PHP file responsible for the crash.

It may also contain a special WordPress Recovery Mode login link.

Check the inbox and spam folder for the administrator email address configured in WordPress.

Step 3: Enable WordPress Debug Logging

If WordPress isn't telling you what is broken, make it keep a record.

Open:

wp-config.php

Find:

define('WP_DEBUG', false);

Change it to:

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

If the constants do not already exist, add them immediately before:

/* That's all, stop editing! Happy publishing. */

Reload the broken page and then check:

/wp-content/debug.log

Look near the bottom of the file for messages containing phrases such as:

PHP Fatal error
Uncaught Error
Allowed memory size exhausted
Call to undefined function
Class not found
Parse error

Do not leave debugging enabled forever. Once troubleshooting is finished, change WP_DEBUG back to false unless you specifically need continued debugging.

Step 4: Disable All Plugins

Plugins are one of the most common causes of WordPress fatal errors.

If you can access wp-admin, go to:

Plugins → Installed Plugins

Deactivate all plugins and reload the site.

If wp-admin is also unavailable, use your hosting File Manager, FTP, SFTP, or SSH and locate:

/wp-content/plugins/

Rename the directory:

plugins to plugins-disabled

Reload the website.

If the website starts working: A plugin is almost certainly involved.

Rename the directory back to:

plugins

Then activate plugins one at a time until the problem returns.

The last plugin activated before the crash is your prime suspect.

Step 5: Test the Active Theme

Themes can cause exactly the same type of fatal PHP errors as plugins.

Open:

/wp-content/themes/

Find the currently active theme directory.

For example:

/wp-content/themes/mytheme/

Rename it:

mytheme-disabled

If a default WordPress theme is installed, WordPress may attempt to fall back to it.

Examples include:

Twenty Twenty-Five
Twenty Twenty-Four
Twenty Twenty-Three

If switching themes restores the site, inspect the original theme's functions.php, custom PHP files, recent updates, and any code added shortly before the problem appeared.

Step 6: Check the PHP Version

WordPress itself may support your PHP version while an older plugin or theme does not.

A PHP version change can expose old code that previously appeared to work.

Common errors caused by PHP incompatibility include:

Call to undefined function Too few arguments Uncaught TypeError Deprecated function Parse error Class not found

Check the PHP version assigned to the domain through your hosting control panel.

Do not randomly change PHP versions without knowing why. A temporary PHP version change can be useful for diagnosis, but the better long-term fix is usually updating or replacing the incompatible plugin, theme, or custom code.

Step 7: Check for PHP Memory Exhaustion

If WordPress runs out of PHP memory, you may see an error similar to:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

That means PHP reached its configured memory limit.

You can sometimes increase the WordPress memory limit in wp-config.php:

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

However, increasing the limit does not automatically fix the underlying cause.

A plugin consuming hundreds of megabytes of memory may still be broken. Giving broken software more memory sometimes just lets it break more enthusiastically.

Step 8: Check the Server Error Logs

If WordPress does not create a useful debug.log, the server may still have recorded the error.

Depending on the hosting environment, check for logs such as:

error_log php_error.log Apache error log LiteSpeed error log PHP-FPM error log

On cPanel hosting, individual websites may also have an error_log file inside the site's directory.

Search for entries generated at the same time you loaded the white screen.

The timestamp matters. If you reload the broken page at 2:17 PM and immediately see a new fatal error logged at 2:17 PM, you've probably found something useful.

Step 9: Clear WordPress and Server Cache

Sometimes the fatal error has already been repaired but a cache layer continues serving the broken response.

Clear any applicable:

WordPress caching plugin cache
LiteSpeed Cache
Object cache
Redis cache
Memcached
Server-side page cache
Cloudflare cache
Browser cache

Then test the website again using a private/incognito browser window.

Step 10: Check WordPress Core Files

An interrupted update, failed upload, or damaged WordPress installation can leave core files missing or incomplete.

The safest repair method is normally to replace WordPress core files with clean copies from the same or current supported WordPress release.

Do not overwrite wp-content or wp-config.php. Those contain your website content, plugins, themes, uploads, and configuration.

Core directories that can normally be replaced with clean WordPress copies include:

/wp-admin/ /wp-includes/

WordPress root PHP files can also be replaced, while preserving:

wp-config.php wp-content/

Step 11: Check wp-config.php for Syntax Problems

A single missing quote, semicolon, bracket, or PHP tag can prevent WordPress from starting.

Pay special attention to anything recently added to:

wp-config.php

Examples include:

Debugging constants
Memory limit changes
Database settings
Security keys
Custom PHP
Cache configuration

Do not post wp-config.php publicly. It contains sensitive database credentials and authentication keys.

Step 12: Think About What Changed

This sounds painfully obvious, but it is one of the best troubleshooting questions available:

What changed immediately before the site broke?

Did you:

Update a plugin?
Install a plugin?
Update WordPress?
Change PHP versions?
Edit functions.php?
Add a code snippet?
Change wp-config.php?
Restore a backup?
Move the website?
Change hosting?
Enable caching?

Start with the most recent change before dismantling the entire site.

Step 13: Restore a Backup If Necessary

If the site was working recently and the cause cannot be repaired quickly, restoring a known-good backup may be the fastest recovery option.

Ideally restore both:

Website files
WordPress database

Be careful with active websites. Restoring an older database may remove recent orders, form submissions, users, comments, settings, or content.

For ecommerce or frequently updated websites, restoring only the damaged files may be safer than blindly restoring the entire database.

The Fast Troubleshooting Order

If you just want the quickest route through the problem, use this order:

Check whether the frontend and wp-admin are both affected.
Look for the WordPress Technical Issue email.
Enable WP_DEBUG_LOG.
Reload the broken page.
Check /wp-content/debug.log.
Check the server PHP/error logs.
Disable all plugins.
Test the active theme.
Verify the PHP version.
Check for memory exhaustion.
Clear caches.
Repair WordPress core files if necessary.

Once the Site Is Working Again

Don't immediately close File Manager and pretend none of this ever happened.

Take a few minutes to clean things up.

Disable WordPress debugging if it is no longer required.
Remove or replace the broken plugin or theme.
Update WordPress core.
Update supported plugins and themes.
Remove abandoned plugins.
Verify your PHP version is supported.
Clear all caches.
Create a fresh backup.
Test the frontend and wp-admin.

Congratulations. Your website has progressed from existential void back to actual WordPress.

Still Getting a White Screen?

If you've gone through the steps above and the site is still completely blank, collect as much information as possible before asking for help.

Useful information includes:

The exact URL showing the white screen
Whether wp-admin works
When the problem started
What changed beforehand
Your PHP version
Your WordPress version
The latest error from debug.log
The latest PHP/server error
Whether disabling plugins changes anything
Whether changing themes changes anything

An actual PHP error message is approximately 4,000 times more useful than:

Website broke. Please fix.