Using WordPress Debug Logging Without Exposing Errors to Visitors Print

WordPress debugging can help reproduce an error, but logs may contain private paths, request data, or other sensitive details. Prefer a staging copy and enable diagnostics only for the time needed to reproduce the problem.

1. Back up wp-config.php and record its current debugging settings.
2. Choose a writable log location outside every public document root, subject to the account permissions and PHP path restrictions. Do not assume that a shared temporary directory is private. If you cannot establish a protected destination, do not enable file logging on the public site.
3. Edit the existing definitions, or add them before the stop-editing comment if absent. Set WP_DEBUG to true, set WP_DEBUG_LOG to the quoted absolute path of your protected log file, and set WP_DEBUG_DISPLAY to false. Do not create duplicate constant definitions.
4. Keep PHP error display disabled. Reproduce the problem once and inspect the log privately.
5. Restore the previous production settings, disable debugging, and securely remove the diagnostic log or retain it only in protected storage.

Hidden errors do not mean a private log

WP_DEBUG_LOG set to true normally writes to wp-content/debug.log. Depending on web-server rules, a visitor may be able to download that file. WP_DEBUG_DISPLAY controls errors shown in pages; it does not block requests for the log. Verify that any log location cannot be served publicly. Do not post raw logs containing credentials or personal data.

Reference: WordPress Debugging.