WordPress White Screen of Death: How to Fix It Fast

You open your WordPress site and see nothing – just a blank white page. No error message, no hint of what went wrong. This is the WordPress White Screen of Death (WSOD), and it is one of the most disorienting problems you can face as a site owner. The good news: it is almost always fixable without professional help if you follow a methodical debugging process.

This guide walks you through every step – from enabling debug logging to isolating plugin conflicts and recovering from PHP fatal errors. By the end, you will know exactly how to diagnose and fix any WSOD, plus how to prevent it from happening again.

---

What Causes the WordPress White Screen of Death?

The WSOD is not a single bug – it is a symptom that can have several root causes. WordPress suppresses PHP fatal errors by default (to avoid showing sensitive paths to visitors), so instead of an error message you get a blank page. Here are the most common triggers:

• PHP fatal errors – A syntax error, an undefined function call, or a class conflict in a plugin or theme causes PHP to halt execution before any output is sent.
• Memory exhaustion – PHP runs out of allocated memory and terminates. WordPress and your plugins each consume memory, and low hosting limits make this common.
• Plugin conflicts – Two or more plugins hook into the same action/filter in incompatible ways, or a plugin depends on a function from another plugin that loaded in the wrong order.
• Theme errors – A broken template file, a missing function call in functions.php, or a poorly written child theme can blank out the entire site or just the front end.
• WordPress core update issues – A failed or partial update can leave core files in an inconsistent state, causing fatal errors on every request.
• Resource exhaustion – Max execution time limits, broken file permissions, or a corrupted .htaccess file can all produce a blank response.

Understanding the cause matters because the fix differs. A memory issue requires a configuration change. A plugin conflict requires isolation and deactivation. A PHP fatal error requires reading the error log and fixing the code (or removing the offending plugin). Let’s go through how to identify which one you are dealing with.

---

Step 1 – Enable WP_DEBUG and WP_DEBUG_LOG

The very first thing to do when you see a white screen is to enable WordPress debug logging. This tells PHP to write all errors to a log file instead of suppressing them. You need FTP/SFTP or SSH access to your server for this step.

Open wp-config.php (in your WordPress root directory) and add the following constants. Place them above the line that reads /* That's all, stop editing! */:

The key settings here:

• WP_DEBUG true – Enables PHP error reporting.
• WP_DEBUG_LOG true – Writes errors to wp-content/debug.log.
• WP_DEBUG_DISPLAY false – Hides errors from front-end visitors. This is critical on live sites.
• SCRIPT_DEBUG true – Forces WordPress to use unminified JS/CSS files, helpful for JS-related blank screens.

After saving wp-config.php, reload your site. Then check the debug log at wp-content/debug.log via FTP or SSH. You should see the fatal error or warning that is causing the blank screen. The error will include the file name and line number, which tells you exactly what code is responsible.

If debug.log does not exist after enabling these settings and reloading the page, check that wp-content/ is writable by your web server user.

For a deeper walkthrough of everything the debug log captures – from PHP warnings to deprecated function calls – check out the full guide on how to enable and use the WordPress debug log. It covers log rotation, log file protection, and how to read and filter different error levels.

---

Step 2 – Check and Increase the Memory Limit

Memory exhaustion is one of the most common WSOD triggers on shared hosting. When PHP runs out of memory, it terminates the request immediately and outputs nothing – exactly what you see with a white screen. If your debug log shows Allowed memory size exhausted or Fatal error: Out of memory, this is your issue.

How WordPress Memory Limits Work

There are two separate memory limits at play:

Setting	Location	Controls	Default
memory_limit	php.ini / .htaccess	PHP’s absolute ceiling	Usually 128M on shared hosts
WP_MEMORY_LIMIT	wp-config.php	WordPress front-end limit	40M (or host’s override)
WP_MAX_MEMORY_LIMIT	wp-config.php	wp-admin limit	256M

WordPress cannot exceed the PHP memory_limit set by your host, so you may need to raise both. Here is how to increase them:

A value of 256M is suitable for most sites. Larger sites running WooCommerce, page builders, or many active plugins may need 512M. After saving, reload the site and check if the WSOD clears.

When Your Host Blocks Memory Changes

Some shared hosts lock the PHP memory limit and ignore overrides in wp-config.php or .htaccess. If increasing the limit has no effect, contact your host and ask them to raise it on the server level. Most managed WordPress hosts (like Kinsta, WP Engine, or Cloudways) allow you to set this in their dashboard or via support ticket.

---

Step 3 – Plugin Conflict Isolation

If increasing memory did not help and your debug log points to a plugin file, or if you cannot identify the error yet, plugin conflict isolation is your next step. The goal is to determine whether a plugin is responsible for the WSOD.

Method 1 – Rename the Plugins Folder (FTP/SFTP)

If you cannot access wp-admin because the WSOD affects the whole site, use FTP or SFTP:

1. Connect to your server via FTP/SFTP.
2. Navigate to wp-content/.
3. Rename the plugins folder to plugins-disabled.
4. Reload your site in a browser.
5. If the WSOD clears, a plugin was responsible. Rename the folder back to plugins.
6. Now move individual plugin folders out one at a time (into a temp location on the server), reloading the site after each, until the WSOD reappears. The last plugin you removed is the culprit.

Method 2 – Binary Search with WP-CLI

If you have WP-CLI access (SSH), the binary search method is faster for sites with many plugins:

The binary search approach halves the problem space with each step. If you have 20 plugins, you can identify the culprit in at most 5 steps instead of testing 20 individually.

Method 3 – Use WordPress Recovery Mode (WP 5.2+)

Since WordPress 5.2, the core includes a built-in fatal error handler. When PHP detects an unrecoverable error, WordPress catches it (using PHP’s register_shutdown_function) and emails the site admin a recovery link instead of showing a blank page to visitors.

Check your admin email for a subject line like “Your Site is Experiencing a Technical Difficulty”. The email contains a link to enter recovery mode, which loads wp-admin with the offending plugin or theme disabled. From there you can deactivate it permanently.

---

Step 4 – WordPress Recovery Mode Deep Dive

WordPress Recovery Mode deserves its own section because it fundamentally changed how WSOD recovery works. Before WP 5.2, a fatal error in a plugin or theme would completely blank out the site and you had no recourse except FTP. Now WordPress handles it more gracefully.

How Recovery Mode Works

1. Fatal error detection – WordPress registers a shutdown function that checks for fatal errors after PHP execution ends.
2. Recovery email – If a fatal error is detected, WordPress sends an email to the admin address with a secure, time-limited recovery URL.
3. Entering recovery mode – Clicking the link sets a cookie. On subsequent page loads, WordPress identifies the file responsible for the fatal error and skips loading that plugin or theme file.
4. Admin access restored – You can log into wp-admin and deactivate the problematic plugin or switch the theme normally.

The recovery mode link expires after 1 hour for security. If you miss it, triggering another fatal error (by reloading the broken page) will trigger a new email. You can also find the recovery key stored as a transient in your database.

What Recovery Mode Cannot Fix

Recovery mode only works for plugin and theme errors that WordPress can catch. It cannot help in these situations:

• The fatal error is in a WordPress core file (rare, but possible after a corrupted update).
• PHP itself cannot start (misconfigured php.ini, missing extensions).
• The error happens before WordPress loads (in wp-config.php or during the bootstrap process).
• The server is returning a 500 Internal Server Error rather than a PHP error.

---

Step 5 – Theme Conflict Isolation

If disabling all plugins did not fix the WSOD, or if your debug log points to a theme file, the active theme is likely responsible. Here are several ways to force-switch to a default theme without wp-admin access.

Method 1 – Force Theme via wp-config.php

After adding the WP_DEFAULT_THEME constant, reload the site. If the WSOD clears, your previous theme was the cause. Remove the constant once you have switched themes permanently via wp-admin.

Method 2 – Update Theme via MySQL

If you have phpMyAdmin or direct database access, run these two queries (replace wp_ with your actual table prefix and the theme slug with any installed default theme):

