गाइड · वर्डप्रेस

WordPress White Screen of Death: Causes and Step-by-Step Fixes

Fix the WordPress white screen of death: turn on WP_DEBUG, find the failing plugin or theme, raise the memory limit, and check PHP version problems.

लेखक: SiteDownCheck संपादकीय टीम · अपडेट: अक्टूबर 5, 2026 · 7 मिनट पढ़ने में

The WordPress "white screen of death" (WSOD) is a blank page with no error message. The cause is a fatal PHP error that happens before WordPress can output anything, and the server is configured not to display errors to visitors. It may affect the whole site, only /wp-admin/, or a single page.

Since WordPress 5.2, many fatal errors show a message instead: "There has been a critical error on this website", and an email goes to the admin address with a link to recovery mode. A completely blank page still happens, particularly when the error occurs outside WordPress's own error handler, when output buffering hides it, or with extremely low memory.

This guide shows how to find the actual error and fix the four usual causes: a plugin, a theme, memory exhaustion and a PHP version mismatch.

Step 1: Verify it really is a blank page

Check the response with the HTTP स्टेटस चेकर. A WSOD normally returns 500 with an empty body. A blank page with status 200 is more often a theme or JavaScript problem. A 500 with no content is PHP dying.

curl -sI https://example.com/ | head -n 5
curl -s https://example.com/ | wc -c

A body length of 0 confirms PHP produced no output. If only one URL is blank, the cause is code that runs on that URL, such as a shortcode, a template or one plugin feature.

Step 2: Turn on debugging to see the error

The fastest way to stop guessing is to make WordPress write the error to a log. Edit wp-config.php and add or change these constants above the line /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG_LOG writes to wp-content/debug.log. Load the broken page, then read the log:

tail -n 50 wp-content/debug.log

A typical entry:

PHP Fatal error:  Uncaught Error: Call to undefined function some_function() in /var/www/html/wp-content/plugins/example-plugin/main.php:42

The path tells you the culprit: plugins/example-plugin means a plugin, themes/example-theme means the theme. If the log is empty, also check the server's PHP error log (/var/log/php8.3-fpm.log, /var/log/apache2/error.log or /var/log/nginx/error.log, or the "Errors" section in your hosting panel).

Step 3: Check your email for recovery mode

If the error is a fatal one that WordPress could catch, the site admin email address receives a message titled "Your Site is Experiencing a Technical Issue". It contains a recovery mode link that logs you in to the dashboard with the faulty plugin or theme paused. From there you can deactivate or update it. Check spam folders, and remember that the message goes to the address in Settings, General, not necessarily yours. If emails are not arriving at all, see WordPress email not sending.

Step 4: Plugin causes

Plugins are the most frequent cause, particularly right after an update, an install, or a PHP version change. If you can still reach the admin, deactivate the suspect plugin. If you cannot, disable plugins from the file system.

With WP-CLI:

wp plugin list --status=active
wp plugin deactivate --all
# or only one:
wp plugin deactivate example-plugin

If WP-CLI itself fails because of the fatal error, add --skip-plugins --skip-themes:

wp plugin deactivate example-plugin --skip-plugins --skip-themes

Without WP-CLI: connect over SFTP or the host's file manager and rename wp-content/plugins to plugins.off. WordPress treats every plugin as missing and deactivates them. If the site comes back, rename the folder to plugins again and reactivate plugins one at a time in the dashboard, testing after each. To disable a single plugin, rename just its folder. The plugin conflict troubleshooting guide covers a safe method for finding the culprit on a live site.

Step 5: Theme causes

A theme fatal error is common after editing functions.php, a theme update, or a child theme that depends on a missing parent. If the debug log points to wp-content/themes/..., switch to a default theme:

wp theme list
wp theme activate twentytwentyfour --skip-plugins

Without WP-CLI, rename the active theme's folder in wp-content/themes/. WordPress falls back to a default theme if one is installed, such as a Twenty Twenty-series theme. If none is installed, upload one first.

A frequent self-inflicted cause is a stray character in functions.php: a missing semicolon, an unclosed bracket, or a closing ?> followed by a blank line. Restore the previous version of the file from your backup or version control.

