11 Ways to Fix the WordPress White Screen of Death

You load your WordPress site and see nothing. No homepage. No dashboard. Sometimes not even an error message.

That is the WordPress White Screen of Death. It usually means WordPress hit a fatal problem before it could show the page. Your content is usually still in the database. The site is failing to load, not disappearing.

Do not try every fix at once. A blank page is a symptom. The fastest safe fix comes from matching the symptom to the most likely cause.

Start With The Safest Fix

Before you edit files, decide how much downtime you can tolerate.

Restoring is not failure. On a WooCommerce store or lead site, it is often the right business move. If you use BlogVault and have a clean backup, restore the live site first when downtime matters, then test updates on a staging site.

If you troubleshoot first, make sure you have:

• a recent backup or restore point
• hosting control panel access
• SFTP, FTP, or file manager access
• access to the site admin email inbox
• a list of recent changes
• host support details

Match The Symptom To The Fix

Use this table to choose your first real test. It keeps you out of the slowest path.

The pattern matters more than the exact wording. A blank wp-admin page after an update points to a different fix than one blank page built with a page builder.

Confirm What Is Broken

Do these checks before changing the site. They often save half the work.

• Check the site in a private window: Open the homepage, wp-admin, and the exact broken page.
• Check another device or network: This rules out browser cache or a local connection issue.
• Check other sites on the same hosting account: If they are also down, contact the host first.
• Check what changed recently: Look for plugin updates, theme updates, WordPress updates, new snippets, migrations, PHP version changes, or traffic spikes.
• Check the admin email inbox: Include spam and promotions folders.

If other sites on the same account are failing, stop digging through WordPress files. The problem may be hosting, PHP, disk space, database access, or a firewall rule.

Use Recovery Mode

WordPress 5.2 and newer can send a recovery email when a plugin or theme causes a fatal error. The subject often says Your Site is Experiencing a Technical Issue.

• Open the recovery email: Use the special link to access recovery mode.
• Disable the named plugin or theme: WordPress may already know what crashed.
• Update, replace, or roll back the culprit: Do not re-enable it just because the site loads again.

Recovery mode is the cleanest fix when it works. It does not always appear. If email is broken, the admin email is old, or the error happens too early, WordPress may never send the message.

No recovery email means you need to look at logs.

Turn On Safe Debug Logging

Logs turn a blank screen into a clue. Use your host’s file manager, SFTP, or FTP to open wp-config.php. Add or update these lines above the line that says That’s all, stop editing! Happy publishing.

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

Reload the broken page once or twice. Then check the WordPress debug log at wp-content/debug.log. Look for:

• Fatal error: WordPress stopped on a serious PHP error.
• Parse error: A file has broken PHP syntax.
• Allowed memory size exhausted: PHP ran out of memory.
• Call to undefined function: A plugin, theme, or PHP version mismatch may be involved; use the exact function name to narrow the undefined function fatal error.
• A plugin or theme path: Start with that exact folder.

Keep WP_DEBUG_DISPLAY set to false on a live site. It keeps raw errors and file paths away from visitors. Turn debug logging off after the fix, unless your site normally keeps private logging enabled.

Disable Plugins

Plugins are the most common cause I check first when a WordPress site goes blank after an update. They run inside the same request as WordPress, so one bad plugin can stop the whole page.

If the dashboard works:

• Open the plugins screen: Go to Plugins > Installed Plugins.
• Deactivate all plugins: Reload the broken page.
• Reactivate in batches: If the site works, turn plugins back on until the problem returns.

If the dashboard is blank:

• Open file access: Use SFTP, FTP, or your host’s file manager.
• Go to the content folder: Open wp-content.
• Rename the plugins folder: Change plugins to plugins-disabled.
• Reload the site: If it works, plugins caused or triggered the issue.
• Restore the folder name: Change it back to plugins.
• Test plugin folders in batches: Rename half the plugin folders, reload, then keep narrowing the broken half.

