Your WordPress site loads a blank white page. No error, no warning, nothing. You refresh and get the same blank page. You check your hosting control panel and the server is running fine. That’s the WordPress White Screen of Death, usually shortened to WSOD.
Here’s the reassuring part: it almost always comes down to one of four causes, and every one of them is fixable without losing any data. The steps below are ordered from most likely to least likely, and in my experience most people are back up and running by step 2 or 3.
Before you start: check whether the blank screen shows up on your site’s front end, in wp-admin, or both. That single detail narrows down the cause quite a bit, and it’s covered in the scenario breakdown further down.
What Causes the WordPress White Screen of Death?
Four causes account for the vast majority of WSOD incidents:
- PHP memory exhausted: WordPress ran out of memory mid-execution and produced no output instead of an error page
- Plugin conflict: a plugin update, or a newly installed plugin, contains a PHP fatal error
- Theme error: a syntax error in
functions.phpor a template file crashes PHP before anything renders - WordPress core update failure: an incomplete update left core files in a mixed state
Less common causes: a corrupted .htaccess file, incorrect file permissions, or a stale opcode cache serving a broken file after a recent change.
Step 1: Enable WP_DEBUG to Find the Actual Error
Before trying anything else, turn on WordPress’s error logging and let it tell you exactly what broke. Open wp-config.php through FTP or your host’s file manager, and add these three lines just above the line that reads /* That's all, stop editing! */:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Setting WP_DEBUG_DISPLAY to false keeps errors out of the browser and routes them to /wp-content/debug.log instead, which matters if your site still has visitors landing on that blank page. Reload the site after saving the file, then open /wp-content/debug.log in your FTP client or file manager.
Whatever broke will be right there in the log: a specific plugin file, your theme’s functions.php, or a WordPress core file. See Allowed memory size of X bytes exhausted? Skip ahead to Step 2. Named plugin file? Go to Step 3.
Step 2: Increase the PHP Memory Limit
PHP memory exhaustion is the single most common cause of WSOD. WordPress requires a minimum of 64MB, but complex sites with WooCommerce, a page builder, and multiple active plugins routinely need 256MB or more.
Add this line to wp-config.php (above the stop-editing line):
define('WP_MEMORY_LIMIT', '256M');If that doesn’t take effect (some hosts override it), try adding this to .htaccess in your WordPress root:
php_value memory_limit 256MIf neither change sticks, your hosting plan has a hard memory cap set at the server level. Contact your host and ask them to raise PHP memory to at least 256MB. This is where shared hosting tends to hit a wall; memory becomes the limiting factor long before anything else does.
Step 3: Deactivate All Plugins
Plugin conflicts are the most common cause of WSOD right after an update. Deactivating everything at once is the fastest way to find out if a plugin is responsible: if the site comes back, you reactivate plugins one at a time until the white screen returns.
If you can access wp-admin: Go to Plugins → Installed Plugins, check the box at the top to select all, then Bulk Actions → Deactivate → Apply. If the site now loads, reactivate plugins one at a time. Whichever one you turn back on right before the white screen reappears is the cause.
If wp-admin is also blank (use FTP): Connect to your server via FTP (FileZilla is the most common client). Navigate to /wp-content/ and rename the plugins folder to plugins_disabled. WordPress can no longer load any plugin at all. If the site loads now, rename the folder back to plugins, then deactivate and re-enable plugins one at a time from wp-admin.
If you’ve got a lot of plugins installed, testing them one at a time gets tedious fast. The plugin conflict diagnosis guide walks through a binary-search approach instead: halve the active set each round rather than toggling plugins one by one.
Step 4: Switch to a Default WordPress Theme
If deactivating plugins didn’t fix it, look at your theme next. A syntax error in functions.php, or in a template file, will crash PHP before it outputs anything.
Via FTP: Navigate to /wp-content/themes/ and rename your current active theme folder (e.g. my-theme → my-theme-backup). WordPress falls back to the most recent default theme it can find (Twenty Twenty-Five, Twenty Twenty-Four, etc.). If the site now loads, your theme’s code is the cause.
Via wp-admin (if accessible): Go to Appearance → Themes and activate a default theme.
Once you’ve confirmed the theme is the problem, open functions.php and check whatever code was added most recently. A missing semicolon, an unclosed bracket, or a function call that doesn’t exist will crash every single page load. This happens a lot after copying in a code snippet from a tutorial without checking it first.
Step 5: Check and Reset Your .htaccess File
A corrupted or malformed .htaccess file can produce a blank response, though it more commonly causes 500 errors instead. Via FTP, rename .htaccess to .htaccess_backup in your WordPress root directory. WordPress will temporarily lose its permalink rules, but if a bad rewrite rule was causing the blank screen, the site will now load.
To regenerate a clean .htaccess once the site is accessible: go to Settings → Permalinks and click Save Changes. WordPress writes a fresh file with correct rewrite rules automatically.
Step 6: Disable the Object Cache
If you’re using a caching plugin (WP Rocket, W3 Total Cache) or Redis object cache, a stale or corrupt cache entry can cause WSOD on specific pages. Temporarily add this to wp-config.php:
define('WP_CACHE', false);Then delete your cache plugin’s cached files, usually from the plugin’s dashboard, or by deleting /wp-content/cache/ via FTP. If the white screen disappears, the cache was serving a broken response.
Step 7: Check Server Error Logs
Your hosting control panel captures PHP errors independently of WordPress. In cPanel, go to Metrics → Errors. On a VPS, check /var/log/apache2/error.log or /var/log/nginx/error.log. Look for any line containing PHP Fatal error; it’ll name the exact file and line number that crashed PHP.
Server error logs are often more complete than wp-content/debug.log because they capture errors that occur before WordPress even starts loading, which WP_DEBUG can’t catch.
Step 8: Fix File Permissions
Incorrect file permissions can prevent PHP from reading or executing WordPress files. The correct permissions are:
- Directories: 755 (
drwxr-xr-x) - Files: 644 (
-rw-r--r--) - wp-config.php: 640 or 600 for extra security
Via FTP (FileZilla), right-click the WordPress root folder and set permissions recursively. Via SSH:
find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;I see this most often after a manual file transfer or server migration, where ownership and permission defaults don’t carry over correctly.
WSOD in Specific Scenarios
White screen in wp-admin only (frontend works)
If the frontend loads normally but wp-admin is blank, the problem is isolated to an admin-only plugin or an admin hook in a plugin or theme. Start by deactivating the most recently updated or installed plugin. If you added code to functions.php recently, a syntax error there would crash the admin without affecting a frontend that’s already cached.
White screen after a WordPress core update
A core update that fails partway through leaves wp-admin and wp-includes in a mixed state, part old version, part new. Download that same WordPress version from wordpress.org, connect via FTP, and upload fresh wp-admin and wp-includes folders. That replaces every core file without touching your content, plugins, themes, or database.
White screen after installing or updating a plugin
If the timing lines up, the white screen showed up right after you installed or updated a specific plugin, that plugin is almost certainly your cause. Rename its folder inside /wp-content/plugins/ over FTP to deactivate it without needing wp-admin access at all. The site should come back immediately.
White screen on one page only
A blank screen on a single post or page, but not sitewide, is almost always a problem with a specific block or shortcode on that page. Edit the page in wp-admin, switch to the Code Editor view, and remove content sections one at a time until the page renders again. Whatever breaks it, usually a page builder widget, an embed, or a complex shortcode, will point you straight to the offending plugin.
How to Prevent WSOD from Happening Again
Most WSOD incidents trace back to one habit: applying updates directly to a live site without testing them first. The WordPress staging guide covers setting up a staging environment, and testing plugin and theme updates there before they touch production is honestly the single most effective thing you can do to prevent this. If a plugin breaks on staging, you fix it there. Your live site never goes down.
Keep current backups before every update. The backup and disaster recovery guide covers setting up automated backups so you always have a restore point if something breaks. For the wider range of WordPress errors beyond WSOD, common WordPress errors is worth a look. Keeping PHP current helps too, since it cuts down on a whole class of memory and execution bugs; the PHP 8.5 upgrade guide walks through the process on Ubuntu servers.
If you’d rather not manage all this yourself, a WordPress maintenance plan covers proactive monitoring, managed updates tested on staging first, and daily backups, so a WSOD gets caught and fixed before any visitor sees a blank screen.
If None of These Fixes Work
If you’ve worked through all eight steps and the white screen persists, the underlying cause is likely environment-specific: a server-level PHP configuration conflict, a compatibility issue between WordPress and your hosting environment’s PHP version, or a corrupted database table. These require hands-on server access and aren’t diagnosable from WordPress’s own tools.
This is exactly the situation the WordPress bug fix and site rescue service is built for: white screen diagnosis and resolution, usually same-day. If your site takes orders, bookings, or leads and you need it back online now, that’s a faster path than working through escalating rounds of server debugging on your own.