Step 6: Memory exhaustion

PHP kills a script that exceeds memory_limit, and the log says:

PHP Fatal error:  Allowed memory size of 41943040 bytes exhausted (tried to allocate 20480 bytes)

Raise WordPress's limit in wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

WordPress defaults to 40 MB for single sites (64 MB for multisite), and that is often too low for page builders and WooCommerce. The constant only works if the server's own PHP memory_limit is at least that high, since WordPress cannot exceed a hard server cap. See WordPress memory limit exhausted fix for all the layers (php.ini, .user.ini, .htaccess and host panels) and how to find what uses the memory.

Step 7: PHP version mismatch

A change of PHP version is a classic trigger. Hosts upgrade PHP, or you pick a newer version in the control panel, and an old plugin or theme uses removed functions. Typical errors:

PHP Fatal error: Uncaught Error: Call to undefined function create_function()
PHP Parse error: syntax error, unexpected token "{"

Confirm which version is running:

php -v
wp cli info | grep -i php

If the break appeared right after an upgrade, switch back to the previous version in the host panel as a temporary fix, then update or replace the incompatible plugin or theme. Do not stay on an end-of-life PHP version permanently; it no longer receives security fixes. Check php.net's supported versions page for the current status, and review WordPress's own PHP compatibility notes before upgrading.

The reverse can also happen: a plugin updated to require a newer PHP version than your server has. The log will show a parse error on syntax that old PHP does not understand, such as typed properties, match expressions or named arguments. Update PHP, or roll back that plugin.

Step 8: Other causes

  • Corrupted core files after a failed update. Reinstall them without touching content: wp core download --force --skip-content. Check integrity first with wp core verify-checksums.
  • A broken .htaccess typically gives a 500 rather than a white page, but rename it to .htaccess.bak to test, and regenerate it with wp rewrite flush --hard. See also fix 500 internal server error.
  • A failed or interrupted update leaves the site in maintenance mode or half-updated. See stuck in maintenance mode.
  • Database trouble shows a specific message instead (see error establishing a database connection).
  • A security breach. If you find unknown files or edited core files in the stack trace, treat the site as compromised and follow the hacked site recovery guide.
  • Output buffering or an extra byte-order mark (BOM) at the start of a PHP file saved with the wrong encoding. Use "UTF-8 without BOM".
  • A full disk, which stops PHP from writing sessions or cache. Run df -h.

A fast decision path

  1. Check status code and body length from outside.
  2. Enable WP_DEBUG_LOG, reload, read wp-content/debug.log.
  3. File path in the error: plugin or theme. Disable it.
  4. "Allowed memory size": raise limits.
  5. Parse error or undefined function after an upgrade: check PHP version.
  6. No log at all: read the web server and PHP-FPM logs, or ask your host.
  7. Remove debug settings and clear caches when finished.

After you fix it, purge caches (page cache, object cache, CDN), because a cached blank page can outlive the cure.

अगले कदम

सामान्य प्रश्न

Is the white screen of death the same as a 500 error?

Often, yes: PHP crashes and the server returns an HTTP 500 with no body. The difference is only presentation. Debug logging reveals the actual error behind either one.

Why is only my wp-admin blank?

Code that runs only in the dashboard is failing, typically an admin-side plugin feature, a page builder or low memory in the admin, where WordPress raises the limit to WP_MAX_MEMORY_LIMIT (256 MB by default). Debug logging will name the file.

Can I fix it without FTP or SSH?

Often yes. Use the recovery mode link in the critical-error email, or the host's file manager to rename plugin and theme folders. Many hosts also provide a one-click PHP version switch and a built-in error log viewer.

Will WP_DEBUG slow down or break my site?

It adds a small amount of overhead and can reveal deprecation notices that are harmless. Keep display off (WP_DEBUG_DISPLAY false) and switch debugging off again once you have found the problem.

Does the blank page hurt SEO?

A long outage can. Search engines see 500 errors and may slow crawling if they persist. Fix it fast and see website downtime SEO impact.

Get notified when this guide updates

Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.