How to Fix the WordPress White Screen of Death? 2026

I still remember the first time my own site went blank — a white page where my homepage used to be, with no error message and no way into wp-admin. That moment of panic is exactly why this guide exists.

The good news: the WordPress white screen of death (often shortened to WSoD) looks terrifying, but it is fixable in almost every case. In this step-by-step walkthrough, I’ll show you the exact order I use to diagnose and repair it, starting with the safest fixes and finishing with the deeper server-level checks. By the end, you’ll know which step applies to your situation and what to do next.

What Is the WordPress White Screen of Death?

The WordPress white screen of death is a blank white browser page that appears when a fatal PHP error stops WordPress from running before any content can render. Because the error happens before HTML is produced, the browser receives an empty response and shows nothing — no message, no styling, no WordPress login link.

There are three common shapes this takes, and recognizing yours will save you hours:

• Frontend only white, wp-admin still works: Usually a plugin or theme bug affecting public pages. You can still log in and fix things from the dashboard.
• Frontend and wp-admin both blank: A deeper problem — memory exhaustion, corrupted core files, or a bad .htaccess. You’ll need FTP access to repair it.
• Browser-specific behavior: Chrome may show an HTTP 500 error while Firefox and Safari show a completely empty page. If the same site looks broken in one browser and fine in another, you’re definitely looking at a WSoD, not a browser issue.

One more clue that confirms you’re dealing with WSoD: many users receive an email with the subject line “Your Site is Experiencing a Technical Issue” or “Critical Error” right after it happens. That email contains a Recovery Mode link, which we’ll cover in Step 11. Check your inbox before you do anything else.

Common Causes of the WordPress White Screen of Death

Before we touch anything, it helps to know what’s actually breaking. In my experience debugging WSoD on dozens of sites, the cause almost always falls into one of these categories:

• Plugin conflicts: A plugin update that clashes with your theme, another plugin, or your PHP version. This is the single most common cause, especially after overnight auto-updates.
• Theme errors: A bad code snippet pasted into functions.php, an incomplete theme update, or a theme that simply isn’t compatible with your current WordPress version.
• PHP memory exhaustion: Your site hits the PHP memory limit and stops. The error message “Allowed memory size exhausted” usually points here, but on production sites with display errors off, you’ll just see white.
• Corrupted .htaccess file: A bad rewrite rule from a plugin install or removal, often introduced by security or caching plugins.
• Failed auto-update: When a core, plugin, or theme update is interrupted, WordPress leaves a .maintenance file behind that locks the site until removed.
• PHP version incompatibility: Your host upgraded PHP and a plugin still uses deprecated functions.
• Corrupted core files: Usually from a botched manual update, a failed migration, or incomplete FTP transfer.
• Incorrect file permissions: WordPress can’t read what it needs to read, so PHP fails silently.
• The hidden mu-plugins folder: Plugins in wp-content/mu-plugins load automatically and bypass the normal deactivation workflow. Most users don’t even know this folder exists.

If you don’t yet know which one is your culprit, that’s completely fine — the steps below are ordered so the most likely causes are fixed first.

Before You Start: Back Up Your Site

Take a full backup before you change a single file. The repair steps below are safe, but a backup gives you a guaranteed rollback point if anything unexpected happens.

Use whichever method is easiest for you:

• Hosting control panel: Most hosts (cPanel, Plesk, custom dashboards) include a one-click backup tool. This is the fastest option.
• A backup plugin: UpdraftPlus, BlogVault, or Solid Backups can create a complete backup of your files and database on a schedule.
• Manual backup: Download wp-content via FTP and export the database from phpMyAdmin. Use this if you can’t reach wp-admin at all.

One note on file ownership: if you change file permissions in Step 9 and need to revert, knowing the original owner (usually your hosting username) saves a frustrating support ticket.

Quick Fix Summary: How to Fix the WordPress White Screen of Death

If you only have two minutes, run through these eight steps in order. Most WSoD cases are resolved by Step 6:

1. Back up your site.
2. Check whether you can access wp-admin — this decides your next move.
3. Enable WordPress debug mode to surface the actual error.
4. Clear browser, plugin, and server cache.
5. Deactivate all plugins via dashboard or FTP.
6. Switch to a default WordPress theme like Twenty Twenty-Four.
7. Raise the PHP memory limit to 256M.
8. Regenerate .htaccess, delete .maintenance, and re-upload core files if needed.

