The site was working a second ago, you were finishing an article or configuring WooCommerce, and suddenly nothing. A white screen instead of the admin panel. Or the homepage disappeared, though the dashboard still opens. Sound familiar? Welcome to the club, you've met the White Screen of Death, also known as WSOD, also known as the "white screen of death" WordPress.

Panic here is the first enemy. WSOD almost never means the site is dead for good. Most often the cause is mundane: a plugin conflict after an update, poorly inserted code in functions.php, or simple lack of memory for the PHP process. In this guide, four proven ways to bring the site back to life and a fifth built into the WordPress core that even experienced users forget about.

💡 Quick overview:

• Disable the problematic plugin through FTP (rename folder) or in bulk by renaming the plugins directory
• Disable the conflicting theme using the same method: themes folder → rename the active theme directory
• Raise the PHP memory limit with the WP_MEMORY_LIMIT line in wp-config.php to 128M or 256M
• Enable WP_DEBUG and WP_DEBUG_LOG for diagnostics, learn the exact cause of the error from the debug.log file
• Use Recovery Mode (WordPress 5.2+), a built-in mechanism that sends a link to access the admin panel even during a fatal error
• Restore the site from backup if the other methods didn't work

1. Disabling the problematic plugin

Plugins are the most common cause of WSOD. You just updated your favorite caching plugin, the screen went dark. You installed a new slider, the site stopped opening. The mechanics are simple: the plugin's PHP code causes a fatal error, and WordPress stops loading the entire page.

The problem is that you can't log into the admin panel and click "Deactivate", the admin panel goes to a white screen just the same. The solution: disable the plugin directly through the file system.

How to disable one plugin through FTP:

• Connect to the server via FTP (FileZilla, WinSCP) or through the hosting file manager (cPanel → File Manager).
• Navigate to the WordPress root directory.
• Open wp-content/plugins.
• Find the problematic plugin's folder, the name matches the title (for example, akismet, woocommerce, or elementor).
• Rename the folder: add an underscore or suffix, _akismet or akismet_disabled. WordPress will perceive the rename as the plugin's absence and deactivate it.

Immediately after renaming, open the site in your browser. It works, the culprit is found. Now you can restore the folder's original name and, after logging into the admin panel, either update the plugin to a compatible version, or remove it and find an alternative.

Mass deactivation of all plugins at once. If it's unclear which exact plugin caused the failure, disable everything wholesale. Rename the wp-content/plugins folder itself to plugins_old and create a new empty plugins directory next to it. All plugins are deactivated. Then bring them back one by one: move the plugin folder from plugins_old back to plugins, log into the admin panel, activate it, and check the site. Repeat until you find the culprit.

Alternative for those who have WP-CLI. One command in the terminal replaces the FTP dance with a tambourine:

1
wp plugin deactivate --all

And then activate one by one: wp plugin activate <slug>. Fast, clean, without a file manager.

2. Disabling the conflicting theme

The second most frequent culprit is the theme. The scenarios are the same: you updated the theme to a new major version, installed a theme with a poorly written functions.php, or a plugin conflicted with the current theme after a WordPress update.

The fix mechanism is almost identical to the plugin one:

• Log in via FTP to wp-content/themes.
• Find the active theme folder (the one currently installed on the site).
• Rename it, for example, add _disabled to the end of the name.

WordPress, not finding the active theme, will automatically switch to the default Twenty Twenty-Five theme (or Twenty Twenty-Four, depending on the WP version). The site will load with the default design, but all your content will remain in place. Important: don't delete the default theme, otherwise there will be nothing to switch to, and you'll get another round of WSOD.

Poorly coded themes and WordPress updates. After a major WordPress release, old themes using deprecated functions or hooks can break. Quality themes from verified developers are updated within a few days after the core release. If your theme hasn't been updated for six months or more, that's a red flag: switch to one that's actively maintained.

Editing functions.php and other theme files. A typo in functions.php, an extra bracket, an incorrect hook call, and the site goes down. If you edited theme files immediately before WSOD appeared, replace the changed file with the original version from a backup or the theme distribution. Without a backup, download the theme again from the source and upload the clean file.

3. Exceeding the PHP memory limit

The site grew, plugins multiplied, traffic went up, and suddenly WSOD. A classic symptom that the PHP process ran out of RAM. Especially relevant on cheap hosting, where one server serves hundreds of sites, and the limit per client is cut to a minimum.

WordPress officially recommends a minimum of 64 MB of memory, but this recommendation dates back to the PHP 5.6 era and five plugins per site. In 2026, a realistic minimum for a working site is 128 MB, and for builds with Elementor, WooCommerce, and several dozen plugins, 256 MB.

How to increase the memory limit:

Open the wp-config.php file (located in the WordPress installation root) and add a line before the comment /* That's all, stop editing! */:

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

If the provider strictly limits PHP memory at the server level, this directive won't work, then there's only one way out: change the plan or hosting. Managed WordPress hosting (SiteGround, WP Engine, Kinsta) configures limits adequately out of the box, and the memory problem is practically never encountered there.

4. Diagnostics through WP_DEBUG

Sometimes neither plugins, nor the theme, nor memory are to blame, the cause of WSOD eludes. Then you need to make WordPress tell you what exactly went wrong.

WordPress has carried a built-in debugger WP_DEBUG for decades. By default it's disabled (white screen instead of errors, the idea is to not expose the site's internals to visitors). But for the administrator, this mode is priceless.

Add to wp-config.php:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

What happens:

• WP_DEBUG enables debug mode;
• WP_DEBUG_LOG writes errors to the wp-content/debug.log file, convenient to read without showing visitors;
• WP_DEBUG_DISPLAY with value false hides errors from the screen (you see a white screen, but logs are written).

After enabling, open the site, reproduce the problem, and look in wp-content/debug.log. There will be a line with the file, line number, and error type, for example, Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. This is the exact address of the problem.

Important: don't leave WP_DEBUG enabled on production after diagnostics, logs grow quickly and can fill up disk space.

5. Recovery Mode, the built-in savior of WordPress 5.2+

Since version 5.2, WordPress can detect fatal errors itself and offer a fallback path. Recovery Mode (recovery mode) is a feature that many administrators still don't use simply because they don't know about it.

How it works. When PHP code in a plugin or theme causes a fatal error, WordPress intercepts it, stops the problematic extension, and sends an email to the administrator's email. The email contains a link that opens access to the admin panel bypassing the problematic code. You log in, see the crashed plugin marked "caused error", deactivate it, and the site is alive again. No FTP, no folder renaming.

Recovery Mode limitations:

• The link is valid for a limited time (about a day) and is tied to an IP address;
• Requires configured mail sending from the site (SMTP plugin or hosting mail);
• Doesn't save from server-level errors (lack of memory, broken .htaccess).

And yet, if the email arrived, you save a dozen minutes of nerves and FTP movements.

Watch a short guide on fixing WSOD, all described methods with live demonstration:

⁉️🤔 Frequently asked questions

Why does the white screen appear only in the admin panel, but the site opens normally?

The error is localized in code that executes only in the control panel: a plugin metabox, theme settings page, custom admin widget. Disable recently installed plugins one by one, the culprit will be found quickly. If it doesn't help, enable WP_DEBUG_LOG and check the log after attempting to log into the admin panel.

White screen only on one post or entry page, what is it?

Most likely, the problem is in the specific entry's content: a shortcode from a nonexistent plugin, broken HTML in the text, conflict with custom fields. Open the entry through Quick Edit in the admin panel and temporarily change the status to "Draft". Does the page load? Then dig inside the content.

Can WSOD be avoided altogether in the future?

Completely eliminate it, no, but minimizing the risk is realistic. Three rules: (1) always test plugin and theme updates on a staging copy of the site before deploying to production; (2) keep daily backups of files and database; (3) don't install plugins and themes from questionable sources, especially nulled versions.

Recovery Mode didn't send an email, what to do?

Mail from a WordPress site without a configured SMTP plugin works unstably. Set up SMTP (Post SMTP, FluentSMTP, or WP Mail SMTP) as a preventive measure. If the email already didn't arrive, go back to the FTP method from section 1, it always works.

How long does the Recovery Mode link last?

The link is valid for 24 hours (more precisely, until the nonce token expires). After that you need to reproduce the error again, WordPress will send the email again.

What to do if nothing helped?

If the four methods above and Recovery Mode didn't bring back the site, the problem is deeper. Perhaps the .htaccess file is damaged (rename it and log into the admin panel, WordPress will create a new one through "Settings → Permalinks → Save"). Or PHP version incompatibility: modern WordPress requires PHP 7.4+, but the host might still have PHP 5.6.

Another diagnostic tool is the Health Check & Troubleshooting plugin from the WordPress.org team. It can launch a safe mode session: disables all plugins and switches to the default theme, but only for your browser (visitors see the normal site). With it you can safely enable plugins one by one and catch the culprit without touching production.

No time for investigation, but the site needs to be up right now? Restore the backup. If there's no backup, a lesson for the future: daily automatic backups cost a few dollars a month and pay for themselves on the first day of a disaster. Practically every hosting offers this feature in the control panel.

And most importantly, don't fear WSOD. It's unpleasant, but solvable. Now you have a step-by-step action algorithm, not panic and an empty screen.