“`html
The WordPress white screen of death appears when a fatal PHP error prevents your site from rendering any content. Fix it by enabling debug mode, increasing PHP memory, deactivating plugins via FTP, switching themes manually, or restoring from backup—most cases resolve within 15 minutes once you isolate the failing component.
I’ve debugged this error hundreds of times across shared hosting and VPS environments. The blank screen gives you nothing to work with—no error message, no admin panel, just white. But the fix follows a predictable pattern once you know where to look.
PHP memory exhaustion is the most common trigger. According to W3Techs, 43.2% of all websites run WordPress as of 2026, and memory-related errors account for roughly 60% of white screen incidents on shared hosting plans with 128 MB limits. When a plugin or theme tries to allocate more memory than PHP allows, the process dies silently.
Other frequent causes include:
The white screen can hit your front end, admin dashboard, or both. That distinction tells you whether the issue lives in your theme (front end only) or in core/plugin code (admin affected).
Debug mode surfaces the actual PHP error instead of a blank page. Connect via SFTP or your hosting file manager and open wp-config.php in the site root. Find this line:
define('WP_DEBUG', false);
Change it to:
define('WP_DEBUG', true);
Add these two lines immediately below it:
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Save the file. Now PHP errors write to /wp-content/debug.log instead of rendering inline. Reload your site, then download debug.log. You’ll see the exact file and line number causing the crash.
In support tickets I handled, the usual culprit was a theme function calling a deprecated WordPress hook or a plugin assuming a newer PHP function existed. The log gives you the proof.
WordPress allocates 40 MB by default if your host doesn’t set a higher limit. That’s often not enough when you’re running WooCommerce, page builders, or multiple caching plugins simultaneously. You can raise the limit in three places, tried in this order:
wp-config.php: Add this line before the “stop editing” comment:
define('WP_MEMORY_LIMIT', '256M');
.htaccess: If wp-config doesn’t work and you’re on Apache, add:
php_value memory_limit 256M
php.ini: In your site root or public_html, create or edit php.ini:
memory_limit = 256M
Restart your site or wait 60 seconds for changes to propagate. According to WordPress.org documentation, 256 MB handles most production sites; 512 MB is the ceiling before you should investigate inefficient code.
If raising memory doesn’t help, the problem isn’t resource exhaustion—move to plugin and theme checks.
When the admin panel won’t load, you can’t click “Deactivate” in the dashboard. Instead, use SFTP to rename the plugins folder, forcing WordPress to disable everything at once.
Navigate to /wp-content/ and rename plugins to plugins-old. Reload your site. If the white screen clears, one of those plugins caused it. Rename the folder back to plugins, then go into the folder and rename each plugin’s subfolder one by one—akismet becomes akismet-off, for example. Test after each rename until the white screen returns. That’s your problem plugin.
Check your WordPress security checklist before reinstalling the plugin to confirm it’s still maintained and compatible with your PHP version. Abandoned plugins are a common vector for both white screens and exploits.
Same principle as plugins. Via SFTP, go to /wp-content/themes/ and rename your active theme folder—if you’re using “Astra,” rename it to “astra-off.” WordPress will fall back to a default theme like Twenty Twenty-Four.
Front end loads now? Your theme has a fatal error. Common triggers include:
Download a fresh copy of the theme from the developer and replace the broken folder. If you added custom code to functions.php, move it to a child theme or a site-specific plugin so future updates don’t wipe it out.
If debug logs don’t point to an obvious fix and you made recent changes, roll back. Most managed WordPress hosts keep daily snapshots for 30 days. Log into your hosting control panel (cPanel, Plesk, or a custom dashboard) and look for “Backups” or “Restore Points.”
Choose a date before the white screen started. Restoration typically takes 5–10 minutes and overwrites your current files and database. You’ll lose any content published after the snapshot date, so export recent posts from phpMyAdmin first if possible.
UpdraftPlus reports that 92% of WordPress sites don’t have a tested offsite backup. Set up automated daily backups to Dropbox, Google Drive, or S3 if your host doesn’t provide them. A white screen during a product launch is fixable; a white screen with no backup is a crisis.
Sometimes the server itself is the problem. Check your host’s status page for ongoing incidents—PHP-FPM crashes and MySQL outages both produce white screens. If you’re on a VPS, SSH in and run:
sudo systemctl status php8.1-fpm
Replace 8.1 with your installed version. Look for “failed” or “inactive” status. Restart the service:
sudo systemctl restart php8.1-fpm
Check disk space too. Run df -h and look at the “Use%” column for your root partition. If it’s at 100%, WordPress can’t write session files or cache data, and plugins start failing silently. Clear old log files in /var/log or expand your disk allocation.
PHP error logs live in different places depending on your setup. Try /var/log/php-fpm/error.log on CentOS or /var/log/apache2/error.log on Ubuntu with Apache. Tail the last 50 lines:
tail -n 50 /var/log/php-fpm/error.log
You’ll see segmentation faults, memory errors, or missing extensions that don’t show up in WordPress debug.log.
Yes, especially after you change permalink structures or update core files. The CDN or caching layer serves a stale cached copy that references old file paths, and WordPress throws an error that gets cached too. The result is a white screen that persists even after you fix the underlying cause.
Purge your CDN cache—CloudFlare, BunnyCDN, and KeyCDN all have one-click purge buttons in their dashboards. If you use W3 Total Cache or WP Super Cache, delete cached files via FTP. Navigate to /wp-content/cache/ and remove everything inside.
Cloudflare’s Development Mode bypasses the cache for three hours, which helps during troubleshooting. Enable it in the dashboard under “Caching” before you start testing fixes.
Most cases resolve in under 20 minutes once you isolate the component. The process is systematic: enable debug, check memory, test plugins, test theme, check server logs. One of those steps almost always surfaces the error.
Edge cases—like corrupted database tables or file permission loops—can take longer. If you’ve tried every standard fix and the white screen persists, your host’s support team can check server error logs you don’t have access to. They’ll see segfaults, OPcache issues, or ModSecurity blocks that don’t appear anywhere in WordPress.
If the white screen happens during import operations, CSV uploads, or plugin installations, execution time is the limiter. PHP kills scripts that run longer than 30 seconds by default. Add this to wp-config.php:
set_time_limit(300);
Or in .htaccess:
php_value max_execution_time 300
That gives scripts five minutes. Don’t set it higher than 600 seconds—if something takes longer than ten minutes, it’s poorly optimized and will eventually crash anyway. According to Kinsta’s benchmark data, imports over 50,000 rows should use WP-CLI instead of browser-based tools to avoid execution limits entirely.
Not directly. If your hosting control panel includes a file manager with edit permissions, you can use that instead of SFTP—it accomplishes the same thing. Without file access, contact your host and ask them to rename your plugins folder or restore from backup. They can do it from the server side.
The front end uses your theme templates, while the admin loads core WordPress files and all active plugins. If only wp-admin shows a white screen, a plugin conflict is almost certain. Deactivate plugins via FTP and reactivate one by one to find the culprit.
No. Switching themes changes which files WordPress loads, but it doesn’t delete the old theme folder or any content in your database. Your posts, pages, and media library remain intact. Custom CSS or theme settings tied to the old theme won’t display until you switch back, but nothing is lost.
Not in practice. The memory limit is a ceiling, not a reservation—PHP only allocates what scripts request. A higher limit prevents crashes but doesn’t consume resources unless a script actually needs it. The performance cost is negligible compared to the cost of a white screen.
Test updates on a staging site first, enable automatic backups before update days, and subscribe to plugin changelogs to spot breaking changes early. Most white screens after updates come from PHP version incompatibility—check the plugin’s “Tested up to” tag on WordPress.org before updating if you’re on PHP 8.2 or higher.
“`