WordPress White Screen of Death: Fix It With the Log

On this page, 10 sections

The WordPress white screen of death is most often a PHP error that stopped the page, with the error message hidden. A timeout or a page that prints nothing can look the same, and the log helps rule those in or out.

Turn on the debug log in wp-config.php, reload the page once, and read the last line that contains “Fatal error” in wp-content/debug.log. Each line starts with a timestamp. That line names the file and line number of the fault, and the file’s folder tells you which plugin or theme to disable.

Guessing instead, such as disabling every plugin, can work, but it tells you nothing about the cause. The log names the file.

What a white screen is

WordPress’s debugging documentation says the PHP default is to show only fatal errors, and that with errors off, hitting one gives you a white screen. I read the page on 11 October 2026.

The relevant passage is in its section on WP_DEBUG: turning the debug constant on changes that default, so errors are displayed. On most production hosts display is off, because showing errors to visitors leaks paths and code details.

So the white screen is not a type of error. It is the symptom of a fatal error you cannot see. The job is to make the error visible to you without showing it to everyone.

Step 1: Switch on the log without showing errors

Edit wp-config.php, above the line that says “That’s all, stop editing”, and add three lines from the documentation’s example for logging while hiding errors:

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

The documentation describes WP_DEBUG_LOG as saving all errors to debug.log in the content directory, usually wp-content/debug.log. You can also give it a file path to save the log somewhere else. WP_DEBUG_DISPLAY set to false keeps the errors off the page.

The same page warns that these tools are meant for local and staging installs, and that using WP_DEBUG on a live site is not recommended. For a short diagnosis on a site that is already down, the trade is reasonable. Turn it off again after, and delete the log, because it can contain file paths.

Step 2: Trigger the error once and read the log

Load the broken page one time. Then open wp-content/debug.log over SFTP, your host’s file manager or SSH.

tail -n 30 wp-content/debug.log

Look for a line like this, with your own paths. The example is made up to show the shape:

[11-Oct-2026 10:00:00 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function something() in /var/www/example.com/wp-content/plugins/some-plugin/file.php:42

The exact words differ. Read three things:

The type: “Uncaught Error”, “Allowed memory size exhausted”, “Class not found”, “Parse error”.
The path, which includes plugins/ or themes/ followed by a folder name. That folder is the culprit, or the first place to look. A plugin can also fail because of code in another plugin, so if disabling the named one changes the error instead of fixing it, read the new line.
The line number, if you plan to read the code.

Step 3: Disable what the log names

You cannot use the dashboard when the site is down, so do it from the file system.

Connect over SFTP or SSH.
Go to wp-content/plugins/.
Rename the folder the log named, for example some-plugin to some-plugin-off.
Reload the site.

As I understand WordPress, it deactivates a plugin whose folder is missing, but I did not test that for this post. Must-use plugins and drop-ins in wp-content are not removed this way. If the log named a theme, rename that folder under wp-content/themes/ and load the site again.

If you can run WP-CLI over SSH, the command wp plugin deactivate takes a plugin name. I read the maintenance-mode page of the WP-CLI documentation for this article and did not test the plugin command on a site, so check wp plugin deactivate --help on your server before relying on flags.

If the log is empty

An empty log after a reload means the error did not reach WordPress’s logging, or the log cannot be written. Check:

File permissions. PHP has to be able to write to wp-content. File ownership matters more than numeric modes when it cannot.
The wrong wp-config.php. Some hosts keep a copy one level above the web root. WordPress reads the one it finds.
A syntax error in wp-config.php itself. If you just edited it, a missing semicolon stops everything before logging starts. Restore the previous version.
The server’s own PHP error log. Hosts keep one outside WordPress. The fatal error may be there.

If the message says memory exhausted

“Allowed memory size of … bytes exhausted” is a PHP fatal error like any other, and the path in the message shows what was running when it ran out. Raising the limit gets you past one page load. The real question is what is using the memory, and the trace usually names a plugin.

Recovery mode: why you might already have an email

Since WordPress 5.2, core has a fatal error handler and a recovery mode. I read the classes on 11 October 2026.

When the handler catches a fatal error, it can send an email to the site’s admin address with a special link. The link opens a session where the broken plugin or theme is paused, so you can log in and deactivate it.

The email service is rate limited: it sends again only after a set time has passed since the last one. The default in the code is DAY_IN_SECONDS, one day, and a filter named recovery_mode_email_rate_limit changes it.

Three limits matter when you are working from this:

One email a day. If one was sent in the last 24 hours, another crash sends nothing.
Not on multisite. In the handler code I read, the recovery mode path runs only when the site is not a multisite install.
Not during updates. The handler returns early when maintenance mode is on, so a crash mid-update does not trigger it. My article on a site stuck in maintenance mode covers that situation.

Check the admin email’s inbox and spam folder first. The link is the fastest route in when the site is down.

When the fault is not in a plugin

If the log names a file in wp-includes or wp-admin, the likely cause is a damaged or half-uploaded core file. Reinstall core files from a fresh download of the same WordPress version, without touching wp-content or wp-config.php.

If the log names the theme, switch themes as described above. If it names nothing from your site, ask your host about the PHP version, because an upgrade can break code that worked before.

After the site is back

Set WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY back to false, or remove the lines.
Delete wp-content/debug.log.
Update, replace or remove the plugin that failed. If it is a plugin you need, read its changelog for the PHP version it requires.
Check that the log was not publicly readable while it existed. The file lives under wp-content, which is a web-accessible folder on most setups. Open /wp-content/debug.log in a private window on your domain. If it downloads, tell your host or add a rule to block it.

Questions people ask

Is the white screen the same as “There has been a critical error”?

They come from the same kind of fault, a PHP fatal error. In the handler source I read, the handler does nothing during maintenance mode, and its recovery step is skipped on multisite. I did not trace which screen each case ends in, so I will not say which one you will see.

Will WP_DEBUG slow down my site?

It adds work and exposes notices. The documentation tells you not to leave it on for live sites. Use it for the diagnosis and then turn it off.

Can I fix it without FTP or SSH?

Some hosts give a file manager in the control panel, and that does the same job. Without any file access, the recovery mode email link is the other route.

Do this today

Add the three debug lines to wp-config.php, load the broken page once, and read the last “Fatal error” line in wp-content/debug.log. Rename the plugin or theme folder it names.

Resources

WordPress developer docs: Debugging in WordPress, read 11 October 2026.
WP_Recovery_Mode and WP_Recovery_Mode_Email_Service, read 11 October 2026.
WP_Fatal_Error_Handler, read 11 October 2026.
WP-CLI: wp maintenance-mode, read 11 October 2026.
On this site: reading WordPress access logs and how 301 errors show up.

WordPress White Screen of Death: Read the Debug Log, Not Guesses