The WordPress white screen of death (WSOD) is a blank page with no error message, typically caused by memory limits, plugin conflicts, or fatal PHP errors. Fix it by enabling debug mode, increasing PHP memory, disabling plugins, or switching to a default theme. Most cases resolve within minutes once you identify the root cause.
When your WordPress site displays a white screen with no content or error message, your visitors see nothing—and you lose traffic, conversions, and trust. According to a 2025 Kinsta hosting report, 23% of WordPress site owners experienced critical downtime in the past year, with WSOD being among the top three causes. This issue affects small blogs and enterprise sites equally, making diagnostic speed essential. Understanding how to fix WordPress white screen of death quickly can mean the difference between a 5-minute fix and hours of lost visibility.
The WSOD typically stems from three categories: memory exhaustion, PHP errors, and theme or plugin conflicts. WordPress has a default memory limit of 40MB, which is often insufficient for modern plugins and large databases. When PHP attempts an operation exceeding this limit, WordPress terminates silently without displaying an error message.
Plugin conflicts are the second major cause. When two plugins use incompatible code or fight for the same hooks, WordPress can fail to load. Similarly, a corrupted or incompatible theme can prevent the site from rendering. Finally, fatal PHP errors—such as syntax mistakes or undefined functions—can trigger WSOD if error reporting is disabled, which is the default on production sites.
Debug mode reveals the hidden errors causing the white screen. Access your site via FTP or file manager and locate wp-config.php in your root directory. Add these lines just before the line that says /* That's all, stop editing! */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );This configuration writes errors to /wp-content/debug.log instead of displaying them on your site. After adding these lines, refresh your website and check the debug log. The error message will point you directly to the problematic plugin, theme, or code.
Many WSOD cases resolve by raising the memory limit. Open wp-config.php again and add this line before the debug statements:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );The first line sets memory for regular operations; the second sets the ceiling for admin operations. If you lack FTP access, ask your hosting provider to increase PHP memory in your control panel (cPanel, Plesk, etc.). Most hosts set this in seconds. Refresh your site and test—if the WSOD disappears, memory was your culprit. If it persists, move to the next diagnostic step.
Since plugins are the most common WSOD cause, disable them first. If you can’t access the WordPress admin panel, use FTP or file manager to navigate to /wp-content/ and rename the plugins folder to plugins-old. WordPress will automatically deactivate all plugins. If your site returns to normal, rename the folder back and re-enable plugins one by one to find the culprit. When you identify the problematic plugin, delete it, update it, or replace it with an alternative.
If plugins aren’t the issue, switch to a default WordPress theme such as Twenty Twenty-Four. Via FTP, navigate to /wp-content/themes/ and rename your active theme folder. WordPress reverts to its default theme. If the WSOD disappears, your theme is corrupted or incompatible. Contact the theme developer for a fix or choose a new theme.
According to Cloudflare’s 2025 web hosting reliability data, shared hosting accounts experience WSOD 40% more frequently than managed WordPress hosts due to stricter server resource limits. On shared hosting, even a single resource-heavy plugin can exhaust allocated memory. VPS and cloud hosting (AWS, DigitalOcean, Linode) users typically see WSOD from plugin conflicts rather than resource limits, since they control their PHP configuration directly.
On Docker-based deployments, WSOD often signals incorrect volume permissions or missing environment variables. Ensure your Docker container has the correct PHP memory limit set in docker-compose.yml and that uploaded files have read/write permissions. For WP Engine, Kinsta, or other managed platforms, WSOD usually indicates a theme or plugin incompatibility—these hosts rarely face memory issues since they scale automatically.
wp-config.php and check /wp-content/debug.log for error messages.WP_MEMORY_LIMIT to 256M and test./wp-content/plugins to /wp-content/plugins-old and refresh.No. WSOD is a display issue, not data loss. Your database, files, and content remain intact. Once you fix the underlying cause, your site recovers fully with no data impact.
Limited options exist without file access. Contact your hosting provider and ask them to enable debug mode, increase PHP memory, or disable all plugins from the server side. Some hosts offer plugin management dashboards that allow remote toggling without FTP.
Disable all plugins first. If the site recovers, the issue is plugin-related. Re-enable plugins one at a time to isolate the culprit. If WSOD persists with all plugins disabled, switch to a default theme. This binary approach eliminates guesswork.
Possibly. If your PHP version is older than 7.4, upgrading to 8.1 or 8.2 often resolves compatibility issues. However, test on staging first—older plugins may break on newer PHP versions. Your host can usually handle the upgrade safely.
Rarely, but yes. If debug logs show suspicious code or unfamiliar function calls, malware may be involved. Run a security scan with Wordfence or Sucuri, and consider a professional audit. Most WSOD cases are benign configuration or compatibility issues, not security breaches.