Still stuck after Step 8? Skip ahead to Step 11 (Recovery Mode) and Step 12 (contacting your host). The detailed walkthrough below explains each step with the exact commands and file edits.

Step 1: Check Whether You Can Access wp-admin

Before changing anything, try loading yourdomain.com/wp-admin. The answer tells you which path to take.

If wp-admin loads (even with a different error), most of your fixes can happen from the dashboard — deactivating plugins, switching themes, and clearing caching plugin settings all become one-click actions. Focus on Steps 4, 5, and 6 first.

If both the frontend and wp-admin are blank, you’re dealing with a deeper issue. You’ll need FTP, SFTP, or your hosting file manager for the rest of the repair. Don’t worry if you’ve never used FTP — file managers in cPanel and Plesk work the same way, just through a browser.

A Reddit thread on r/Wordpress sums it up from one user who got stuck: “My frontend and admin site is locked out and facing a white screen issue.” That’s exactly the scenario Steps 2, 4, and 6 are designed for.

Step 2: Enable WordPress Debug Mode (WP_DEBUG)

The fastest way to stop guessing is to turn on debug mode. WordPress has a built-in system that writes the actual PHP error to a file you can read — even when visitors see nothing but white.

Open wp-config.php in your site root via FTP or file manager. Find the line that says /* That's all, stop editing! Happy publishing. */ and add these three lines directly above it:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Here’s what each line does:

• WP_DEBUG — turns the debugging system on.
• WP_DEBUG_LOG — tells WordPress to save errors to /wp-content/debug.log.
• WP_DEBUG_DISPLAY — set to false so visitors don’t see scary PHP errors on the live site.
• @ini_set( 'display_errors', 0 ) — a belt-and-braces line that hides errors from the HTML output.

Reload your broken page, then open /wp-content/debug.log via FTP. The last line is almost always the culprit — a “Fatal error”, “Parse error”, or “Allowed memory size exhausted” line pointing to a specific plugin folder, theme file, or core file. That filename is your roadmap for the next step.

Once your site is back, remember to set WP_DEBUG back to false in production.

Step 3: Clear Browser, Plugin, and Server Cache

It’s surprisingly common to repair a WSoD correctly and then think the fix didn’t work — because the cached version of the broken page is still being served. Clearing cache in three places usually solves this.

Browser cache: Hard refresh the page with Ctrl + F5 on Windows or Cmd + Shift + R on Mac. If you want a full clear, open your browser settings and clear cached images and files for your domain.

Plugin cache: Open your caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache, etc.) and click “Purge Cache” or “Clear Cache”. For WP Rocket specifically, hover over the plugin menu and choose “Purge Cache”.

Server cache: Managed hosts like WP Engine, Kinsta, SiteGround, and Pressable maintain their own server-level cache. Log into your hosting dashboard and look for a “Cache” or “Performance” panel — there’s usually a “Purge All” button. Users on managed hosts frequently report this distinction catches them out.

Step 4: Deactivate All WordPress Plugins

Plugins cause the majority of WSoD cases, especially right after an overnight auto-update. Deactivating all of them at once is the fastest way to rule them out.

Method A — Dashboard (if wp-admin works): Go to Plugins → Installed Plugins, select all, choose “Deactivate” from the bulk action dropdown, and click Apply. If the white screen disappears, reactivate plugins one by one until it returns — that last one is the offender.

Method B — FTP (if wp-admin is locked): Connect via FTP, SFTP, or your hosting file manager. Navigate to /wp-content/ and rename the plugins folder to something like plugins_old. WordPress will automatically deactivate every plugin because it can’t find them. Refresh your site.

If the site comes back, rename the folder back to plugins and log into wp-admin. All plugins will appear deactivated. Reactivate them one at a time, refreshing the site after each, until the WSoD returns. The last plugin you activated is the broken one.

Method C — WP-CLI (for SSH-capable users): If your host gives you SSH access, run:

wp plugin deactivate --all

Then reactivate them in batches to find the culprit:

wp plugin activate plugin-one plugin-two plugin-three

The binary search shortcut for plugin-heavy sites: If you have 30+ plugins, activating one by one will take forever. Instead, deactivate all, then activate half of them. If the WSoD returns, the bad plugin is in that half. Keep splitting the suspect group in half until you isolate it. This binary search approach saves hours on large sites.

Don’t forget mu-plugins: Check /wp-content/mu-plugins/. These “must-use” plugins load automatically and are not deactivated when you rename the regular plugins folder. If your debug log points to a plugin you can’t see in your dashboard, it’s probably hiding here. Rename the mu-plugins folder as well to test.

