WordPress White Screen of Death: Diagnose and Fix It Fast

The White Screen of Death is the drama queen of WordPress errors. A completely blank page, no message, no logo, no hint, just void where your business used to be. It has the scariest name and the most theatrical presentation of any WordPress failure.

It is also, despite the name, rarely serious. The WSOD is what you see when PHP crashed before it could print anything, including an error message. Something fatal happened early: a plugin, a theme, a memory limit, a corrupted file. The site's content, database, and files are almost always perfectly intact. The lights are off; the building is fine.

Newer WordPress versions usually replace the blank page with the "critical error" message (we have a full guide for that one). If you're getting pure white, you're dealing with the same family of problem, minus even the courtesy of a sentence. Here's the flashlight.

First, three quick checks

1. Is it everything or one page? Check the homepage, an inner page, and /wp-admin. All white means a site-wide fatal, plugin, theme, memory. Only some pages white points at something specific to those pages (a page builder element, a shortcode, a template). If wp-admin works, your job is much easier: you can disable things from the dashboard.

2. Is it just you? Open the site in an incognito window and check from your phone on mobile data. Occasionally a caching layer serves you a blank page while the world sees a working site. Clear browser and site cache before doing anything drastic.

3. Did the site or the server change? An update, a new plugin, a PHP version bump, a host migration. Recent change = prime suspect.

Make the error visible

The whole problem with the WSOD is silence, so step one is making PHP talk. Via SFTP or your host's file manager, edit wp-config.php and add above the "stop editing" line:

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

Reload the blank page, then read /wp-content/debug.log. In most cases the final fatal error names the exact file, and the folder that file lives in names the plugin or theme responsible. Also check your admin email: WordPress often sends a fatal-error notification with a recovery-mode link that lets you into the dashboard with the broken component suspended.

Work the suspect list

Memory limit (the WSOD's favourite cause). If the log says "Allowed memory size exhausted," add to wp-config.php:

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

If the white screen persists and your host caps PHP memory lower than that, raise it in the hosting panel or ask support.

Plugins. No dashboard access? Rename /wp-content/plugins to plugins-off via SFTP. Site returns → rename back, then reactivate one at a time until the screen goes white again. The last activation is your culprit. Roll it back a version or replace it.

Theme. Rename the active theme's folder in /wp-content/themes; WordPress falls back to a default theme. If the site returns, the theme, often a recent edit to its functions.php, is the problem. A stray syntax error in a pasted code snippet is a classic WSOD trigger: one missing semicolon, whole site gone.

Corrupted core files or a failed update. If an update was interrupted, first check for a .maintenance file in your site root and delete it (a stuck maintenance file blanks the whole site). Still white? Re-upload fresh copies of the wp-admin and wp-includes folders from a clean WordPress download, never touch wp-content, that's where your stuff lives.

Cache and CDN. After any fix, purge every cache layer, plugin cache, server cache, CDN. Many "the fix didn't work" moments are just a cached white page.

Nothing worked? Restore last night's backup, then diagnose on a staging copy without your live site bleeding visitors. If the phrase "last night's backup" made you laugh nervously, read this next.

The pattern behind the panic

Same as every WordPress emergency: the WSOD follows change (an update, a snippet, a version bump) applied directly to a live site with no safety net. A staging environment, pre-update backups, and uptime monitoring turn this entire article from an emergency into a non-event you read about once. That bundle has a name: a maintenance plan.

When WordPress is the wrong tool for the job

Here's the structural truth the WSOD exposes: WordPress executes a pile of independently-written PHP (core, theme, a dozen plugins) as one program, on every single page load. Any fatal error anywhere in that pile takes down everything. There's no isolation; the weakest plugin is the site.

If yours is a marketing site, the fixes and process above tame that risk to nearly zero, and WordPress remains the right, economical choice. But if your revenue flows through the site (bookings, orders, client portals), consider what you'd pay to make "one bad semicolon = total blackout" architecturally impossible. Custom-built applications separate concerns: a failing component degrades one feature, not the whole business. Monitoring catches it, deployments roll back automatically, and nobody's renaming folders over SFTP at 11pm. We build those too, and we'll tell you honestly whether your situation justifies one or whether that would be overkill. Judge a website not by its blank page... but by how it was built.

Staring at the void right now?

Enable the debug log, read the last fatal error, disable the named component. That's the whole game, and it resolves most white screens within the hour. If the log is Greek to you or the cause is something deeper (server config, database corruption, a hack), our emergency debugging service can take it from here, usually same-day, with a plain-English report of what happened.

May the Code Be With You.

---

WordPress Pro builds, fixes, and maintains WordPress sites, and builds custom solutions for businesses that have outgrown them. [Get emergency debugging →]