Blank White Page: Finding the Error PHP Decided Not to Show You

A blank white page is not a missing page — it is an error message that was suppressed. PHP hit a fatal error, stopped executing before it printed anything, and display of errors was switched off, so the browser received a valid response with nothing in it.

That framing is the whole fix. You are not looking for a broken template; you are looking for a message that already exists and is being hidden. Turn it back on, or find where it was written down, and the problem usually names itself in one line.

Table of contents

• Why the page is blank rather than an error
• Read the log first
• Turning the message on, for WordPress
• The four usual causes, in order
• Making the next one cheaper
• How this fits the rest of the stack
• FAQ

Why the page is blank rather than an error

Three things have to line up for a truly white page.

1. PHP hits a fatal error — a call to a function that does not exist, a memory limit reached, a syntax error in a file it just loaded.
2. Execution stops immediately. Nothing further is output, and whatever partial page had been buffered is discarded.
3. display_errors is off, which it should be on any production server, so the message goes to a log rather than the browser.

The result is HTTP 200 with an empty body. Note the status code: the server thinks it succeeded. That is why uptime monitors that only check for a 200 response cheerfully report the site as healthy while every visitor sees nothing.

Modern PHP and modern WordPress often catch this and show a plain there has been a critical error on this website page instead, sometimes with a link. That is the same failure with better manners. If you are seeing genuinely nothing, either the error happened too early for the handler to run, or the handler itself is what broke.

Browsers differ slightly in how they render an empty response, which is why the same broken site can look white in one browser and show a small error in another. That is cosmetic — the underlying failure is identical.

Read the log first

Before changing any configuration, look for the message that was already written. It exists somewhere, and it usually names the file and line.

• The PHP error log, whose location depends on the host. Common paths are /var/log/php-fpm/, /var/log/apache2/error.log, /var/log/nginx/error.log, or a error_log file dropped in the site directory.
• The web server error log, which catches things PHP could not log itself.
• Your host’s log viewer, if there is one in the control panel — usually the fastest route.
• wp-content/debug.log on WordPress, if debug logging was already enabled.

Search the log around the timestamp when the page went blank. A fatal error line names the error, the file and the line number, and that is normally the entire diagnosis. Allowed memory size of X bytes exhausted and Call to undefined function account for a large share of cases.

If the logs are empty or unreachable, then turn error display on temporarily — and only temporarily, because the messages can expose file paths and configuration to anyone visiting.

Turning the message on, for WordPress

Edit wp-config.php, above the line that says to stop editing, and add:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );   // write to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // do NOT print to the browser
@ini_set( 'display_errors', 0 );

This combination is the one to use on a live site: the error is captured to a file you can read, and visitors still see nothing revealing. Reload the broken page once, then read wp-content/debug.log.

Set WP_DEBUG_DISPLAY to true only on a site nobody else is using, and turn all of it back off when finished. Leaving debug logging on indefinitely grows a large file and can record more than you want kept.

If wp-config.php itself is the problem — a stray character after the closing tag, a syntax error from a bad edit — nothing will load at all, including the admin. That case is diagnosed by looking at the file rather than the log.

The four usual causes, in order

1. Memory exhausted. The log says Allowed memory size ... exhausted. Raise the limit as a diagnostic — define( 'WP_MEMORY_LIMIT', '256M' ); — but treat a site that needs ever-increasing memory as a symptom. Something is loading far more than it should, usually a plugin.
2. A plugin conflict or a bad plugin update. The classic. If you can reach the admin, deactivate everything and re-enable one at a time. If you cannot, rename wp-content/plugins to plugins-off over SFTP or a file manager, which deactivates all of them at once, then rename it back and re-enable individually.
3. A theme error. Same technique — rename the active theme’s directory and WordPress falls back to a default theme. If the site returns, the theme is the culprit, and it is often a customisation made directly to a parent theme.
4. A PHP version mismatch. The host upgraded PHP and something in your stack uses syntax or functions that were removed. The log names the function. This one arrives without you changing anything, which makes it confusing.

A fifth, less common but worth knowing: a partially completed update. If the page went blank during an update, files may be half-replaced. Reinstalling core from Updates then Reinstall Now, or re-running the plugin update, usually resolves it.

The diagnostic order that wastes least time: read the log, and only if there is no log do the rename-plugins dance. People often start with the dance because it is the advice they find first, and it takes an hour to arrive at something the log would have said immediately.

Making the next one cheaper

• Monitor content, not status codes. A check that only looks for HTTP 200 will not notice this at all. Assert that a known string appears in the page body.
• Keep logs reachable without SFTP. The moment you need them is the moment the site is down and you are on a phone. A log viewer in a dashboard beats hunting for credentials.
• Update one plugin at a time, with a backup taken immediately before. Batch updates are the single most common cause of the version of this that happens during maintenance.
• Have a staging copy for anything business-critical, so plugin and PHP upgrades break there rather than in production.
• Know your rollback. For files, the previous version. For anything that ran a database migration, the pre-update backup is the only route back.

And treat memory limits as a signal rather than a dial. Raising the limit makes the blank page go away, and if the underlying cause is a plugin loading an entire table into memory, you have bought time rather than fixed anything.

How this fits the rest of the stack

Nearly every step above is easier when the logs are somewhere you can read them without hunting for SFTP credentials during an outage. The RunxBuild hosting calculator covers what the site costs to run alongside the rest of the stack. RunxBuild managed WordPress puts a file manager and a database browser in the dashboard — rename a plugin directory, read a debug log, edit wp-config or inspect a table from the browser — and services keep build and runtime logs together per deploy with one-action rollback.

Useful related references:

• PHP Show All Errors: Why the Page Is Blank and How to Fix It
• WordPress Hosting for Agencies: White-Label, Multi-Site, and the Reseller Model
• WordPress Blog Pagination: Posts Per Page, and Why Page 2 Is Empty
• Services on RunxBuild

FAQ

What causes a blank white page on a website?

A fatal PHP error that stopped execution before anything was printed, combined with error display being switched off — which is correct for production. The response is HTTP 200 with an empty body, which is why uptime monitors that only check status codes report the site as healthy.

How do I see the error behind a white screen?

Read the log first — the message already exists, naming the file and line. Check the PHP error log, the web server error log, or your host’s log viewer. If there is nothing there, enable WP_DEBUG with WP_DEBUG_LOG true and WP_DEBUG_DISPLAY false so the error is captured to a file without being shown to visitors.

How do I fix a white screen if I cannot access wp-admin?

Rename wp-content/plugins to something else over SFTP or a file manager, which deactivates every plugin at once. If the site returns, rename it back and re-enable plugins one at a time to find the culprit. The same technique works on the active theme’s directory.

Is raising the PHP memory limit the right fix?

As a diagnostic, yes. As a permanent fix, usually not. A site that needs ever-increasing memory has something loading far more than it should — typically a plugin pulling an entire table into memory. Raising the limit buys time rather than solving it.

Why did my site go blank without me changing anything?

Most often a host-side PHP version upgrade that removed a function something in your stack still calls, or an automatic plugin update. The error log names the function or file. This is also why staging copies matter for anything business-critical.