UPDATE wp_options SET option_value = ‘twentytwentyfour’ WHERE option_name = ‘template’;
UPDATE wp_options SET option_value = ‘twentytwentyfour’ WHERE option_name = ‘stylesheet’;

This directly updates the database records that WordPress reads for the active theme. It takes effect immediately on the next page load.

Child Theme Issues

If you are using a child theme, a common cause of WSOD is a syntax error in the child theme’s functions.php. This file is loaded early in WordPress’s bootstrap process, so even a single missing semicolon will crash the site. Your debug log will point directly to the offending line.

---

Step 6 – Common PHP Fatal Errors Behind WSOD

Once you have the debug log running, you will see one of a handful of recurring fatal error types. Here is what each means and how to fix it:

Allowed Memory Size Exhausted

Error: Fatal error: Allowed memory size of 134217728 bytes exhausted

Fix: Increase WP_MEMORY_LIMIT as described in Step 2. If the error points to a specific plugin, that plugin has a memory leak – check for updates or consider replacing it.

Call to Undefined Function

Error: Fatal error: Uncaught Error: Call to undefined function some_function()

Fix: A plugin or theme is calling a function from another plugin that is not active, or has a typo in the function name. The error log will show the file and line number. Check if the required dependency plugin is active, or if this is a custom code issue, fix the function call.

Cannot Redeclare Function or Class

Error: Fatal error: Cannot redeclare class ClassName

Fix: Two plugins (or a plugin and the theme) are defining the same class or function. This is a plugin conflict. The fix is to identify and remove one of the conflicting plugins, or report the conflict to the plugin developer – the correct fix is to wrap class/function declarations in if ( ! class_exists() ) or if ( ! function_exists() ) checks.

Parse Error: Syntax Error

Error: Parse error: syntax error, unexpected token, expecting ";" in /path/to/file.php on line 42

Fix: There is a syntax error in PHP code – often introduced by manually editing a theme’s functions.php or a plugin file. Go to the exact file and line number in your error log, find and fix the syntax error. Common causes: missing semicolon, unclosed string, mismatched brackets, or pasting code that contains HTML entities (< instead of <).

Maximum Execution Time Exceeded

Error: Fatal error: Maximum execution time of 30 seconds exceeded

Fix: A script is running too long – usually an inefficient database query, an external API call hanging, or a background import process. Increase max_execution_time in php.ini (or via .htaccess with php_value max_execution_time 120), and investigate the slow operation. If a plugin is causing this on every page load, it has a bug.

---

Step 7 – Check the Server Error Log

The WordPress debug log is your first stop, but the server-level error log can catch errors that happen before WordPress even loads. This is essential if the WSOD persists even with no entries in wp-content/debug.log.

Where to Find the Server Error Log

• Apache: /var/log/apache2/error.log or /var/log/httpd/error_log
• Nginx: /var/log/nginx/error.log
• cPanel hosting: cPanel dashboard – Logs – Error Log
• Cloudways: Application – Monitoring – Error Logs
• Kinsta/WP Engine/Flywheel: Site dashboard – Logs section

You can also check logs via SSH with a command like tail -100 /var/log/apache2/error.log. Look for entries timestamped around the time the WSOD started. A 500 Internal Server Error with a file path is a strong clue.

500 vs Blank Page – What is the Difference?

A true blank screen (HTTP 200 with empty body) usually means PHP executed but produced no output – often a buffer issue, an early exit() call, or output buffering problem in a plugin. A 500 Internal Server Error means the web server itself returned an error – often a bad .htaccess rule, a PHP configuration problem, or a missing PHP extension.

Use your browser’s developer tools (Network tab) to check the HTTP status code when you hit the WSOD. This distinction matters for your next debugging step.

---

Step 8 – Debugging the .htaccess File

A corrupted or incorrect .htaccess file is a less common but frustrating WSOD cause. WordPress generates its own .htaccess rules for pretty permalinks, but some plugins add their own rules that can conflict with the server configuration or contain syntax errors.

