Quick answer
Production PHP errors should be investigated through protected logs rather than printed into public pages. Displayed errors can reveal paths and configuration details while disrupting the visitor experience.
Before you start
Confirm the exact domain, PHP handler/version, effective configuration source, and current logging settings. Preserve the existing settings and ask support if your account cannot change the required directive.
Steps
- Use the hosting provider's supported PHP configuration controls for the intended domain. Keep display_errors and startup-error display off in production while enabling the appropriate private logging path.
- Ensure logs are stored outside public access and are writable only as required by the application. Set a retention and rotation policy so diagnosis does not fill the account.
- For WordPress, review its own debug configuration as well as the PHP settings. A plugin or application override can change what the browser sees.
- Reproduce the reported issue safely and compare the timestamp and request with the private log. Verify the public response does not disclose diagnostic details.
Verify the result
Support should have enough sanitized evidence to locate the error while visitors see the intended page or a useful generic failure state. Do not publish phpinfo or a debug log as a support attachment.
Troubleshooting and recovery
If settings appear ineffective, check which PHP configuration and handler actually serve the domain. Startup and fatal errors can behave differently from runtime settings; avoid pasting unrelated Apache directives into a PHP-FPM configuration.
Related help
- Use website error logs to diagnose a failed request
- Report and investigate a WordPress critical error
- Keep credentials and private files out of your public website
Official references
Reviewed October 31, 2026. Interfaces, vendor availability, and account features can change. Check your current account before making changes.