Step 5: Switch to a Default WordPress Theme

If deactivating plugins didn’t bring your site back, the theme is the next suspect. A broken theme — often from a copy-paste mistake in functions.php — can take the whole site down.

Method A — Dashboard: Go to Appearance → Themes and activate Twenty Twenty-Four (or another default theme like Twenty Twenty-Three).

Method B — WP-CLI: Run:

wp theme activate twentytwentyfour

Method C — FTP: Navigate to /wp-content/themes/ and rename your active theme’s folder (for example, my-theme to my-theme_old). WordPress will fall back to the latest default theme automatically.

If your site comes back after switching themes, the problem is in your old theme. Check functions.php for any recently added code snippets — a missing semicolon or stray character there will crash the entire site.

Step 6: Increase the PHP Memory Limit

The “Allowed memory size exhausted” error means WordPress ran out of PHP memory. WooCommerce checkouts, large product imports, page builders, and complex plugins are common triggers.

Open wp-config.php and add this line above the “stop editing” comment:

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

That tells WordPress to ask PHP for up to 256 megabytes. If your host’s hard cap is lower (some shared hosts cap at 128M), you’ll need to either raise it through your hosting control panel or ask support. The setting in wp-config.php cannot exceed what the server actually allows.

Apache-only alternative: You can also try adding this to .htaccess:

php_value memory_limit 256M

Warning: this method breaks sites running PHP-FPM (most modern hosts) with a 500 error. If your site goes from white to “Internal Server Error” after editing .htaccess, remove that line and use the wp-config.php method instead.

Full control via php.ini: If you have access to php.ini (often through cPanel’s MultiPHP INI Editor), you can set the limit directly there. This is the most reliable method on shared hosting.

Step 7: Regenerate or Fix the .htaccess File

A bad .htaccess file is a classic cause of WSoD, especially after installing or removing security and caching plugins. The fastest repair is to let WordPress regenerate it from scratch.

Connect via FTP and rename .htaccess to .htaccess_old. Then log into wp-admin (if accessible) and go to Settings → Permalinks and click “Save Changes” without changing anything. WordPress writes a fresh .htaccess file.

If you can’t reach wp-admin, create a new .htaccess file in your site root with this default WordPress content:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Refresh your site. If it loads, your old .htaccess was the problem. If your permalink structure was anything other than “Plain”, you’ll need to restore those custom rules — but get the site working first, then re-add them carefully.

Step 8: Delete the .maintenance File

When a WordPress core, plugin, or theme update is interrupted — by a server timeout, a closed browser, or a connection drop — WordPress creates a temporary .maintenance file in your site root. Under normal circumstances, WordPress removes it automatically when the update finishes. If the update fails, the file stays, and your site stays locked.

Connect via FTP or file manager, navigate to your site root (the same folder that contains wp-config.php), and look for a file literally named .maintenance. Delete it. Refresh your site.

This is a one-second fix that solves WSoD cases that started right after an update — a very common Reddit scenario where users report the white screen appearing “out of nowhere” the morning after an auto-update.

Step 9: Check and Fix WordPress File Permissions

Wrong file permissions can break a WordPress site silently. If PHP can’t read a file, you get a blank page with no error. The correct permissions are:

• All folders: 755
• All files: 644
• wp-config.php: 440 or 400 (extra security)

To fix them, open cPanel File Manager, your FTP client (FileZilla, Cyberduck, Transmit), or SSH. Right-click the wp-content, wp-includes, and wp-admin folders, set permissions to 755, and check “Recurse into subdirectories” for folders only. Then select all files inside those folders and set them to 644.

For wp-config.php, set it to 440 for a nice balance of security and accessibility. Most hosts recommend this in their documentation.

Never set anything to 777. That gives every user on the server write access to your files — a serious security hole and almost never the correct answer.

Step 10: Re-upload WordPress Core Files

If nothing above worked, your core WordPress files might be corrupted. Replacing them is safe and won’t touch your content, plugins, themes, or settings.

Download a fresh copy of WordPress from wordpress.org/download/. Unzip it on your computer. Connect to your site via FTP and upload two folders:

• /wp-admin/ — overwrites the entire admin folder
• /wp-includes/ — overwrites the entire includes folder

Also upload the individual files in the root of the WordPress download: wp-activate.php, wp-blog-header.php, wp-comments-post.php, wp-config-sample.php, wp-cron.php, wp-links-opml.php, wp-load.php, wp-login.php, wp-mail.php, wp-settings.php, wp-signup.php, wp-trackback.php, and xmlrpc.php.

