WordPress White Screen of Death Fix Guide: Causes, Recovery Steps, and Prevention

Overview

The phrase white screen of death WordPress usually refers to a blank page caused by a fatal PHP error, memory exhaustion, output buffering issue, or a server-side problem that prevents WordPress from completing the request. Sometimes you will see a fully blank screen. Other times the page is partially rendered, or only one area of the site fails, such as /wp-admin/, a single template, or a plugin settings page.

The most useful way to approach this problem is to stop guessing and work from the outside in:

1. Confirm the scope of the outage.
2. Preserve access and create a rollback point if possible.
3. Check for recent changes.
4. Disable likely failure points in the safest order.
5. Read logs or enable debugging to confirm the cause.
6. Restore stability, then harden against repeat failures.

Common causes include:

• A plugin conflict or plugin update that introduced a fatal error.
• A broken theme file, child theme override, or incompatible template code.
• PHP memory limits that are too low for current plugin load.
• A PHP version mismatch after a hosting or server change.
• Corrupted core files during an interrupted update.
• Server configuration errors, file permission issues, or exhausted resources.
• Custom code added to functions.php, a mu-plugin, or a snippets plugin.

If you recently changed hosting, SSL, DNS, or environment configuration, keep in mind that not every blank page is purely a WordPress issue. In those cases, it can help to cross-check your broader setup with related guides such as How to Set Up SSL Certificates: HTTPS Installation and Common Fixes, How to Point a Domain to Your Website: DNS Records Explained for Beginners, and Troubleshooting Common DNS and Domain Issues: A Practical Checklist for IT Admins.

Quick triage checklist before you touch anything:

• Does the blank page affect the public site, the admin area, or both?
• Did the problem begin after a plugin, theme, core, PHP, or hosting change?
• Do you still have access to hosting, SFTP, SSH, or the file manager?
• Is there a backup or snapshot from just before the issue began?
• Can you read the server error log or enable WordPress debugging?

Checklist by scenario

Use the scenario that matches your symptoms. Start with the least destructive option and escalate only as needed.

Scenario 1: The entire site is blank, including wp-admin

This usually points to a plugin, theme, core file, or PHP-level failure.

1. Check whether the server itself is reachable. If the domain resolves and the server responds, move on. If not, investigate hosting, DNS, or recent infrastructure changes first.
2. Review recent changes. If the site failed right after an update or code deployment, that change becomes your primary suspect.
3. Disable all plugins by renaming the plugins folder. Using SFTP, SSH, or your host file manager, rename wp-content/plugins to something like plugins-disabled. Then refresh the site. If the site returns, a plugin caused the fatal error.
4. If the site recovers, isolate the plugin. Rename the folder back to plugins, then disable individual plugin folders one by one or reactivate plugins gradually from the dashboard until the blank page returns.
5. If disabling plugins does not fix it, switch themes. Rename the active theme folder in wp-content/themes. WordPress may fall back to a default theme if one is present. If not, upload a default theme first.
6. Enable debugging. In wp-config.php, set WP_DEBUG to true, log errors to file, and keep display disabled on production. Then inspect wp-content/debug.log if it is created.
7. Check PHP error logs at the server level. Fatal errors often appear there even when WordPress does not render anything useful.
8. Re-upload WordPress core files if you suspect corruption. Replace core directories and files except wp-content and wp-config.php.
9. Confirm PHP version compatibility. If the server PHP version changed recently, verify that your theme and plugins support it.
10. Increase PHP memory if logs suggest exhaustion. A memory-related fatal error can produce a blank page with no obvious message.

Scenario 2: The public site is blank, but wp-admin still works

This often means the problem is tied to the active theme, a front-end plugin, a broken template, or cached output.

1. Open a default post or page in an incognito window. Confirm whether the problem affects all front-end requests or only certain URLs.
2. Clear all layers of cache. Purge plugin cache, server cache, CDN cache, and browser cache.
3. Temporarily disable performance, page builder, SEO, redirect, security, and front-end enhancement plugins. These commonly alter rendering behavior.
4. Switch to a default theme. If the blank page disappears, compare your custom theme files, child theme overrides, and recent edits.
5. Check template files and custom code. A malformed query, unsupported function, or syntax error in template logic can fail only on front-end requests.
6. Use your browser tools. If the screen is visually blank but the response is not empty, inspect the DOM, network, and console using How to Use Browser DevTools to Troubleshoot CSS, JavaScript, and Network Errors.

Scenario 3: wp-admin is blank, but the public site still loads

This pattern usually points to an admin-only plugin, a dashboard hook, memory limit issue, or role-specific code path.

1. Try recovery mode if WordPress offers it. If WordPress sent a recovery email after a fatal error, use it to enter admin safely and identify the failing component.
2. Disable plugins first. Plugins that add admin pages, menus, or editor integrations are common causes.
3. Check your user-specific plugins or customizations. Some issues only appear for logged-in administrators.
4. Increase memory temporarily. Admin areas often use more memory than front-end views.
5. Inspect error logs and debug output. Focus on hooks that fire in admin context.

Scenario 4: Only one page, post type, or settings screen is blank

This usually means the problem is data-specific or tied to one plugin module.

1. Test a different URL of the same type. If one product page fails but others work, inspect content, custom fields, or builder data for that item.
2. Check shortcode output and block rendering. A broken shortcode or block callback can blank a single template path.
3. Temporarily disable the plugin tied to that feature. Form plugins, custom field plugins, page builders, and e-commerce extensions are frequent sources.
4. Review recent content edits. Imported markup, malformed embeds, or custom snippets can break one page while the rest of the site appears normal.