Testing and Resetting .htaccess

1. Connect via FTP/SFTP to your WordPress root directory.
2. Download a copy of .htaccess as a backup.
3. Rename .htaccess to .htaccess-backup.
4. Reload your site. If the WSOD clears.htaccess was the issue.
5. Create a new .htaccess with only the default WordPress rewrite rules.
6. You can regenerate the correct rules by going to wp-admin – Settings – Permalinks and clicking Save Changes (no changes needed, just save).

The default WordPress .htaccess content for Apache looks like this (do not copy block comment syntax – just the plain directives):

# BEGIN WordPress
RewriteEngine On
RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

---

The WSOD Debugging Checklist

Use this checklist in order every time you hit a white screen. Work through each step and stop when the WSOD clears.

Step	Action	Tool Needed	Clears WSOD If…
1	Enable WP_DEBUG + WP_DEBUG_LOG	FTP + wp-config.php	You can read the exact error
2	Check debug.log for PHP fatal errors	FTP or SSH	Error found and fixed
3	Increase WP_MEMORY_LIMIT to 256M	FTP + wp-config.php	Memory exhaustion was the cause
4	Rename plugins folder or deactivate all	FTP or WP-CLI	A plugin was responsible
5	Force default theme via WP_DEFAULT_THEME	FTP + wp-config.php	Active theme was broken
6	Check server error log	Hosting dashboard or SSH	Server-level 500 error found
7	Rename .htaccess	FTP	Corrupted .htaccess rules
8	Restore WordPress core files	WP-CLI or manual download	Core files were corrupted

---

Step 9 – Restoring WordPress Core Files

If none of the above steps fix the WSOD, WordPress core files may be corrupted. This can happen after a failed update, a server crash during a file write, or (more seriously) a malware injection that modified core files.

Via WP-CLI (Fastest Method)

If you have SSH and WP-CLI available, this is the cleanest approach. The wp core download --skip-content command replaces all core files (wp-admin/, wp-includes/, and root PHP files) without touching your wp-content/ folder or wp-config.php:

wp core download –skip-content –force

The --force flag overwrites existing files. Run this from your WordPress root directory. After completion, reload the site.

Via FTP (Manual Method)

1. Download the same version of WordPress as your current installation from wordpress.org/download/releases/.
2. Extract the ZIP file locally.
3. Delete the wp-content/ folder from the extracted files (you only want to replace core, not your plugins and themes).
4. Upload the remaining files to your server, overwriting existing ones.

Do not replace wp-config.php if you have customizations in it (you almost certainly do).

---

Step 10 – WSOD in wp-admin Only (Front-End Works)

Sometimes only the admin area shows a white screen while the front end loads fine. This is a specific variant of WSOD and usually points to a different set of causes.

Common wp-admin WSOD Causes

• Admin-only plugin error – A plugin that only loads in wp-admin (an admin-panel plugin, a settings page plugin) has a fatal error that only manifests in the dashboard context.
• WordPress auto-update in progress – If an update started but did not complete, the maintenance file (.maintenance in WordPress root) may still exist. Deleting it manually via FTP usually resolves this.
• Corrupted wp-admin directory – Reinstalling core files as described in Step 9 fixes this.
• Browser caching a stale admin page – Try a hard refresh (Ctrl+Shift+R / Cmd+Shift+R) or clear browser cache. This is embarrassingly common.

To isolate admin-only plugins, connect via FTP and rename individual plugin folders inside wp-content/plugins/ that you know are admin-only (settings panel plugins, dashboard widget plugins, etc.).

---

Working with AJAX Errors Alongside WSOD

A less obvious cause of partial white screens – where parts of your page load but others do not, or wp-admin requests hang – is AJAX errors in WordPress. When a wp-admin page relies on admin-ajax.php to load content and that request fails or returns an unexpected response, it can cause certain dashboard panels or front-end dynamic sections to display blank areas.

