WordPress Shows a Blank White Page: 7 Ways to Find What Actually Broke

You open your WordPress website and see nothing.

No menu. No content. No obvious error message. Sometimes the entire page is completely white. In other cases WordPress displays a message such as:

There has been a critical error on this website.

This problem is commonly called the WordPress White Screen of Death, but the name can be misleading.

A blank page is not the actual problem. It is only the visible result of something preventing WordPress from completing the request.

The real cause could be completely different from one website to another.

• A plugin may be causing a fatal PHP error.
• The active theme may contain incompatible code.
• PHP may have run out of memory.
• A PHP version change may have broken old code.
• A WordPress update may have stopped halfway through.
• Core files may be missing or corrupted.
• The web server may be hiding the real error.

That is why randomly reinstalling WordPress or deleting plugins is the wrong place to start.

PRBLEM Principle: A blank screen gives us almost no information. Our first job is not to fix it. Our first job is to make the hidden failure visible.

---

Before You Touch Anything

Do not begin by deleting files.

If your hosting provider offers backups, check whether a recent backup exists before making changes.

You should ideally have access to at least one of the following:

• WordPress administrator dashboard
• Hosting File Manager
• FTP or SFTP
• Hosting error logs
• phpMyAdmin

If wp-admin is also blank, do not worry. Most of the diagnostic methods in this guide can be performed without logging in to WordPress.

Do not do these things yet

• Do not delete the database.
• Do not reinstall everything from scratch.
• Do not change every file permission to 777.
• Do not delete the entire plugins folder.
• Do not remove your theme permanently.
• Do not restore an old backup before identifying what happened if the current data matters.

Most blank-screen problems can be diagnosed without destructive changes.

---

First Question: Where Is the White Screen?

The location of the blank page is one of our strongest diagnostic clues.

Case A: The entire website and wp-admin are blank

This often points toward a global PHP problem, plugin failure, theme failure, memory exhaustion, incomplete update or damaged WordPress files.

Case B: The frontend is blank but wp-admin still works

The active theme becomes more suspicious because WordPress administration can still load while frontend rendering fails.

Case C: wp-admin is blank but the website still works

This suggests code that runs specifically inside the administration area, a plugin conflict, admin-specific memory usage or a failed request used by the dashboard.

Case D: Only one page is blank

Do not treat this as a full WordPress failure.

The problem may be limited to:

• A shortcode
• A block
• A page template
• A plugin function
• A specific PHP query
• A custom field
• A page builder component

PRBLEM Diagnosis: The smaller the affected area, the less likely it is that WordPress itself is completely broken.

---

Method 1: Check WordPress Recovery Mode First

Modern versions of WordPress include a built-in Recovery Mode that can help when WordPress detects a fatal PHP error.

When this happens, WordPress may send an email to the administrator email address configured for the site.

Check the inbox and spam folder for an email related to a technical problem on your WordPress site.

The email may identify the plugin or theme involved and include a special Recovery Mode login link.

If you receive the Recovery Mode email

Use the recovery link and log in.

WordPress may temporarily pause the faulty plugin or theme for your administrator session, allowing you to enter wp-admin.

Once inside, do not immediately assume the problem is permanently fixed.

Look for information about the component that caused the fatal error.

Then investigate whether the component:

• Needs an update
• Was just updated
• Requires a newer PHP version
• Is incompatible with another plugin
• Contains custom modifications

If no Recovery Mode email arrives, continue with the next method. The absence of an email does not prove that no PHP error occurred.

---

Method 2: Make the Hidden PHP Error Visible

A completely white page often appears because PHP encountered an error but the server is configured not to display that error to visitors.

This is normally good for security, but it makes troubleshooting difficult.

Instead of displaying errors publicly, we can tell WordPress to write them to a log file.

Step 1: Open wp-config.php

Open your hosting File Manager or connect using FTP/SFTP.

Open the folder containing your WordPress installation.

You should see files and folders such as:

wp-admin
wp-content
wp-includes
wp-config.php
wp-login.php

Before editing wp-config.php, download a copy of the file or create a backup.

Step 2: Find WP_DEBUG

Search for a line similar to:

define( 'WP_DEBUG', false );

Change the debugging configuration to:

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

Place these settings before the line that says:

/* That's all, stop editing! Happy publishing. */

If the constants already exist, edit the existing definitions instead of adding duplicates.

Important: Do not create two different WP_DEBUG definitions in the same file.

Step 3: Reproduce the error

Save the file and open the broken page again.

Then check:

/wp-content/debug.log

If the file exists, open it and look near the bottom for recent errors.

You may see something similar to:

PHP Fatal error: Uncaught Error: Call to undefined function...

or:

PHP Fatal error: Allowed memory size of ... bytes exhausted

or:

