Your WordPress site is a blank white page. Start here

You open your website and there is nothing there. No header, no menu, no message, a white page. Or there is one line of text saying the site has had a critical error, and nothing else. You try your phone, then the WordPress login, and get the same.

Take a breath. In nearly all the cases we see, nothing has been deleted. Your pages, your orders and your images are all still on the server. One piece of code has failed and stopped the rest of the page being built, and the job for the next hour is to find out which one.

What the white screen means

WordPress builds each page on the fly, using a programming language called PHP. When a piece of PHP hits an error it cannot recover from, it stops dead. A live site is set up not to show visitors the error, because error messages can give away things an attacker would like to know, so what you see is the nothing that was built before it stopped.

Newer versions of WordPress catch some of these and show “There has been a critical error on this website” instead of a blank page. It is the same fault with a politer face. WordPress also emails the site’s admin address when this happens, with a subject line about a technical issue and a special link that lets you log in with the broken plugin paused. Check that inbox, spam folder included, before you do anything else. That email often names the plugin for you.

The usual causes

Three things account for most of the white screens we are asked to look at.

• An update. A plugin or theme updated, by hand or automatically overnight, and the new version clashes with something else on the site. If the site broke within a day of an update, start there. Our post on whether to click “update all” covers why this happens and how to make it less likely.
• Running out of memory. Each page view gets a fixed allowance of server memory. A heavy page builder, a big import or a shop with a lot of products can go over it, and PHP stops. The error for this one says “Allowed memory size exhausted”.
• A PHP version change at the host. Hosts retire old versions of PHP from time to time and move sites onto newer ones. A plugin last updated five years ago may use parts of PHP that no longer exist. If nothing changed on your side and the site broke anyway, this is the likely culprit, and your host may have sent an email about it weeks ago.

Rule out the easy things first

Spend five minutes on these before you open any files.

Check whether the whole site is down. Try the home page, an inner page and /wp-admin/. If the public pages work and only the admin is white, a caching plugin may be serving visitors old copies of the pages, which buys you time. If the home page alone is broken, the fault sits in something that runs on that page only, such as a slider or a homepage block.

Try a private browser window. A stale copy in your own browser can make a fixed site look broken, and a broken one look fixed.

Ask what changed. An update, a new plugin, a host email, a developer making changes last night. The answer to that question solves more white screens than any tool.

Find the error

WordPress can write its errors to a file instead of throwing them away. You need access to the site’s files for this, through SFTP or the file manager in your hosting control panel.

Open wp-config.php in the main folder of the site. Above the line that says “That’s all, stop editing”, add these three lines:

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

Load the broken page again, then look in the wp-content folder for a file called debug.log. Near the bottom will be a line starting “PHP Fatal error”. It names a file, and the file’s path tells you who wrote it. A path containing wp-content/plugins/some-plugin/ points at that plugin. One containing wp-content/themes/ points at your theme.

Many hosts also keep a PHP error log of their own in the control panel, which gives you the same line without touching wp-config.php.

When you have finished, take those three lines out again and delete debug.log. Left in place, that file can be read by anybody who guesses its address, and it records details about your site you would rather keep to yourself.

Switch a plugin off without the dashboard

If the error names a plugin, you can switch it off without logging in. In wp-content/plugins, rename that plugin’s folder, for example from some-plugin to some-plugin-off. WordPress can no longer find it, so it stops loading it. Reload the site.

If you have no error to go on, rename the whole plugins folder to plugins-off. That switches every plugin off at once. If the site comes back, looking plain, a plugin was the cause. Rename the folder back, then switch plugins off one at a time from the dashboard until it breaks again.

Themes work the same way. Rename the active theme’s folder in wp-content/themes and WordPress falls back to one of its default themes, provided one is still installed. The site will look wrong, but if it loads, you know where the fault is.

For a memory error, add this line to wp-config.php alongside the others:

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

Some hosts set a ceiling lower than that and ignore the line, in which case the host has to raise it.

For a PHP version problem, most control panels let you switch the site back to the previous version. Treat that as a stopgap for a week or two. The old version is being retired for a reason, and the real fix is updating or replacing the plugin that cannot cope.

When to stop and restore

Give yourself an hour. If by then you cannot find the error, or the error points somewhere you do not recognise, or every change seems to make things worse, stop making changes. Each one you make is something else to undo later.

Restore the backup taken before the site broke. Two things to check before you press the button:

• Restore files and database together if the update that caused this also changed the database. Big plugins such as WooCommerce often do. Putting the old files back over a database the new version has already changed can leave you with a second fault.
• Think about what has happened since the backup. On a shop, orders placed after the backup was taken disappear when you restore. Note them down first.

This is where a lot of owners find out what their backups are worth. A backup you have never restored from is a hope, and our post on what website backups should do covers how to test one before the day you need it.

Getting back to normal

A white screen is one of the most alarming things a website can do, and one of the more fixable ones. Most come down to a single plugin, a memory limit or a PHP change, and most are back up within the hour once somebody reads the error.

If you would rather that somebody was not you, sites on our Care & Hosting plan get their updates tested before they go live, backups that are checked by restoring them, and a person to ring when something goes white anyway. It is £49 a month, and we move your site across for free.