If your white screen is partial (the page skeleton loads but content areas are blank) rather than a total blank page, checking your browser’s Network tab for failing XHR requests is a good next step. For a full breakdown of how to track down these issues, read our guide on debugging WordPress AJAX and admin-ajax.php errors – it covers how to identify AJAX response codes, trace which action handlers are failing, and fix the most common causes.

---

Prevention Tips and Ongoing Monitoring

The best time to set up WSOD prevention is before it happens. These practices reduce your exposure significantly:

Keep Debug Logging Ready (Without Exposing Errors)

Keep WP_DEBUG_LOG true and WP_DEBUG_DISPLAY false enabled at all times on production – not just when troubleshooting. This way, if a WSOD hits, your log already exists and you do not waste time setting up debugging after the fact. The log file path (wp-content/debug.log) should be protected from public access by adding a block rule in .htaccess:

<Files “debug.log”>
Order allow,deny
Deny from all
</Files>

Test Updates on Staging First

Plugin and theme updates are the number one trigger for unexpected WSOD on otherwise stable sites. A staging environment that mirrors production lets you test updates before pushing them live. Most managed WordPress hosts include staging with one click. If yours does not, use a local development environment to test major updates.

Monitor PHP Error Rates

Tools like Query Monitor (as a plugin, active only on admin) or server-level APM tools (New Relic, Datadog) let you see PHP errors and memory usage in real time. A sudden spike in fatal errors after a plugin update is an early warning before a full WSOD develops.

Set Up Uptime Monitoring

Free tools like UptimeRobot check your site every 5 minutes and send you an email or SMS when it goes down. This means you find out about a WSOD quickly instead of discovering it hours later from a customer complaint.

Maintain Automated Backups

Daily database backups and weekly full-site backups give you a fast recovery path when all else fails. If the WSOD is caused by data corruption or a bad database migration, restoring a recent backup is faster than debugging. Services like UpdraftPlus, BlogVault, or your host’s native backup system all work well.

Minimum Recommended Memory

As a baseline, set your memory limits before you experience a problem:

• Simple blogs / brochure sites: 128M
• Sites with a page builder: 256M
• WooCommerce stores: 256M-512M
• Membership sites with many active plugins: 512M+

---

Quick Reference: WSOD by Symptom

Symptom	Most Likely Cause	First Step
Total blank page, HTTP 200	PHP fatal error or plugin/theme crash	Enable WP_DEBUG_LOG, check debug.log
500 Internal Server Error	Bad .htaccess or PHP config error	Check server error log, rename .htaccess
White screen only in wp-admin	Admin-only plugin.maintenance file	Delete .maintenance file, disable admin plugins
White screen after plugin update	Plugin PHP fatal or conflict	Recovery mode email or rename plugin folder
White screen after theme switch	Theme functions.php syntax error	Force default theme via WP_DEFAULT_THEME constant
White screen after WordPress update	Failed/partial core update	Run wp core download –force via WP-CLI
White screen + “memory exhausted” in log	PHP memory limit too low	Increase WP_MEMORY_LIMIT to 256M+
Partial blank (skeleton loads, content blank)	AJAX failure or JS error	Check browser Network tab for failed XHR requests

---

Conclusion

The WordPress White Screen of Death looks catastrophic but is almost always fixable within minutes once you know where to look. The key is a methodical approach: enable debug logging first, check the error, then address the specific root cause rather than trying random fixes.

To summarize the priority order: enable WP_DEBUG_LOG first – it tells you exactly what is wrong. If the log shows memory exhaustion, raise WP_MEMORY_LIMIT. If it points to a plugin file, use the binary search isolation method. If it points to a theme file, force-switch to a default theme via wp-config.php. WordPress Recovery Mode (available since WP 5.2) is your fastest admin-access path when a plugin or theme causes a fatal error.

Going forward, keep debug logging permanently enabled (with display off), test updates on staging before pushing live, and maintain regular backups. A WSOD that used to mean hours of downtime becomes a 5-minute fix when you already have the logging in place.

---

PHP Fatal Error White Screen of Death WordPress Debugging WordPress Recovery Mode WP_DEBUG

Last modified: April 6, 2026