A blank page can be an empty successful response, a PHP fatal with error display disabled, an early exit, exhausted memory or HTML hidden by front-end code. The browser colour alone does not identify the layer.
Inspect status, headers and response body before enabling visible errors. Production visitors should never see filesystem paths or stack traces.
Check the actual HTTP response
Open browser Network tools or use an authorised HTTP client. Record status code, content type, response length, redirect chain and cache headers.
Blank response patterns:
500 with empty body -> server/PHP failure
200 with zero bytes -> early exit or suppressed fatal
200 with HTML -> CSS/JavaScript/display issue
3xx loop -> URL/HTTPS/cookie problemTest a CSS/image asset and wp-login.php to define the boundary.
View the raw response
Use “View source” or inspect the response body. If markup exists, disable browser extensions and inspect CSS such as white text, hidden containers or a full-screen overlay.
If the raw body ends abruptly, note the last rendered template section. That can locate the hook or shortcode executing when PHP stopped.
Do not edit design CSS before proving that the server returned complete HTML.
Read PHP and server logs
Match the request timestamp with PHP-FPM, Apache/Nginx and WordPress logs. Look for fatal errors, memory exhaustion and uncaught exceptions.
Enable WP_DEBUG_LOG with WP_DEBUG_DISPLAY false only when existing logs are insufficient:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Remove temporary logging after diagnosis and protect the log from public download.
Check memory and execution limits
Memory exhaustion can produce a blank response if errors are hidden. Record allowed memory, attempted allocation, file and line.
Do not raise the limit without inspecting the consumer. A loop or unbounded query will use the new ceiling.
For timeouts, compare PHP maximum execution time with reverse-proxy limits and identify the task that stalled.
Isolate plugins and theme narrowly
If the fatal names a plugin, rename only its directory. If no log is available, test on staging or rename the plugins directory with a documented reactivation order.
Remember that must-use plugins load separately from the normal plugins directory and can continue causing the blank response.
For a theme issue, ensure a compatible default theme is present. A missing fallback can leave WordPress unable to render anything.
Do not edit parent theme or plugin files as the permanent fix.
Find early termination and output buffering
Search custom code for exit, die, output-buffer cleanup and maintenance logic around the affected route. A security or staging guard may deliberately return no content.
if ( ! defined( 'ABSPATH' ) ) {
exit;
}This guard is normal at direct file access; the defect is when similar logic triggers during a legitimate WordPress request.
Check incomplete or wrong files
An interrupted update, failed restore or disk/inode limit can leave zero-byte or missing PHP files. Compare trusted package checksums and recent modification times.
Reinstall the exact official component after backup. Preserve uploads and configuration, and confirm filesystem ownership before another update.
Clear OPcache so PHP does not keep stale compiled code.
Verify every affected path
Test homepage, posts, login, administrator, editor, media and the original URL. Inspect logs for new fatals and test as both anonymous and logged-in user.
Recurring care should alert on empty HTML responses as well as non-200 status codes. A white screen is resolved only when the underlying request completes predictably, not when a cached page temporarily appears.