On large sites, testing half at a time is much faster than testing 40 plugins one by one. Also check wp-content/mu-plugins. These are must-use plugins. They load automatically and may not turn off from the dashboard.

When you find the culprit, keep it disabled until you know the cause. Update it, replace it, roll it back, ask the developer, or use a deeper guide to troubleshoot WordPress plugin conflicts. A site that works after disabling all plugins is a diagnosis, not the final repair.

Switch Themes

A theme can also cause the WordPress white screen of death, especially if the error is in functions.php, a template file, or a copied snippet.

If the dashboard works:

• Open the themes screen: Go to Appearance > Themes.
• Activate a default WordPress theme: Use a current default theme.
• Reload the broken page: If it works, the active theme needs repair.

If the dashboard is blank:

• Open the themes folder: Go to wp-content/themes.
• Confirm a default theme exists: WordPress needs one to fall back to.
• Rename the active theme folder: This forces WordPress away from it.
• Reload the site: Check the frontend and admin area.

If there is no default theme installed, upload one before forcing the switch.

If the log names functions.php, check the newest snippet first. Common problems are a missing semicolon, a broken bracket, pasted smart quotes, or extra output in the wrong place.

Fix Memory Exhaustion

Memory errors are easy to spot because the log usually says Allowed memory size exhausted.

This often appears after a WooCommerce change, a heavy page builder edit, a product import, image generation, or one very complex page.

• Open wp-config.php: Use file manager, SFTP, or FTP.
• Raise WordPress memory: Add this above the stop-editing line.

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

• Reload the broken page: Check whether the site returns.
• Ask the host if nothing changes: Some hosts enforce a lower hard limit.

Raising memory can get the site online, but it may not be the root fix. If the same issue keeps coming back, find the plugin, import job, page builder layout, query, or hosting limit that is using too much memory.

Clear Cache

Cache can make a fixed site look broken, or make one visitor see the white screen while another sees the working site.

• Check in a private window: This avoids old browser cache.
• Clear the WordPress cache plugin: If admin works, purge cache from the plugin.
• Clear host cache: Use your host dashboard or ask support.
• Clear CDN cache: Purge Cloudflare or any other CDN you use.
• Clear object cache if your host has one: This matters on managed hosting.

After each major fix, retest the homepage, wp-admin, and the original broken URL.

Do not delete unfamiliar folders under wp-content unless you know what created them. Some cache folders are safe to clear. Some folders are not cache.

Fix Failed Updates

If the blank screen started during or right after a WordPress update, check for a stuck maintenance file or incomplete WordPress files.

• Look for .maintenance: It sits in the WordPress root folder.
• Delete it only if the update is stuck: This can restore access when WordPress is trapped in maintenance mode.
• Complete the interrupted update: Use the dashboard if it returns, or ask the host if files are incomplete.
• Replace WordPress core only when needed: Use a fresh official WordPress package.

If the failure involved a plugin update rather than core, troubleshoot that update before replacing WordPress files. WP Remote also covers when a WordPress update broke your site.

Core replacement is not the normal first fix. Use it when the timing or logs point to corrupted WordPress files, missing admin files, or an interrupted core update.

Reset .htaccess

A bad .htaccess file can cause a white screen, a 500 error, or broken routing.

• Find .htaccess: It is in the WordPress root folder.
• Rename it: Use .htaccess_old.
• Reload the site: If it works, the file was part of the problem.
• Regenerate permalinks: Go to Settings > Permalinks and save changes.

Do not paste random PHP or memory rules into .htaccess. On many servers, those rules can break the site.

Check Permissions And PHP Version

Permissions decide whether WordPress can read and write files. PHP version decides whether your plugins and themes can run on the server. Common permission baselines are:

• folders: 755
• files: 644
• wp-config.php: more restrictive, based on host guidance

Never set everything to 777. It may make one error disappear, but it creates a security risk.

If the white screen started after a migration, restore, host move, or manual upload, ask the host to check file ownership too. Ownership problems can look like WordPress file permissions problems.

