How to fix the WordPress white screen of death

The WordPress white screen of death (WSOD) is a blank page — no error message, no content, no admin bar. It happens when PHP hits a fatal error before WordPress can produce any output. Since WordPress 5.2, you are more likely to see “There has been a critical error on this website” instead of a blank screen, but the underlying cause is the same: a fatal PHP error.

WP Debug Toolkit (WPDT) is designed for exactly this scenario. Its standalone viewer works independently of WordPress, so you can read error logs, inspect files, and disable plugins even when WordPress is completely down.

If you only remember one thing: enable debug logging, check the log for “Fatal error,” and the file path in the error message tells you which plugin or theme caused it.

Step 1: Check if wp-admin works

Before debugging, determine how much of your site is broken.

Test the frontend

Load your site’s homepage in a browser. If you see a blank white page or the “critical error” message, the frontend is down.

Test wp-admin

Go to https://example.com/wp-admin/. Sometimes only the frontend is broken (a theme issue) while the admin still works. If wp-admin loads, the problem is likely in your theme’s code, not a plugin.

Test with a different browser or incognito window

Rule out caching. A cached version of the site might display fine in your regular browser while the actual site is broken. Open an incognito/private window and load the site.

What you learn from this

Frontend	wp-admin	Likely cause
Broken	Works	Theme issue or frontend-only plugin code
Broken	Broken	Plugin fatal error, PHP issue, or database problem
Works	Broken	Admin-specific plugin code or corrupted admin file
Broken (some pages)	Works	Page-specific template, shortcode, or block issue

Step 2: Enable debug logging

You need to see the actual error message. Without debug logging, PHP fails silently and you get a blank screen with no explanation.

Manual method: edit wp-config.php via FTP

Connect to your server via FTP, SFTP, or your hosting panel’s file manager.
Open wp-config.php in the WordPress root directory.
Add these lines above the /* That's all, stop editing! */ comment:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Save and upload the file.
Reload the broken page in your browser. This generates the error and writes it to the log.

If these constants already exist in the file, change their values. Do not add duplicates.

Note: Keep WP_DEBUG_DISPLAY set to false. Setting it to true during a WSOD might show the error directly in the browser, which helps with debugging but exposes server details to visitors if the site is public.

WPDT method: use the standalone viewer

If WPDT’s standalone viewer is installed, you can enable debug logging without touching wp-config.php:

Open the viewer URL (e.g., https://example.com/wpdebugtoolkit/).
Log in with your viewer password.
Press K to open Settings.
Toggle error logging on.

The viewer writes the debug constants to wp-config.php through its own API. It does not need WordPress to be running.

No FTP access and no viewer installed

If you cannot access the server files and do not have the standalone viewer:

Check your hosting control panel. Most hosts (cPanel, Plesk, Cloudways, etc.) have a file manager built in.
Contact your host’s support and ask them to enable WP_DEBUG and WP_DEBUG_LOG for you.
Some managed hosts (Kinsta, WP Engine, Flywheel) have their own error log viewer in their dashboard — check there before editing any files.

Step 3: Read the error log

Once debug logging is enabled and you have reloaded the broken page, the error is written to the log.

Manual method: download debug.log via FTP

Connect to your server via FTP.
Navigate to wp-content/.
Download debug.log.
Open it in a text editor.
Scroll to the bottom — the most recent errors are at the end.

A fatal error entry looks like this:

[15-Mar-2026 14:22:05 UTC] PHP Fatal error: Uncaught Error: Call to undefined function
wc_get_product() in /var/www/html/wp-content/plugins/my-product-sync/includes/class-sync.php on line 127

Or a memory exhaustion error:

[15-Mar-2026 14:22:05 UTC] PHP Fatal error: Allowed memory size of 67108864 bytes exhausted
(tried to allocate 4096 bytes) in /var/www/html/wp-content/plugins/page-builder-pro/includes/class-renderer.php on line 453

Or a parse error:

[15-Mar-2026 14:22:05 UTC] PHP Parse error: syntax error, unexpected '}' in
/var/www/html/wp-content/themes/flavor/functions.php on line 89

WPDT method: open the standalone viewer

Visit the viewer URL.
The Error Logs view loads immediately, showing parsed, formatted log entries.
The most recent error appears at the top (if sorted by newest).
Fatal errors are highlighted by severity level.
Hover over an entry and press Q to open the File Viewer — this shows the source code around the error line so you can see the context.

The viewer does not require WordPress to be running. It reads the log file directly from the filesystem.

Step 4: Identify the cause from the file path

The file path in the error message tells you what generated the fatal error.

Plugin errors

If the path contains /wp-content/plugins/plugin-name/:

/wp-content/plugins/my-product-sync/includes/class-sync.php on line 127

The plugin my-product-sync caused the crash. The file class-sync.php at line 127 is where the error occurred.

Theme errors

If the path contains /wp-content/themes/theme-name/:

/wp-content/themes/flavor/functions.php on line 89

Your active theme caused the crash. The functions.php file is the most common culprit — it runs on every page load.

WordPress core errors

If the path contains /wp-includes/ or /wp-admin/includes/:

/wp-includes/class-wpdb.php on line 2056

This indicates a problem in WordPress core itself. Core fatal errors are rare and usually caused by corrupted files, a failed update, or a server configuration problem (not a bug in WordPress). Re-downloading WordPress core files often fixes it.

Must-use plugin errors

If the path contains /wp-content/mu-plugins/:

/wp-content/mu-plugins/custom-functions.php on line 15

Must-use plugins cannot be deactivated through the admin. You need to remove or rename the file via FTP.

Step 5: Disable the offending code

Once you know which plugin or theme caused the crash, disable it to restore access to your site.

Method 1: Rename the plugin or theme folder via FTP

Connect to your server via FTP.
Navigate to wp-content/plugins/.
Rename the offending plugin’s folder. For example, rename my-product-sync to my-product-sync-disabled.
Reload your site. WordPress detects the missing folder and deactivates the plugin.

For a theme crash, rename the theme folder in wp-content/themes/. WordPress falls back to the latest default theme (Twenty Twenty-Five, Twenty Twenty-Four, etc.). If no default theme is installed, you need to upload one via FTP.

Method 2: WordPress recovery mode

Since WordPress 5.2, fatal errors trigger recovery mode. WordPress sends an email to the admin email address with a special login link. This link gives you access to wp-admin with the offending plugin or theme automatically paused.

Check your email (including spam folders) for a message from WordPress about a technical issue on your site. The subject line includes your site name and a description of the problem. Click the recovery link in the email to log in and deactivate the problem plugin from the Plugins page.

Recovery mode links expire after 24 hours.

Method 3: WPDT Crash Recovery

If the standalone viewer is installed:

Visit the viewer URL.
Press P to open Crash Recovery.
You see a list of installed plugins and themes with enable/disable controls.
Disable the offending plugin.
Reload your site to confirm it is back.
Check the error log for the specific error to understand the root cause.
Re-enable other plugins one by one if needed.

Crash Recovery works by renaming plugin/theme directories on the filesystem — the same mechanism as the FTP method, but from a browser interface that works during crashes.

Method 4: WP-CLI (if you have SSH access)

wp plugin deactivate my-product-sync

Or deactivate all plugins at once:

wp plugin deactivate --all

Switch to a default theme:

wp theme activate twentytwentyfive

Step 6: Fix the root cause

Disabling the plugin or theme restores access, but you need to address the underlying problem.

Update the plugin or theme

The most common fix. Check if an update is available that resolves the issue. Update from wp-admin once you have access back.

Check PHP version compatibility

Some plugins require a minimum PHP version. A plugin written for PHP 8.0 may crash on PHP 7.4 with a fatal error about syntax or undefined functions. Check the plugin’s requirements, and update your PHP version if needed (contact your host or update through your hosting panel).

Contact the developer

If the plugin is actively maintained, report the issue. Include:

The exact error message and file/line from your log (you can copy that exact line in WPDT by pressing X over it).
Your WordPress version.
Your PHP version.
The plugin version.
Whether the error happens immediately on activation or after a specific action.

Replace the plugin

If the plugin is abandoned (no updates in over a year) and you cannot fix the code yourself, find an alternative plugin that provides the same functionality.

Fix custom code

If the crash is in your own theme or custom plugin, fix the code at the file and line number indicated in the error. Common mistakes:

Calling a function that does not exist (typo or missing dependency).
Using PHP syntax not supported by the server’s PHP version.
Exceeding the memory limit in a loop.

Common causes of the white screen

Memory exhaustion

Fatal error: Allowed memory size of 67108864 bytes exhausted

PHP ran out of memory. The number (67108864 = 64 MB) tells you the limit. Increase it in wp-config.php:

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

This sets the WordPress memory limit. If the server’s PHP memory_limit in php.ini is lower, the server limit wins. Contact your host to increase the PHP limit if needed.

The memory error message also shows the file and line where memory ran out. That code might be loading too much data — processing a large import, rendering a complex page builder layout, or running a query that returns thousands of results.

Plugin conflicts

Two plugins that interfere with each other can cause fatal errors. Symptoms: the site crashes only when both plugins are active. See How to Debug WordPress Plugin Conflicts for a detailed walkthrough.

PHP version incompatibility

Updating PHP (e.g., from 7.4 to 8.2) can break plugins that use deprecated or removed functions. Downgrading PHP (e.g., from 8.2 to 7.4) breaks plugins that use newer syntax like named arguments, enums, or union types.

Check the error message for clues:

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

create_function() was removed in PHP 8.0. The plugin needs an update.

Parse error: syntax error, unexpected token "enum"

The plugin uses PHP 8.1+ syntax but your server runs PHP 7.4 or 8.0.

Syntax errors in functions.php

Editing functions.php through WordPress’s built-in theme editor is dangerous. A missing semicolon, unmatched brace, or typo causes a parse error that crashes the entire site.

Parse error: syntax error, unexpected '}' in /wp-content/themes/flavor/functions.php on line 89

Fix: edit the file via FTP and correct the syntax error. If you cannot find it, restore from a backup.

Since WordPress 4.9, the theme editor has syntax checking that prevents saving broken code, but this protection does not cover edits made via FTP or external editors.

Corrupt .htaccess

A malformed .htaccess file can cause 500 errors (which look like a white screen from the browser). This is technically a web server error, not a PHP error, so debug.log is empty.

Fix: rename .htaccess to .htaccess-backup via FTP, then visit your site. If it loads, go to Settings → Permalinks in wp-admin and click “Save Changes” to regenerate a clean .htaccess.

Database connection errors

Error establishing a database connection

This is not a white screen technically, but it produces a mostly blank page. Check wp-config.php for correct database credentials (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). If the credentials are correct, your database server may be down — contact your host.

Failed WordPress core update

If a WordPress core update was interrupted (server timeout, connection drop), some files may be missing or corrupt. The fix:

Download a fresh copy of WordPress from wordpress.org.
Upload the wp-admin/ and wp-includes/ directories via FTP, overwriting the existing files.
Do not overwrite wp-content/ — that contains your plugins, themes, and uploads.

Prevention

Use a staging environment

Test plugin updates, theme changes, and PHP version upgrades on a staging copy before applying them to production. Most managed hosts offer one-click staging.

Maintain backups

Keep automated daily backups with at least 7 days of retention. Your host may handle this, or use a backup plugin. When a WSOD strikes, restoring from the previous day’s backup is often the fastest fix.

Enable error email notifications

WPDT’s Site Monitor sends you an email when a fatal error occurs. You find out about problems before your clients do. See Setting Up Notifications.

Keep plugins updated

Outdated plugins are the most common cause of fatal errors after a WordPress core or PHP update. Update plugins regularly and remove plugins you no longer use.

Troubleshooting

All plugins disabled but still white screen

If you deactivated every plugin (via FTP rename of the entire plugins directory) and still see a white screen:

Switch to a default theme. Rename your active theme’s folder in wp-content/themes/. WordPress falls back to a default theme.
Check mu-plugins. Must-use plugins in wp-content/mu-plugins/ are always active. Rename or remove files there.
Check for a broken db.php. A corrupted drop-in at wp-content/db.php can crash WordPress before any plugin loads. Rename it to db.php.bak.
Check .htaccess. Rename it and test.
Check wp-config.php syntax. A stray character or unclosed string in wp-config.php itself causes a parse error before WordPress loads anything.
Re-download WordPress core files. Upload fresh wp-admin/ and wp-includes/ directories.

Error log is empty

The log file is empty after reloading the broken page. Possible reasons:

Debug logging is not enabled. Verify that wp-config.php contains define('WP_DEBUG', true) and define('WP_DEBUG_LOG', true) and that they are above the “stop editing” comment.
The directory is not writable. PHP cannot create or write to debug.log if the wp-content/ directory does not have write permissions for the web server user.
The error happens before WordPress loads. A syntax error in wp-config.php itself, or a server configuration problem (wrong PHP version, missing PHP modules), causes PHP to fail before WordPress’s error handling initializes. In this case, check the server’s PHP error log instead — usually at /var/log/php-fpm/error.log, /var/log/apache2/error.log, or accessible through your hosting panel under “Error Logs.”
PHP’s own error logging is disabled. Some hosts suppress PHP error output entirely. Check your PHP configuration or contact your host.
The error is not a PHP error. A 500 status from a corrupt .htaccess or web server misconfiguration does not produce a PHP error log entry.

“There has been a critical error on this website”

This is WordPress 5.2+ recovery mode, not a traditional WSOD. WordPress caught the fatal error and is showing a user-friendly message instead of a blank screen.

Click “Learn more about troubleshooting WordPress” on the error page for WordPress’s own recovery suggestions. Then check your email for the recovery mode link.

If you do not receive the recovery email:

Check spam folders.
Verify the admin email address is correct in the database. You can check with WP-CLI: wp option get admin_email.
Some hosts block outgoing email from PHP. Check your host’s email configuration or use an SMTP plugin (which you may need to install via FTP since wp-admin is down).

Cannot access FTP

If you cannot get to the server’s files at all:

Hosting panel file manager. cPanel, Plesk, Cloudways, Runcloud, and most hosting panels include a browser-based file manager.
SSH/terminal access. Some hosts provide SSH access even when FTP is not configured.
Contact hosting support. They can access the files and make changes on your behalf. Tell them: “I need to rename a plugin folder in wp-content/plugins/ to diagnose a white screen.”
WPDT standalone viewer. If it was installed before the crash, you do not need FTP. Open the viewer URL directly.

Advanced topics

WP_DISABLE_FATAL_ERROR_HANDLER

define('WP_DISABLE_FATAL_ERROR_HANDLER', true);

This disables WordPress 5.2’s built-in fatal error handler. Instead of the “critical error” message, you get a blank white screen (or PHP’s default error output if display_errors is on).

When this is useful: the recovery mode handler sometimes interferes with debugging because it catches the error before you can see it with WP_DEBUG_DISPLAY. Disabling the handler lets PHP display the raw error. Only use this temporarily on non-production sites.

Increasing PHP memory limit

WordPress’s WP_MEMORY_LIMIT is a soft limit that only applies to WordPress operations. The actual ceiling is PHP’s memory_limit directive in php.ini.

To find the current PHP memory limit and increase it, you can use WP Debug Toolkit (see PHP and server settings):

echo ini_get('memory_limit');

To increase it (if your host allows it), add to .htaccess:

php_value memory_limit 256M

Or create/edit a php.ini file in your WordPress root:

memory_limit = 256M

Or add to wp-config.php (works for WordPress operations only):

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

WP_MAX_MEMORY_LIMIT controls the memory limit for admin operations, which typically need more memory.

PHP error log vs WordPress debug.log

These are different files that log different things.

WordPress debug.log (wp-content/debug.log): Errors routed through WordPress’s error handling. Created when WP_DEBUG_LOG is true. Only captures errors that happen after WordPress has started loading.

PHP error log (e.g., /var/log/php-fpm/error.log): All PHP errors on the server, including errors that happen before WordPress loads — like syntax errors in wp-config.php or missing PHP extensions. Controlled by the error_log directive in php.ini.

If debug.log is empty during a WSOD, check the PHP error log. It may contain the fatal error that WordPress could not catch.

Checking for corrupt core files

WordPress core files can become corrupted during failed updates or server issues. To verify and repair:

wp core verify-checksums

This compares your core files against the official WordPress checksums. If files are modified or missing, re-download them:

wp core download --force

This overwrites wp-admin/ and wp-includes/ with fresh copies but does not touch wp-content/.

Summary

Method	Requires server access?	Works during WSOD?	Can disable plugins?	Shows error details?
WPDT standalone viewer	No (browser only)	Yes	Yes (Crash Recovery)	Yes (error log + file viewer)
WordPress recovery mode	No (email link)	Yes	Yes (wp-admin)	Partial (recovery email)
FTP/SFTP file edit	Yes	Yes	Yes (rename folders)	Yes (download debug.log)
Hosting panel	Yes (panel login)	Yes	Yes (file manager)	Depends on host
WP-CLI over SSH	Yes (SSH access)	Yes	Yes (`wp plugin deactivate`)	Yes (`debug.log`)
Contact host support	No	Yes	Yes (they do it)	Depends on host