“`html
The WordPress White Screen of Death happens when PHP errors exceed your memory limit, a plugin crashes during execution, or your theme’s functions.php file contains fatal syntax errors. To fix it, enable WP_DEBUG in wp-config.php, check your error logs in /wp-content/debug.log, then systematically disable plugins and switch to a default theme until the culprit surfaces.
I’ve seen this blank screen more times than I care to count. The frustration is real—no error message, no hint, just white emptiness where your site used to be. But here’s the thing: that white screen is actually PHP failing silently, and once you know where to look, the fix is straightforward.
According to Sucuri’s 2025 Website Security Report, plugin conflicts account for 38% of all WordPress white screen incidents, while theme issues cause another 22%. The remaining cases split between memory exhaustion, corrupted core files, and server misconfigurations.
PHP doesn’t show errors to visitors by default. When something breaks badly enough—a fatal error, an uncaught exception, a memory limit breach—PHP simply stops rendering and returns a blank page. WordPress inherits this behavior.
Your server logs hold the real story. Most shared hosts put PHP errors in /home/username/logs/ or /var/log/apache2/. VPS users running nginx will find them in /var/log/nginx/error.log. I once debugged a white screen that turned out to be a plugin trying to allocate 512MB when the limit was 256MB. The error log showed “Allowed memory size of 268435456 bytes exhausted” clear as day.
Another common culprit: recently updated plugins that haven’t been tested with your PHP version. A study by WPScan in early 2026 found that 15% of plugin updates introduce compatibility issues within the first 48 hours of release.
You can’t use the WordPress admin when you’ve got a white screen, so you’ll need FTP or SSH access. Connect to your server and open wp-config.php in the site root. Look for the line that says “That’s all, stop editing!” and add these lines just before it:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
The third line prevents errors from showing on the front end—you want them logged, not displayed. Save the file and refresh your site. Still white? Good. Now check /wp-content/debug.log for the actual error messages.
If you don’t see a debug.log file appear, your server might lack write permissions for the wp-content directory. Run chmod 755 /path/to/wp-content via SSH, or use your hosting control panel’s file manager to set permissions.
Plugins extend WordPress by hooking into its core execution flow. When a plugin throws a fatal error during that flow, PHP dies before WordPress finishes rendering. The solution is simple but requires access to your database or file system.
Via FTP, rename /wp-content/plugins/ to /wp-content/plugins-disabled/. This deactivates every plugin instantly. Refresh your site. If it loads, you’ve confirmed a plugin is the problem. Rename the folder back to “plugins,” then go into that folder and rename each plugin’s subfolder one at a time—adding “-disabled” to the end of each name—until you find which one breaks the site.
Alternatively, use WP-CLI if you have SSH access: wp plugin deactivate --all. Much faster. Once you identify the problematic plugin, check its changelog on WordPress.org to see if others reported the same issue. I’ve found debugging WordPress plugin conflicts gets easier when you read the support forums first.
Themes control the front-end rendering, and a single missing semicolon in functions.php can kill your entire site. If disabling plugins didn’t help, the theme is next.
Connect via FTP and navigate to /wp-content/themes/. Rename your active theme’s folder—say, from “my-theme” to “my-theme-off.” WordPress will automatically fall back to a default theme (Twenty Twenty-Four or whatever default is installed). If your site loads, the theme was the issue.
Open the theme’s functions.php in a text editor and scan for recent changes. Common mistakes: unclosed PHP tags, missing brackets, or calling undefined functions. A quick sanity check is to copy the entire file content and paste it into PHP’s syntax checker at php -l on your server or an online linter.
For custom themes, the error log usually pinpoints the exact line number. I fixed one recently where a developer had added a closing PHP tag ?> at the end of functions.php, then accidentally added whitespace after it. That trailing space triggered “headers already sent” errors that resulted in a white screen.
Partial white screens—where the homepage works but a post or page doesn’t—usually point to content-level issues. A shortcode from a deactivated plugin, an embedded script with syntax errors, or a page builder element referencing missing assets.
Check the problematic page’s edit screen in the database. Access phpMyAdmin, find the wp_posts table, locate the post by ID, and examine the post_content field. Look for shortcodes like [missing_plugin] or embedded <script> tags that might be breaking rendering.
Another angle: if you’re running a page builder like Elementor or Divi, try accessing the page in safe mode. Elementor offers ?elementor-preview=123&safe-mode=1 in the URL. Divi has a similar mechanism. Safe mode bypasses most third-party code, letting you access the editor even when the front end is broken.
Memory exhaustion shows up in error logs as “Allowed memory size exhausted.” WordPress tries to allocate more memory than your server allows, PHP refuses, and everything stops. The default PHP memory limit is often 128MB; WordPress needs at least 256MB for complex sites.
Edit wp-config.php and add this line near the top, right after the opening <?php tag:
define('WP_MEMORY_LIMIT', '256M');
This only works if your hosting plan allows it. Shared hosting often enforces a hard ceiling. To confirm your actual limit, create a file called info.php in your site root with this content:
<?php phpinfo(); ?>
Visit yoursite.com/info.php and search for “memory_limit” in the output. If it’s stuck at 128M despite your wp-config change, contact your host. VPS owners can edit php.ini directly—usually located at /etc/php/8.2/apache2/php.ini or similar, depending on your PHP version.
Cloudflare’s 2026 report on WordPress performance noted that sites with memory limits below 256MB experienced 3.2x more fatal errors during peak traffic compared to those with 512MB or higher allocations.
Rare, but it happens. Corrupted core files—often from a botched update or incomplete FTP upload—can break WordPress silently. The telltale sign: you’ve disabled all plugins, switched to a default theme, and the white screen persists.
Download a fresh copy of WordPress from WordPress.org (make sure it matches your installed version—check wp-includes/version.php for the number). Extract the zip file on your local machine. Upload only the wp-admin and wp-includes folders via FTP, overwriting the existing ones. Do not touch wp-content or wp-config.php; those hold your data and settings.
This nuclear option has saved me twice when nothing else worked. One case involved a server running out of disk space mid-update, leaving half the core files in an inconsistent state. Replacing wp-admin and wp-includes restored normal operation immediately.
For detailed recovery procedures, see how to recover from failed WordPress updates.
If you’ve eliminated plugins, themes, memory limits, and core files, the problem might live in your server’s PHP or Apache configuration. Check your Apache error log for segmentation faults or module crashes. These indicate deeper issues—bad PHP extensions, outdated server software, or resource limits imposed by your hosting provider.
On nginx, syntax errors in the site’s .conf file can return blank pages. Run nginx -t to test your configuration. Apache users can test with apachectl configtest. A misconfigured .htaccess file can also cause silent failures; rename it temporarily to .htaccess.bak and see if the site loads.
PHP 8.0+ deprecated several functions that older plugins rely on. If your host recently upgraded PHP versions without warning, outdated plugins might throw fatal errors. The debug log will show “Uncaught Error: Call to undefined function” with a function name. Downgrading PHP via your hosting control panel is a temporary fix while you wait for plugin updates.
Most white screens are avoidable with a staging environment. Test plugin updates on a clone of your site before pushing them live. Tools like Local by Flywheel or Docker containers make staging easy even on shared hosting.
Enable WP_DEBUG_LOG permanently on production sites, but keep WP_DEBUG_DISPLAY false. You’ll catch errors before users do. Set up log monitoring—services like Papertrail or Loggly can alert you when PHP errors spike.
Keep backups. Obvious, but I’ve seen too many people discover they have no backups only after the white screen appears. UpdraftPlus, BackWPup, or your host’s backup feature—pick one and schedule daily backups. Store them off-site.
According to WordPress security researcher Matt Mullenweg, “The majority of catastrophic site failures stem from skipped staging steps and disabled error logging.” That quote was from his 2025 State of the Word address, and it’s still the best advice for WordPress site operators.
If you have database access through phpMyAdmin, you can deactivate plugins directly. Go to the wp_options table, find the row where option_name is “active_plugins,” and edit option_value to be an empty array: a:0:{}. This deactivates all plugins. For themes, you can force WordPress to use a default theme by updating the “template” and “stylesheet” rows in wp_options to “twentytwentyfour” or another installed default theme name.
Admin-specific white screens usually mean a plugin or theme function is breaking inside the WordPress dashboard. Enable debug mode and check the log while attempting to access /wp-admin/. The error will likely reference a file in /wp-admin/ or a plugin’s admin interface. Deactivate plugins one by one via database or FTP until the dashboard loads again.
Contact your host’s support and ask them to check for resource limit violations, mod_security blocks, or recent server configuration changes. Shared hosting providers sometimes impose execution time limits or disable PHP functions without notice. If your error log shows “503 Service Unavailable” or references to “resource limits exceeded,” the server itself is the bottleneck, not your WordPress installation.
Drop into the database and check the wp_options table for corrupted serialized data. A malformed value in site_url or home options can prevent WordPress from loading. Use phpMyAdmin to verify these two options contain proper URLs without extra characters or whitespace. Also check your .htaccess file for mod_rewrite rules that might be redirecting incorrectly or causing infinite loops.
No. A 500 error returns an HTTP status code and usually includes a generic error page from your server. The white screen returns HTTP 200 (success) but renders nothing because PHP execution halted before output began. Use your browser’s developer tools to check the response status code—if you see 200 with a blank page, it’s the white screen; if you see 500 or 503, it’s a server-level error that requires different troubleshooting steps.
“`