Also ask whether PHP changed recently. An old plugin or theme can work for years, then fail when the host upgrades PHP. A temporary rollback to a supported older PHP version can help while you update or replace incompatible code; change it deliberately if you need to change the PHP version in WordPress.

Site Health can help orient the PHP and server-side checks when the dashboard is still reachable.

Use Server Logs When WordPress Logs Are Empty

Sometimes WordPress cannot write to debug.log because the error happens before WordPress gets far enough.

Ask your host for logs around the time the site went blank. Ask them to check:

• PHP fatal errors
• Apache or Nginx errors
• memory and process limits
• disk space
• database connection failures
• file ownership problems
• firewall or ModSecurity blocks
• recent PHP version changes

This is also the right point to contact a WordPress developer if the site is revenue-critical, custom code is involved, or the same fix keeps failing.

Send the helper the useful facts: when it started, what changed, which URLs are blank, whether admin works, the error text, log excerpts, steps already tried, and whether a backup exists.

Fix One Blank Page

If only one post, page, product, or landing page is blank, do not treat it like a whole-site failure. The cause is often tied to that page:

• a page builder module
• a shortcode
• a custom template
• a product block
• a form embed
• a memory-heavy layout
• a plugin that runs only on that page

If admin works, duplicate the page and remove sections in chunks until the page loads. If the page is important, test this on staging first.

Rarely, a very long page with many shortcodes or nested blocks may hit PCRE limits. PCRE is the pattern-matching engine PHP uses for some text processing. Ask the host before changing those limits. This is an edge case, not a standard first fix.

After The Site Loads

When the site comes back, finish the cleanup while the cause is fresh.

• Turn off debug display and logging: Return them to the site’s normal setup.
• Restore test folder names: Undo any temporary folder renames.
• Keep the culprit disabled: Do not re-enable it until it is fixed.
• Regenerate .htaccess if you renamed it: Save permalinks again.
• Clear all cache layers: Browser, plugin, host, CDN, and object cache; use a WordPress cache clearing checklist if several layers are involved.
• Test important paths: Homepage, admin login, forms, checkout, search, account pages, and the original broken URL.
• Check logs again: Make sure new fatal errors are not still appearing.
• Write down the cause: Include what changed and what fixed it.

If you restored a backup to get the site online, reproduce the issue on staging before applying the same update again. BlogVault staging is useful here because you can test the plugin, theme, PHP version, or update path without using the live site as the test area.

Prevent It Next Time

You cannot prevent every blank screen, but you can make the next one shorter and safer.

• Keep automatic offsite backups: A backup is useful only if you can restore it.
• Test restores: Do not learn your restore process during an outage.
• Test updates on staging: Use staging before plugin, theme, core, or PHP changes.
• Avoid abandoned plugins and themes: Old code is often the quiet risk.
• Stop editing live theme and plugin files: Use staging, a child theme, or a safe snippets workflow.
• Watch uptime and errors: A blank site should not depend on a customer telling you.
• Match hosting to the site: WooCommerce, page builders, and large catalogs need more resources than a small brochure site.

BlogVault fits this workflow because backups, restore, and staging all reduce the same risk: making emergency changes directly on a broken live site.

FAQs

Conclusion

The WordPress White Screen of Death looks worse than it usually is. Start by protecting the site, then use the scope of the problem, recent changes, recovery mode, and logs to decide what to test. Plugins and themes are the most common causes, but memory, cache, failed updates, .htaccess, permissions, PHP changes, and server limits all have clear next steps.

Do not let the live site carry every experiment. Once it loads again, clean up debug settings, fix or replace the culprit, test the important pages, and move risky updates to staging. That is how you turn a blank screen from a panic event into a handled incident.

Written by

Shivani M

Shivani enjoys crafting guides that make every aspect of using WordPress simple and easy to follow. When she's not glued to her laptop, you can find her buried in a good book or occasionally, painting.