WordPress Page Is Blank With No HTML: How to Find and Fix the Cause

This article is a localized edition of the Japanese original. Read the Japanese original

When a WordPress page goes completely white and "View page source" in the browser shows almost no HTML, PHP has usually stopped partway through. With the PHP setting that hides errors from the screen (the normal setting on production servers), you are left with only a white screen and no visible error.

This article does not guess at fixes. It walks through finding the cause by reading the error records.

Check the current state first

Look at the HTTP status

Even when the screen is white, the status the server returns tells you where to look. Check it in the "Network" tab of the browser's developer tools, or with curl.

# Show only the response headers (replace example.com with your site)
curl -I https://example.com/

Check for the “critical error” message and email

WordPress 5.2 and later has fatal error protection (recovery mode). When a fatal PHP error occurs, you see "There has been a critical error on this website." instead of a blank white screen. At the same time, an email goes to the site admin email address with the name of the plugin or theme that caused it and a link for logging in to recovery mode.

If you received the email, log in through the link and deactivate the plugin or theme it names. If no email arrived, or the screen really is blank, move on to checking the error logs below.

Read the error records

Turn on the WordPress debug log

Open wp-config.php over FTP or with a file manager, and add the following lines before the line /* That's all, stop editing! Happy publishing. */. If there is already a define( 'WP_DEBUG', false ); line, change that line instead (defining the same constant twice produces a warning).

<?php
// Turn on debugging
define( 'WP_DEBUG', true );
// Write errors to wp-content/debug.log
define( 'WP_DEBUG_LOG', true );
// Do not show errors on screen (so visitors do not see internal details)
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

After saving, open the blank page again. New entries are added to wp-content/debug.log, so look for a PHP Fatal error line near the end.

PHP Fatal error:  Uncaught Error: Call to undefined function example_function() in /var/www/html/wp-content/plugins/example-plugin/example.php:25

In this example, line 25 of example.php in the example-plugin plugin is the cause. The plugins/plugin-name or themes/theme-name part of the path tells you which plugin or theme it is.

By default, debug.log is created in a location that can be opened from a browser. Once you find the cause, revert the lines above (set WP_DEBUG to false) and delete debug.log.

Read the server error log

If nothing is written to debug.log, the error happens before WordPress loads (a mistake in wp-config.php, for example) or outside WordPress (.htaccess, PHP settings). Check the server error log.

• Shared hosting: the "Error log" or "Access statistics" menu in the control panel
• Apache (Debian / Ubuntu): /var/log/apache2/error.log
• nginx: /var/log/nginx/error.log (PHP-FPM keeps its own log in a separate file)

# Show the last 50 lines (adjust the path to your server)
sudo tail -n 50 /var/log/apache2/error.log

Isolate the cause

If the error logs do not reveal the cause, or you cannot get into the admin screen, isolate it by taking plugins and the theme out one at a time.

Stop all plugins

Rename the wp-content/plugins folder over FTP to something like plugins_off, and no plugins are loaded. If the page now displays, a plugin is the cause.

If you open the Plugins screen in the admin while the folder is renamed, WordPress deactivates the plugins whose files it cannot find (a notice says the plugin has been deactivated due to an error). When you then rename the folder back to plugins, the plugins return to the list in a deactivated state. Activate them one at a time; the one that brings back the white screen is the cause.

If you suspect a specific plugin, rename only that plugin's folder (wp-content/plugins/plugin-name).

On servers where WP-CLI is available, you can do the same with commands.

# List active plugins without loading plugins or themes
wp plugin list --status=active --skip-plugins --skip-themes

# Deactivate all plugins
wp plugin deactivate --all --skip-plugins --skip-themes

# Deactivate only the suspect plugin (replace example-plugin with the real name)
wp plugin deactivate example-plugin --skip-plugins --skip-themes

Switch to a default theme

If stopping plugins does not help, suspect the theme. Rename the active theme's folder (wp-content/themes/theme-name) and then open Appearance → Themes in the admin. WordPress treats the theme as broken and switches to an installed default theme (Twenty Twenty-Five, for example). It cannot switch if no default theme is installed, so in that case upload a default theme from WordPress.org to wp-content/themes over FTP first.

With WP-CLI, switch like this.

# Check the installed themes
wp theme list --skip-plugins --skip-themes

# Switch to a default theme (use a theme name from the list)
wp theme activate twentytwentyfive --skip-plugins --skip-themes

If you use a child theme, code you added to the child theme's functions.php may be the cause.

Common causes and fixes

Right after upgrading PHP

If an old plugin or theme uses functions or syntax removed in the newer PHP, it causes a fatal error. Update the plugin or theme named in the error log, or replace one that is no longer maintained. If you cannot fix it right away, temporarily switch the PHP version back in the server control panel and do the replacement in the meantime.

Running out of memory

If the log says Allowed memory size of ... bytes exhausted, PHP has hit its memory limit. You can raise the limit WordPress uses in wp-config.php (it cannot go above PHP's own memory_limit).

<?php
define( 'WP_MEMORY_LIMIT', '256M' );

If it keeps happening after raising the limit, isolate plugins to check whether one of them uses a large amount of memory.

A mistake in .htaccess

On an Apache server, if every page returns a 500 error, check .htaccess. The standard WordPress section looks like this (when WordPress is installed directly in the web root).

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

To isolate it, move .htaccess aside by renaming it to something like .htaccess_old, and check whether the front page displays. If it does, go to Settings → Permalinks in the admin and click "Save Changes" without changing anything; WordPress rewrites .htaccess (if it has permission to write the file). nginx servers do not use .htaccess.

File permissions and ownership

If the white screen started after moving files or changing server settings, check permissions. The usual values are 644 for files and 755 for directories.

# Run in the WordPress directory (replace /var/www/html with the real location)
cd /var/www/html
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Whether the owner should be the web server user (www-data, for example) depends on the server setup. On shared hosting you do not need to change the owner, and usually cannot.

An empty page left in the cache

If the status is 200 and the body is empty, a caching plugin or the server cache may have saved the empty page produced during the error. If the page stays white after you fix the cause, clear the cache and check again.

Cautions

• Before changing wp-config.php or renaming folders, copy the original files to your computer.
• Setting WP_DEBUG_DISPLAY to true lets visitors see file paths and other details in the errors. On a production site, investigate with errors written to the log, not shown on screen.
• When you are done, set WP_DEBUG back to false and delete debug.log.

Summary

• Check the HTTP status with curl -I or similar: for 500, read the error logs; for 200 with an empty body, suspect the theme or cache.
• Log errors to wp-content/debug.log with WP_DEBUG_LOG and identify the plugin or theme from the PHP Fatal error line. If nothing is logged, read the server error log.
• If you cannot get into the admin, isolate the cause by renaming folders or with WP-CLI's --skip-plugins --skip-themes.
• Once you find the cause, revert the debug settings.

Related articles:

• How to enable WordPress debug mode
• How to diagnose a blank WordPress front page
• How to fix the WordPress "Allowed memory size exhausted" error
• How to set up WordPress .htaccess correctly

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)