PHP Parse error: syntax error, unexpected token...

How to read the important part

You do not need to understand the entire error.

Start by finding the file path.

For example:

/wp-content/plugins/example-plugin/includes/example.php

This tells us the failure occurred inside a file belonging to:

example-plugin

That does not automatically prove the plugin itself is badly written. Another plugin, PHP version change or missing dependency could have caused the code path to fail.

But we now have a real suspect instead of a blank screen.

---

Method 3: Disable Plugins Without Access to wp-admin

If the error appeared after installing or updating a plugin, plugin isolation should be one of your first tests.

You do not need access to the WordPress dashboard to disable plugins.

Option A: Disable one suspected plugin

Using File Manager or FTP, open:

/wp-content/plugins/

Imagine the suspected plugin folder is:

example-plugin

Rename it temporarily to:

example-plugin-disabled

Now reload the broken website.

What the result means

If the site starts working: the renamed plugin is involved in the failure.

If the site remains blank: restore the original folder name and continue investigating.

Do not permanently delete the plugin folder yet.

Option B: Disable all normal plugins temporarily

If you do not know which plugin is responsible, rename:

/wp-content/plugins

to something such as:

/wp-content/plugins-disabled

Then reload the website.

If WordPress suddenly works, at least one normal plugin is involved.

Rename the folder back to:

plugins

Then test individual plugins rather than deleting anything.

Use the half-split method when you have many plugins

If twenty or thirty plugins are installed, testing every plugin one by one is unnecessarily slow.

20 plugins
    ↓
Disable 10
    ↓
Test the site

Site works?
YES → suspect is inside the disabled group
NO  → suspect is probably inside the active group

    ↓
Split the suspicious group again
    ↓
Repeat

This quickly reduces the number of possible causes.

What if disabling the plugin fixes it?

You now have several possible solutions:

• Update the plugin to a compatible version.
• Roll back the plugin if the failure started immediately after an update.
• Check whether the plugin supports your current PHP version.
• Check for a conflict with another plugin.
• Replace the plugin if development has been abandoned.
• Send the exact fatal error to the plugin developer.

PRBLEM Diagnosis: “Disabling the plugin fixed it” identifies the component. The debug log usually tells you why that component failed.

---

Method 4: Check Whether the Active Theme Is Broken

If plugins are not responsible, the active theme becomes the next major suspect.

This is especially likely when:

• The frontend is blank but wp-admin still works.
• You recently edited functions.php.
• You added custom PHP code to the theme.
• The theme was recently updated.
• PHP was recently upgraded.
• The problem appeared immediately after changing themes.

If wp-admin still works

Go to:

Appearance → Themes

Temporarily activate a standard WordPress theme that you already have installed.

Then test the frontend again.

If the site starts working, the previous theme or theme customization is involved.

If wp-admin does not work

First confirm that another working theme is installed.

Then open:

/wp-content/themes/

Find the active theme folder.

For example:

my-theme

Rename it temporarily:

my-theme-disabled

If a valid fallback theme is installed, WordPress may switch away from the unavailable theme.

Reload the site.

If the blank screen disappears, investigate the original theme before activating it again.

Did you edit functions.php?

A single missing character can cause a PHP parse error.

For example, broken code like this:

function prblem_example() {
    echo 'Hello';

is missing the closing brace:

}

If the problem appeared immediately after editing PHP, undo the most recent modification first.

Do not keep changing unrelated files.

---

Method 5: Check PHP Memory and PHP Version

Sometimes the plugin or theme is not fundamentally broken. PHP simply cannot complete the request under the current environment.

Problem A: PHP memory exhaustion

If the debug log contains text similar to:

Allowed memory size of ... bytes exhausted

PHP ran out of memory while processing the request.

This can be caused by:

• A memory-intensive plugin
• A plugin loop
• A huge database operation
• Large image processing
• A page builder operation
• Too many plugins performing work simultaneously

Possible temporary test

You can define a WordPress memory target in wp-config.php:

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

This does not guarantee that your hosting provider will allow WordPress to use that amount of memory.

The server-level PHP memory limit can still be lower.

If increasing the limit makes the site work, do not automatically consider the investigation finished.

Important: A higher memory limit can hide inefficient code. Find out why the request needs excessive memory if the problem returns.

Problem B: The PHP version changed

This is a common cause when a website suddenly fails even though nobody intentionally changed WordPress.

A hosting provider may upgrade PHP, or you may have changed the PHP version from the hosting panel.

Old themes and plugins may contain code that no longer works correctly under the newer version.

Check your hosting panel for the current PHP version.

Then ask:

• Did the problem begin immediately after a PHP version change?
• Does the debug log reference an old plugin or theme?
• Does the plugin developer state that your PHP version is supported?

Possible solutions

