A completely white page in WordPress usually means that PHP has stopped running, but the error display is turned off; However, a cache empty response, bad compression output, or upstream error can also create a similar appearance. If it's just a white page, check the code or data of the same path. If site and wp-admin are both white, it's more likely a global plugin, template, bootstrap, or a PHP limitation.
Quick answer: Look at the status and size of the response in Network, find the PHP log at the same timestamp, and only test the component that the trace shows. Turning on the error display for visitors, accidentally removing plugins or increasing memory is not the way to detect.
First make sure you really have a "white response"
Browser DevTools or curl specifies that a 200 response with an empty body is received, a 500 is received, or a redirect to a blank page has occurred. Open the Network tab with Disable cache and see the status, content type, size and redirects. If the complete HTML arrives but the page doesn't show anything, there is a CSS or JavaScript error; This scenario is different from fatal PHP.
- Test a simple URL, login page and a static file separately.
- Test from another network or browser to detach the local cache.
- Record the start time and the last deploy, update or code modification.
- PHP-FPM disk space and health
log reveals hidden error
First, read the PHP-FPM log or the host panel. If you don't have access, enable temporary WordPress debug logging without public display:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Repeat the white request once and check the end of wp-content/debug.log. If the file is not created, see the path permission, custom constant WP_CONTENT_DIR and main PHP log. After diagnosis, return debug to normal setting.
Possible causes in order of action
Fatal error in plugin or template
Find the file name and the first related stack frame. If the manager doesn't open either, temporarily rename the suspect plugin folder. Dropping the entire plugins folder is just to limit the scope and should be followed by a phased activation. For the template, first make sure there is a healthy default template.
PHP running out of memory
message Allowed memory size exhausted shows the ceiling value and the stop location. Limited and proportional incrementing may restore access, but will not cure loops, large queries, or faulty image processing. Also measure the actual worker consumption and the number of simultaneous requests.
Incomplete file or version mismatch
Incomplete upload, aborted deploy or PHP change can remove required class/function. Checksum the core and match supported plugin and theme versions to PHP. Restore the core file from the official source and do not overwrite the content of the site.
Premature output or broken response
Custom code may be exit slow or output buffering and compression may interfere at different layers. Compare response size, headers and upstream log. Randomly turning off gzip on all layers without witnesses will only change the architecture.
Low-risk isolation path
- Take a current backup and a snapshot of the log.
- Choose a repeatable request.
- Temporarily sidestep the agent specified in the trace Leave it.
- If you don't have a trace, test the plugins and then the template step by step in staging.
- After the page returns, smoke test the login, form, cron and checkout paths.
- Replace the workaround with the stable fix or compatible version.
If the page is white only Sometimes seen
Intermittent failure is usually dependent on a particular worker, resource limitation, or input. Match the time of the failed request with the PHP-FPM log and the request ID and see if all errors occur on the same endpoint, user, or process. Checking the number of busy workers, timeout and database status is more useful than randomly increasing resources. If the load balancer has multiple backends, measure the response of each node separately; The healthiness of one node hides the failure of another node.
If white screen started after kernel upgrade, WordPress recovery after kernel update explains the difference between file and database. The 500 response is also discussed in the WordPress 500 Error Guide from the web server's perspective.
What not to do
- Enable
display_errorsfor users production. - Remove plugin or template without keeping version and settings.
- Use
chmod 777to hide ownership error. - Restore store database without protecting new orders.
- installation of several repair and cache plugins on the disabled site.
prevention of repetition
test the changes first in the staging of the same version, have rollback deployment and monitor PHP fatals. backup should include file and database and its restore should be really tested. Keeping versions and timestamps of changes will make diagnosis time much shorter.
When is expert help needed?
If the answer is sometimes white, only occurs under load, or a trace between PHP-FPM, database and custom code is spread, a snapshot of the moment of the error is required. WordPress technical troubleshooting service It can be used to check the application and server logs at the same time. You can also follow the official critical error message with the Critical Error guide.
Frequently Asked Questions
Why is the white screen visible only to the administrator?
Administration pages They have different hooks, queries and assets. Check the security plugin, dashboard, or error saving settings in the same user request.
Why does it return on page refresh?
Probably faulty worker, cache mismatch or load dependent error. Compare successful and failed request by PID, time and upstream.
Does increasing PHP memory always solve the problem?
No. Only useful when the valid workload does not exceed the smaller ceiling; Irregular consumption growth needs to find the cause.
What does the white screen with status 200 mean?
Maybe the output is interrupted before render or the empty response is cached. body, header and PHP log are the defining request.