How to Fix the WordPress White Screen of Death

What the White Screen Actually Means

A blank white page is almost always a fatal PHP error that never made it to the browser, because display_errors is off on the server. That is standard practice on any production PHP setup, including CloudStick's stack — you never want raw PHP stack traces, file paths, and variable dumps exposed to visitors. The trade-off is that when something does break at the fatal level, WordPress has nothing left to render. PHP halts execution the instant it hits the fatal error, the page output stops mid-stream, and the browser just shows whatever was sent before the crash, which in most cases is nothing at all.

This is different from a 500 Internal Server Error page or an nginx/Apache error page, because the web server itself is not the one objecting — PHP-FPM ran the script, the script crashed partway through, and the server dutifully returned whatever partial output existed, which is usually an empty body with a 200 or 500 status depending on when the crash happened. Three things account for nearly every white screen: a plugin or theme calling a function that no longer exists or throwing an uncaught exception, the script exceeding memory_limit and PHP terminating it outright, or a syntax error introduced by a direct file edit that never got validated before being saved. The fix in every case starts the same way — get PHP to tell you what actually happened instead of guessing.

Enable WP_DEBUG and Read the Log

Turning on WP_DEBUG_LOG writes the exact fatal error, file, and line number to a plain text file, which is the fastest way to identify the cause without touching production output. Open wp-config.php and add the debug constants above the line that reads /* That's all, stop editing! */. Keep WP_DEBUG_DISPLAY set to false so the error still does not print to visitors — you only want it captured to the log file, not shown on the broken page.

Reload the broken page in another tab, then look at the newest lines appended to debug.log. A line like PHP Fatal error: Uncaught Error: Call to undefined function points straight at a plugin file and function name; Allowed memory size exhausted points at memory_limit; a parse error naming a specific file and line points at a bad manual edit. You do not need to interpret the whole trace — the first fatal error entry, top to bottom, is almost always the one that matters. If you would rather not open an SFTP client or SSH session just to read one file, CloudStick's Web Application Logs section on the site's dashboard streams this same debug output live, so you can see the exact fatal error line without ever leaving the browser.

Isolate a Bad Plugin or Theme

If the log points at a plugin, or you cannot reach wp-admin at all to disable it normally, renaming the plugins folder over SFTP or a file manager forces WordPress to deactivate every plugin at once without touching the database. Connect to the server and navigate to wp-content, then rename the plugins directory. WordPress will detect the folder is missing on the next load and mark all plugins as inactive, which immediately restores the front end if a plugin was the cause.

Once the site loads again, rename plugins-disabled back to plugins so WordPress re-registers them all as inactive rather than deleting anything, then reactivate one at a time from wp-admin until the white screen returns — that last plugin is the culprit. The same logic applies to themes: if wp-cli is available, run wp theme activate twentytwentyfour to force the default theme without needing wp-admin. Without wp-cli, the same switch can be done directly in the database by updating the template and stylesheet options in the wp_options table to a theme folder you know exists on disk.

Check Memory Limits and Server Logs

If debug.log shows "Allowed memory size exhausted," the fix is raising memory_limit in wp-config.php and in the PHP-FPM pool, not just one or the other — WordPress's own WP_MEMORY_LIMIT constant cannot exceed whatever the underlying PHP pool allows. Add the constant near the top of wp-config.php, then confirm the PHP-FPM pool for the site permits at least that much.

If debug.log is empty or missing entirely, the failure may be happening before WordPress even loads its own error handling, which means the server-level PHP log is the next place to look. On CloudStick that is the site's PHP-FPM error log under the site's log directory, alongside the web server's own error log — check both, since Apache-fronted stacks and pure Nginx stacks name theirs slightly differently.

A syntax error from a bad manual edit shows up here too, usually as a parse error naming the exact file and line — open that file, find the unclosed bracket or missing semicolon, and restore a known-good copy of the file if you have one rather than guessing at the fix. If the crash traces back to a PHP version mismatch — a plugin using syntax that a newer or older PHP release does not support — CloudStick's EasyPHP tool shows the active PHP version and loaded extensions per site at a glance, which saves you from hunting through phpinfo() output manually.

Preventing Future White Screens

Most repeat white screens come from updating plugins or themes directly on production without a staging step first — test updates on a staging copy before pushing them live, and the fatal errors get caught somewhere that does not take the real site down. Keep WP_DEBUG_LOG enabled permanently on staging, and only enable it temporarily on production when you are actively diagnosing an issue, then turn it back off so the log file does not grow unbounded.

As a quick recap: enable WP_DEBUG and WP_DEBUG_LOG and tail debug.log to find the exact fatal error, rename wp-content/plugins to force every plugin off if the cause is unclear, switch to a default theme with wp-cli or the database if the theme is the suspect, and check the memory_limit setting and the PHP-FPM or web server error log if debug.log stays empty. If the site keeps breaking in ways that are hard to pin down, CloudStick's one-click staging environments let you reproduce the exact plugin and theme combination safely before ever touching the live site again.