• Update the incompatible plugin or theme.
• Replace abandoned software.
• Temporarily return to the previously working supported PHP version while fixing compatibility.
• Contact the developer with the exact PHP error.

Do not remain permanently on an outdated, unsupported PHP version just because old code requires it.

---

Method 6: Check for an Interrupted WordPress Update

Did the blank screen appear immediately after updating WordPress, a plugin or a theme?

If so, the update may not have completed correctly.

Check for a stuck maintenance file

Open the main WordPress directory using File Manager or FTP.

Look for:

.maintenance

This is a hidden file, so your File Manager may require you to enable an option such as:

Show Hidden Files

If an update ended abnormally and WordPress remains stuck in maintenance mode, removing the leftover .maintenance file can restore normal operation.

However, if core files were only partially updated, deleting this file will not repair those files.

Check whether files are missing

If the update connection failed halfway through, files inside these directories may be incomplete:

wp-admin
wp-includes

This can result in missing function errors, missing class errors or completely blank responses.

Safe core-file repair

Download a clean copy of the correct WordPress release from the official WordPress website.

A core repair should preserve:

• wp-config.php
• The entire wp-content directory
• Your database

The goal is to replace WordPress core files, not your uploads, themes, plugins or configuration.

Do not do this blindly: Never overwrite wp-content while attempting a simple WordPress core repair.

---

Method 7: Look Below WordPress at the Server Layer

If plugins, themes and WordPress core appear normal, the blank response may originate below WordPress itself.

This is where many troubleshooting guides stop too early.

A blank page can also happen when the web server or PHP handler fails before WordPress can properly report the error.

Check the hosting error log

Most hosting control panels provide access to one or more error logs.

Look for sections called:

• Error Log
• PHP Errors
• Raw Logs
• Apache Error Log
• Nginx Error Log
• Application Logs

Reload the broken page and immediately inspect the newest log entries.

You may find errors that WordPress itself could never log because execution stopped before WordPress was fully loaded.

Look for HTTP status codes

A page that looks visually blank may still return an important HTTP status code.

Common examples include:

• 500 — server-side execution error
• 502 — gateway or upstream PHP problem
• 503 — service temporarily unavailable or overloaded
• 504 — upstream process timed out

If you see one of these codes, the problem may extend beyond WordPress application code.

Check resource limits

Open your hosting resource monitor if one exists.

Look for:

• CPU limits
• Memory limits
• PHP worker limits
• Entry process limits
• Disk I/O limits
• Storage space exhaustion

A server with no free disk space, for example, can create strange failures because WordPress, PHP or the database may be unable to write temporary data.

Check file permissions carefully

Incorrect permissions can prevent PHP or the web server from reading required files.

However, do not attempt to solve permission problems by setting everything to:

777

This can create serious security problems and may not solve an ownership issue anyway.

If permissions or file ownership appear incorrect, use your hosting provider’s recommended WordPress permission configuration or ask support to correct ownership.

---

Special Case: Only One WordPress Page Is Blank

If the rest of the website works, do not disable the entire installation immediately.

Investigate what is unique about the broken page.

Check the page content

Ask whether the page contains:

• A unique shortcode
• A custom Gutenberg block
• A page builder widget
• Custom PHP
• A form
• An embedded external service
• A custom template

Duplicate the page and remove suspicious components one at a time.

If removing one component restores the page, you have isolated the failing path without affecting the rest of the site.

---

Special Case: The Site Is Blank Only for Logged-In Users

This changes the investigation significantly.

If logged-out visitors can see the website but administrators see a blank page, investigate code that runs only for authenticated users.

• Admin toolbar extensions
• Membership plugins
• User-role plugins
• Security plugins
• Dashboard customizations
• Logged-in cache exclusions
• Custom user-specific PHP code

PRBLEM Diagnosis: Different behaviour for logged-in and logged-out visitors usually means the application is taking a different code path. That difference is valuable evidence.

---

Special Case: The Problem Started After Adding a Code Snippet

Custom snippets can break WordPress just as easily as plugins or themes.

If you added PHP immediately before the failure, reverse that change before investigating unrelated components.

Common mistakes include:

• Missing semicolon
• Missing closing brace
• Calling a function that does not exist
• Declaring the same function twice
• Using code written for another PHP version
• Calling a plugin function before the plugin has loaded

For example:

function prblem_message() {
    echo 'Hello World'
}

The missing semicolon after 'Hello World' can cause a parse error.

The corrected version is:

function prblem_message() {
    echo 'Hello World';
}

If the snippet was added through a snippet-management plugin, use Recovery Mode if available and disable that snippet first.

---

The Fastest Diagnostic Route

If you want the shortest practical troubleshooting path, follow this order.

Blank WordPress page
        ↓
Check admin email for Recovery Mode
        ↓
Enable safe error logging
        ↓