Critical warning: do NOT upload or overwrite the wp-content folder. That’s where your themes, plugins, and uploads live. Overwriting it would destroy your site.

Refresh your site once the upload completes.

Step 11: Use WordPress Recovery Mode (WP 5.2+)

Since WordPress 5.2, your site automatically enters Recovery Mode when it hits a fatal error, and emails the site admin a special link. Many users see the email, assume it’s spam, and miss the easiest fix available.

The email subject is usually “Your Site is Experiencing a Technical Issue” or “Critical Error” and comes from your site URL. Open it, click the recovery link, and WordPress loads the dashboard with the broken plugin or theme paused. From there, you can deactivate the offender and bring the rest of the site back online.

If you’re the site admin and never received this email, check:

• Your spam folder
• That WP_DEBUG_DISPLAY isn’t accidentally sending error emails somewhere else
• That the admin email in Settings → General is correct and deliverable

Recovery Mode is genuinely the fastest path back for users who still receive email from their site.

Step 12: Contact Your Hosting Provider

When DIY fixes fail, the cause often lives at the server level — and only your host can see it. The trick is to ask the right questions so you don’t get bounced back to “try clearing your cache”.

Send your host this short checklist:

• Can you share the last 50 lines of my site’s PHP error log?
• Can you share the last 50 lines of the PHP-FPM or Apache error log?
• What PHP version is my site running? (Note: WordPress 6.5+ recommends PHP 8.1+ as of 2026.)
• What is my server’s hard PHP memory limit, and can it be raised?
• Has ModSecurity or any WAF rule blocked my IP or a recent request?
• Is there a server-side cache I need to purge beyond my plugin cache?

Managed hosts like WP Engine, Kinsta, and SiteGround often have server-side caching layers, malware scanners, and WAF rules that can all trigger WSoD on their own. They can also roll back to a known-good server snapshot faster than you can rebuild by hand.

For users on shared hosting (GoDaddy, Bluehost, HostGator), be aware that some hosts won’t raise the PHP memory limit or modify php.ini. If that’s your situation, and the WSoD keeps returning, upgrading to managed WordPress hosting is often the most cost-effective next step.

How to Prevent the White Screen of Death in the Future

Once your site is back, a few small habits will keep the WSoD from coming back. Most of these are free or built into good hosting.

Use a staging site for updates. Most managed hosts and several plugins (WP Staging, Duplicator) let you clone your site to a private test area. Run plugin, theme, and core updates there first. If the staging site stays green for 24 hours, push the updates to production.

Schedule automatic backups. Daily backups mean a WSoD is a 10-minute rollback, not a 4-hour repair. UpdraftPlus, BlogVault, and Solid Backups all handle this with minimal setup.

Update plugins one at a time. Mass updates are the single biggest WSoD trigger because you can’t isolate which plugin caused the failure. Take the extra two minutes.

Monitor your error log weekly. Even a healthy site produces warnings. Reading debug.log once a week catches plugin conflicts and PHP deprecation notices before they escalate into a full crash.

Stick to trusted plugin sources. Nulled or pirated plugins are the most common source of malicious or broken code that triggers WSoD. Always install from wordpress.org or directly from the developer’s site.

Keep PHP current. Each new WordPress release raises the minimum recommended PHP version. As of 2026, WordPress 6.5+ officially recommends PHP 8.1 or higher. Hosts that run old PHP versions eventually break plugins that rely on newer syntax.

Taken together, these habits reduce the chance of ever seeing a blank page again. And if you do, you’ll have a clean rollback ready in seconds.

Frequently Asked Questions

Conclusion: Stay Calm and Fix It Step by Step

The WordPress white screen of death looks like a disaster, but it’s almost always fixable with a 15-minute walkthrough. In most cases, the cause is a plugin conflict, a memory limit, or a corrupted .htaccess — all of which are reversible without touching your content.

To recap the workflow: check whether wp-admin is reachable, enable WP_DEBUG to surface the actual error, clear all three cache layers, deactivate plugins via dashboard or FTP, switch to a default theme, raise the PHP memory limit, regenerate .htaccess, delete the .maintenance file, re-upload core files if needed, and finally escalate to your host with a specific list of questions. Pair that with a staging site and daily backups, and you’ll never lose more than a few minutes to WSoD again.

If your site is still down after running through every step, drop a comment below with the exact error from your debug.log and I’ll do my best to help you track down the cause.