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.
A decision tree before changing the site
- No response body: record the HTTP status and time, then correlate server and PHP evidence. Empty HTML alone does not establish which component failed.
- HTML exists but the page looks blank: inspect the returned markup, browser errors, styles and overlays. Preserve the response before changing presentation.
- Public pages work but administration is blank: follow the administrator-only blank page diagnosis. A cached public page does not verify the administrator request.
- The request redirects or is denied: identify that response and its origin before treating it as a rendering failure.
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.
Our isolated HTTP exercise: the status is only one clue
On 24 October 2026 we served four original synthetic fixtures on a temporary loopback HTTP listener and read their responses. No WordPress site or production configuration was involved. The controlled observations were:
empty-success HTTP 200 0 bytes no HTML
empty-error HTTP 500 0 bytes no HTML
hidden-markup HTTP 200 90 bytes HTML present
maintenance HTTP 503 69 bytes HTML presentThe hidden-markup fixture contained a main element with display:none. The empty 200 and empty 500 had identical body lengths; the status differed. This exercise demonstrates response distinctions, not a WordPress root cause or a client repair. Reproduce those controlled status/body combinations in an isolated environment and inspect the raw response, rather than drawing the conclusion from a screenshot.
For a real incident, retain the original URL, time, status, body observation and matching log evidence. Follow WordPress debugging guidance when additional logging is needed, keeping errors off public screens.
Evidence to close a white-screen repair
Repeat the affected URL under the original visitor condition after the agreed correction. Confirm the intended content and response, the affected form or administrative task and the absence of the matching new error in the available logs. Record the change and any unverified routes. For WordPress white screen repair, provide that boundary and the recent change history so the scope can target the failing layer.