Read wp-content/debug.log
        ↓
Does the error point to a plugin?
        ↓
 YES → Disable/test that plugin
 NO
        ↓
Does it point to the theme?
        ↓
 YES → Switch/test theme
 NO
        ↓
Memory or PHP compatibility error?
        ↓
 YES → Fix environment / incompatible code
 NO
        ↓
Did an update just occur?
        ↓
 YES → Check maintenance state and core files
 NO
        ↓
Inspect hosting/server error logs
        ↓
Check resource limits and PHP handler

This approach is much safer than randomly deleting components because each action is based on evidence from the previous step.

---

Three Different Solution Paths

Solution Path 1: Application-Level Failure

Use this path when the debug log points to a plugin, theme or custom snippet.

1. Disable the affected component.
2. Confirm that WordPress loads again.
3. Update the component if a compatible update exists.
4. Check PHP compatibility.
5. Test for conflicts with other plugins.
6. Replace abandoned components when necessary.

Solution Path 2: PHP Environment Failure

Use this path when the log reports memory problems, undefined PHP functions, deprecated/incompatible syntax or environment-related errors.

1. Check the current PHP version.
2. Check the hosting PHP memory limit.
3. Identify which component triggers the error.
4. Update incompatible software.
5. Temporarily use a compatible supported environment if required for recovery.
6. Move back toward a current supported PHP environment after the incompatible code is fixed.

Solution Path 3: WordPress or Server-Level Failure

Use this path when plugins and themes are not responsible.

1. Check whether an update was interrupted.
2. Inspect WordPress core files.
3. Check hosting error logs.
4. Check disk space and resource limits.
5. Check PHP-FPM or server-level failures with your host.
6. Repair WordPress core files if evidence indicates corruption.

---

How to Verify That the Problem Is Really Fixed

Do not stop after seeing the homepage once.

Test the parts of WordPress that exercise different systems.

• Open the homepage while logged out.
• Open several posts and pages.
• Log in to wp-admin.
• Open Posts.
• Edit a post.
• Save the post.
• Open Media Library.
• Open Plugins.
• Test forms.
• Test login and logout.
• Test checkout if the site uses e-commerce.

Then inspect the newest debug log entries again.

A site that visually loads but continues generating fatal errors is not fully repaired.

---

Turn Debug Mode Back Off

After troubleshooting a production site, do not leave WordPress debugging enabled unnecessarily.

Return the configuration to your normal production settings.

For example:

define( 'WP_DEBUG', false );

If you manually added temporary debugging definitions, clean them up carefully so that duplicate constants are not left in wp-config.php.

---

If the Site Is Still Blank

If none of the previous methods reveal the cause, collect evidence before contacting your hosting provider or developer.

Record:

• The exact time the failure occurred
• The URL that fails
• Whether wp-admin works
• Whether logged-out visitors are affected
• The current PHP version
• The newest debug.log error
• The newest server error-log entry
• The last plugin, theme or WordPress update performed
• Whether disabling plugins changed the result
• Whether switching themes changed the result

Instead of telling support:

My WordPress site is broken.

you can now provide something much more useful:

The frontend returns a blank page while wp-admin is also unavailable. Disabling the normal plugins does not change the result. The failure began after a PHP version change, and the server error log reports a fatal error at the same time as the request.

That information can dramatically shorten the troubleshooting process.

---

Quick Recovery Checklist

• Check whether the entire site or only one area is blank.
• Check the WordPress administrator email for Recovery Mode.
• Enable safe WordPress error logging.
• Inspect wp-content/debug.log.
• Identify the file path mentioned in fatal errors.
• Temporarily disable the suspected plugin.
• Test the active theme.
• Check for PHP memory exhaustion.
• Check whether PHP was recently changed.
• Check for an interrupted update.
• Look for a leftover .maintenance file.
• Verify WordPress core files if necessary.
• Inspect server-level error logs.
• Check CPU, memory, PHP worker, disk and storage limits.
• Test the website again after every change.
• Disable temporary debugging after the investigation.

---

Final Diagnosis

A WordPress white screen is not a diagnosis.

It is the absence of a visible diagnosis.

Your goal is to determine which layer stopped WordPress from completing the request.

Plugin or theme layer: A component triggers a fatal error or incompatible code path.

PHP layer: Memory, PHP compatibility or execution problems prevent WordPress from finishing.

WordPress layer: An interrupted update or damaged core file prevents normal loading.

Server layer: The web server, PHP handler, resource limits, permissions or storage system fails before WordPress can produce a normal response.

The most important troubleshooting step is therefore not reinstalling WordPress.

It is turning the invisible failure into evidence.

PRBLEM Principle: Do not fight the white screen. Find the error hidden behind it, identify the layer that produced it, change one thing at a time, and verify the result.