WordPress white screen of death: why the page is blank and how to fix it

The tab has finished loading and there is nothing in it. No logo, no menu, no error, just white. That is the WordPress white screen of death, and it looks worse than it usually is. PHP quit before the page was done, and the reason was written to a log nobody showed you.

What is the WordPress white screen of death?

It is a PHP fatal error with the error text hidden. WordPress.org’s guide to common errors puts it down to a plugin, a theme or running out of memory in most cases.

WordPress 5.2 and later normally trap a fatal error and print “There has been a critical error on this website” in place of the blank page. So on a current site, a true white screen means the catch did not happen. Our post on what the critical error message means covers that version of the same crash.

Tracing the crash and stopping a repeat after the next update is what our WordPress maintenance plans cover.

Why did our lab show three different screens for one error?

We wanted to see how one broken line changes what a visitor gets. On 17 Oct 2026, at 12:07 PM ET, we dropped a throwaway plugin file into a test site running WordPress 7.1.3 on PHP 8.3.33. It called create_function(), a function PHP’s manual lists as gone since version 8, and we made it fail in three ways.

The last row is the white screen. The PHP log line was the same in all three:

Uncaught Error: Call to undefined function create_function() in /wordpress/wp-content/mu-plugins/zz-ops95-wsod.php:18

Watch for the middle row. A page that stops halfway, with the header in place and the rest gone, is the same fatal error. If your site looks cut off, treat it as a crash, not a layout bug.

Meanwhile wp-login.php answered 200 on every run. Being able to log in tells you nothing about the front of the site.

Where do you find the error behind the blank page?

The blank page hides the error, but PHP still wrote it down. Start with the error log in your hosting control panel, since reading it changes nothing on the site.

If WordPress did catch the crash, check the admin inbox and its spam folder for an email titled “Your Site is Experiencing a Technical Issue”. It names the plugin or theme and carries a recovery mode link. That link opens the login page in recovery mode; log in, and the broken plugin or theme stays paused while you deactivate it. What that technical issue email contains is set out in our earlier test.

No log there? Turn on WordPress’s own. In wp-config.php, before the “stop editing” comment, set WP_DEBUG and WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false, so the text goes to a file and stays off the screen. Load the blank page once more. The file appears as wp-content/debug.log.

Scroll to the bottom and read the newest fatal error. The path at its end gives it away: whatever folder follows plugins/ or themes/ is what crashed. Then set WP_DEBUG back to false, because anyone can download debug.log while logging is on.

How do you bring the site back before you know the cause?

Give the plugins folder a new name, such as plugins.hold. WordPress.org’s troubleshooting FAQ uses this trick, because WordPress then cannot find any plugin and runs without them, while their settings wait in the database. If the page comes back, a plugin was to blame. Restore the old folder name and switch them on again one by one until the white page returns.

A theme named in the log gets the same treatment: rename its folder, and WordPress drops to a default theme. A line about “Allowed memory size” means PHP ran out of memory; the wp-config.php line that cleared it is in our test of the memory exhausted error.

Fixed it, and visitors still get a blank page? Clear the cache in your caching plugin and the cache in your host’s panel, then check again in a private window. A cache can keep serving the saved blank page to visitors, while you, logged in as the admin, skip the cache and see a working site.

When we take on a white screen, we find the line, switch off or replace what broke, and test the update on a staging copy before it reaches the live site again.

What changed right before the screen went white?

Most of the time, something was updated an hour or a day earlier. Old code met a newer WordPress, theme or PHP and could not run. Our walk back through a site broken after an update goes through each suspect in turn.

What did this lab leave out?

• A real host. Apache or nginx may show their own “500 Internal Server Error” page where Playground sent an empty body.
• We did not test this: a half page arriving as a 200. In our lab even the half page came back as a 500; on a server that has already sent the headers, it can arrive as a 200 instead.
• A real old plugin, which may fail on one page only.
• debug.log itself. We did not turn it on in the lab; the logging steps above follow WordPress.org’s debugging page.
• File permissions. A plugin or theme folder that the web server cannot read may also end in a blank page, but we never tried it.

What is the first thing to do?

Open your site logged out, in a private window, find the newest fatal error in the log, and rename the folder it points to. A path to a file nobody on your team added changes the order: read what to do in the first hour after a WordPress hack before anything else.

Page still blank, or orders slipping away? Our free WordPress site check takes your site address and a line on what you see. Within 2 business days you get a written report naming the cause and what fixing it involves. If you already know what to fix, the one-off fixes are listed here. Or describe the blank page to us. We post one real site fix a day on our LinkedIn Page.