Scenario 5: The issue started right after migration, hosting change, or PHP upgrade

Here the WordPress error may be real, but the root cause is often environmental.

1. Verify the correct document root and site files are present.
2. Confirm database credentials and connectivity. While a database issue often shows a different message, some setups suppress errors poorly.
3. Check PHP version, extensions, and limits.
4. Review file ownership and permissions.
5. Validate URL, HTTPS, and mixed environment assumptions.
6. Confirm migration completeness. Partial uploads and interrupted archives can leave missing theme or plugin files.

If your problem began during a move, keep a migration checklist handy and review Step-by-Step Guide to Migrating a WordPress Site to a New Host with Zero Downtime.

What to double-check

Once you think you found the cause, pause and verify the basics before declaring the fix complete. This is where many repeat outages begin.

1. Confirm the actual trigger

If disabling one plugin restored the site, do not stop at “plugin conflict.” Check whether the trigger was:

• A new plugin version
• An outdated dependent plugin
• A theme integration issue
• A PHP version incompatibility
• Memory pressure that only surfaced after the plugin update

Knowing the exact trigger makes the next maintenance window safer.

2. Check logs after the fix

Even if the site loads again, review the debug log and server logs for warnings that may point to the next failure. A site can recover from the main fatal error while still generating notices, deprecated code warnings, or intermittent failures.

3. Test both logged-in and logged-out states

Do not test only the homepage. Verify:

• Homepage
• A standard page
• A single post
• A category or archive page
• wp-admin dashboard
• Plugin-specific admin screens
• Forms, checkout, or membership flows if applicable

A practical follow-up is to use a broader post-fix checklist like Website Launch Checklist: Everything to Test Before You Go Live.

4. Re-enable components gradually

If you disabled multiple plugins or switched themes during recovery, do not turn everything back on at once. Re-enable in a controlled sequence and test after each step. That is the fastest way to catch a second fault without losing your place.

5. Verify backups and rollback options

After a live outage, make sure your backup system is still functioning and that you know how to restore from it. A surprising number of site owners discover backup gaps only after the immediate incident is over.

6. Check for related infrastructure issues

If you changed DNS, domain routing, or SSL around the same time, confirm there is not a second issue masking itself as a WordPress failure. These guides can help if needed:

• DNS Propagation Checker Guide: How Long DNS Changes Take and What to Do While Waiting
• How to Set Up SSL Certificates: HTTPS Installation and Common Fixes

7. Document what happened

Create a short incident note with:

• Date and time
• Symptoms
• Recent changes
• Exact error from logs
• Fix applied
• Preventive step to take next

That small habit turns an emergency repair into an internal manual you can use later.

Common mistakes

Most prolonged outages come from process mistakes rather than the original fatal error. Avoid these traps.

Turning on full error display on a public production site

Logging errors is useful. Displaying them publicly is not. On production, prefer writing debug output to a log file rather than exposing paths, plugin names, and stack traces to visitors.

Editing live files repeatedly without a checkpoint

When the site is already down, rushed edits to functions.php, core files, or random plugin files can make the root cause harder to trace. Before editing, create a backup, a snapshot, or at least copy the original file locally.

Assuming the last visible change is the only cause

A plugin update may coincide with a PHP version change, a cache issue, or a server resource limit. Correlation helps narrow the search, but it does not prove the exact cause.

Reactivating everything at once after a recovery

This is one of the fastest ways to recreate the outage and lose the trail. Restore services in stages.

Ignoring mu-plugins, drop-ins, or custom snippets

Some of the most stubborn white screen cases come from code outside the normal plugin list, including must-use plugins, object cache drop-ins, code snippets managers, or custom includes loaded from the theme.

Skipping environment compatibility checks

When a plugin suddenly fails after months of stability, the real cause may be a server-level change. Always verify PHP version, memory, extensions, and permissions before blaming the application alone.

Not testing after cache is cleared

Cache can both hide and preserve errors. If you fix a fatal issue but keep serving cached broken output, the site may look unchanged. Purge all relevant layers after any substantial fix.

When to revisit

This guide is most useful when treated as a recurring maintenance checklist, not a one-time emergency read. Revisit it in these situations:

• Before major plugin, theme, or core updates. Confirm backups, staging, rollback steps, and logging access.
• Before a PHP version change. Compatibility issues are a common trigger for a WordPress site blank page problem.
• Before seasonal traffic peaks or campaign launches. Higher load can expose memory and plugin stability issues that stayed hidden under normal traffic.
• After changing hosts, DNS, SSL, or server configuration. Environment shifts often surface as application errors.
• Any time your workflow changes. New deployment tools, code snippet practices, page builders, or caching layers change your risk profile.

Practical action plan to save for later:

1. Create a staging site if you do not already have one.
2. Make sure backups run automatically and can be restored.
3. Store hosting, SFTP, SSH, and control panel access in a secure team-accessible place.
4. Keep a default WordPress theme installed for emergency fallback.
5. Know where PHP and WordPress logs live on your host.
6. Test plugin and theme updates in batches instead of all at once.
7. Document your standard recovery order: plugins, theme, logs, memory, core files, environment.

If your team handles WordPress across multiple environments, this checklist works best when turned into an internal runbook. The more consistent your process, the less time you spend staring at a blank screen with no clue where to begin.

In short, the best WordPress white screen fix is rarely a single trick. It is a controlled sequence: isolate scope, disable likely failure points safely, verify with logs, restore service carefully, and record what changed. That approach works across shared hosting, managed WordPress platforms, VPS setups, and custom stacks because it is built around diagnosis rather than guesswork.