Your WordPress site loads a completely blank white page with no error message. You try refreshing — still nothing. You check your hosting control panel — the server is running. You’ve hit the WordPress White Screen of Death (WSOD).
The good news: WSOD almost always has one of four causes, and each one is fixable without data loss. The steps below are ordered from most likely to least likely cause. Most people resolve this at step 2 or 3.
Before you start: note whether the blank screen affects your site’s frontend, your wp-admin, or both — that distinction narrows the cause significantly and is covered in the scenario section below.
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 newly installed plugin contains a PHP fatal error
- Theme error — a syntax error in
functions.phpor a template file crashes PHP before any output - 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 fixes blindly, turn on WordPress’s error logging so it tells you exactly what went wrong. Add these three lines to wp-config.php — via FTP or your hosting file manager — 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 writes errors to /wp-content/debug.log rather than displaying them on screen — important if your site still has visitors. After adding these lines, reload the page, then open /wp-content/debug.log in your FTP client or file manager.
The error message will name the exact cause: a specific plugin file, your theme’s functions.php, or a WordPress core file. If the log shows Allowed memory size of X bytes exhausted, go straight to Step 2. If it names a 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 to .htaccess in your WordPress root:
php_value memory_limit 256MIf neither works, your hosting plan has a hard memory cap — contact your host and ask them to raise PHP memory to at least 256MB. On shared hosting plans, memory is often the limiting factor for running a complex WordPress site reliably.
Step 3: Deactivate All Plugins
Plugin conflicts are the most common cause of WSOD after an update. Deactivating everything at once immediately tells you whether a plugin is responsible — if the site loads, you reactivate them one at a time to find the culprit.
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. The last one you activate before the white screen returns 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 — if the site now loads, rename the folder back to plugins, then deactivate and re-enable plugins one at a time from wp-admin.
The plugin conflict diagnosis guide covers a binary-search approach to finding the offending plugin faster when you have many installed — halving the active set each time instead of testing one by one.
Step 4: Switch to a Default WordPress Theme
If deactivating plugins didn’t fix it, your active theme is the likely cause — a syntax error in functions.php or a template file that crashes PHP before any output.
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 responsible, open functions.php in a text editor and look for any recently added code — a missing semicolon, an unclosed bracket, or a failed function call produces a fatal error on every page load. This is especially common after manually adding code snippets from tutorials.
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). 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 to wp-config.php:
define('WP_CACHE', false);Then delete your cache plugin’s cached files (usually via 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 lines containing PHP Fatal error — they 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 {} \;Incorrect permissions most often appear after a manual file transfer or server migration where ownership/permission defaults weren’t preserved.
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 the cached frontend.
White screen after a WordPress core update
A core update that failed mid-way leaves wp-admin and wp-includes in a mixed state — some files from the old version, some from the new. Download the same version of WordPress from wordpress.org, connect via FTP, and upload the wp-admin and wp-includes folders — this replaces all core files without touching your content, plugins, themes, or database.
White screen after installing or updating a plugin
If the timing is clear — the white screen appeared immediately after a specific plugin was installed or updated — that plugin is almost certainly the cause. Via FTP, rename that plugin’s folder in /wp-content/plugins/ to deactivate it without needing wp-admin access. The site should load 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. The broken block — often a page builder widget, an embed, or a complex shortcode — will point to the offending plugin.
How to Prevent WSOD from Happening Again
Most WSOD incidents are caused by updates applied directly to a live site without testing first. The WordPress staging guide covers setting up a staging environment — testing plugin and theme updates on staging before applying to production is the single most effective prevention measure. If a plugin breaks on staging, you fix it there; your live site never goes down.
Maintain current backups before every update — the backup and disaster recovery guide covers automated backup setup so you always have a restore point if something breaks. For the broader landscape of WordPress errors and their causes, common WordPress errors covers the full range beyond WSOD. Keeping PHP current also reduces a class of memory and execution bugs — the PHP 8.5 upgrade guide covers the process on Ubuntu servers.
For ongoing protection without managing this yourself, a WordPress maintenance plan includes proactive monitoring, managed updates tested on staging first, and daily backups — so WSOD incidents are caught before your visitors see 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.
The WordPress bug fix and site rescue service covers exactly this situation — white screen diagnosis and resolution, typically same-day. If your site processes orders, bookings, or leads and you need it back online fast, that’s the fastest path to a fix without spending hours on escalating server debugging.
