Your developer turns on logging to trace a broken form. The form gets fixed. The log keeps growing.
That file may hold more than error messages. Poorly written logging can capture email addresses, request data, file paths or API secrets. WordPress debug log security means collecting enough evidence to fix a fault while keeping that evidence out of public view.
Separate screen errors from private logs
A live page should not show raw debug output to visitors. It can reveal internal details and make the site look broken. Private logs give the team a place to inspect errors without placing them inside the page.
WordPress uses WP_DEBUG to enable debug mode. WP_DEBUG_LOG controls logging, and WP_DEBUG_DISPLAY controls on-page messages. These settings serve different purposes. Turning off display does not remove a log file.
The official debugging guide describes the settings. For a live incident, ask your host or developer to use a controlled, short logging window.
Choose a protected place for the log
When enabled with its simple true setting, WP_DEBUG_LOG normally writes to wp-content/debug.log. WordPress also supports a custom log path.
Prefer a host-approved location outside the public web root. Set file access so only the required service and team can read it. Check backup and log-shipping tools too: a private file can still be copied to a public destination.
If a log must stay under a web-accessible path, block access at the server and verify that block. Do not rely on a hard-to-guess filename. Our file permissions guide explains the related ownership checks.
Log the event, not the secret
Useful log entries include a timestamp, an error code, the affected feature and a request ID. The request ID lets a developer trace one failure across systems without copying the whole customer record.
Avoid logging passwords, authentication headers, payment data, private tokens or full form submissions. Mask sensitive fields before the message reaches disk. Removing them later is less reliable because copies may already exist.
For example, “CRM request failed: timeout; request 427” may be enough to start a trace. A full dump of the outgoing payload may expose far more than the team needs.
Our secrets management guide covers the response if a key has already reached a log.
Set a narrow troubleshooting window
Write down the fault and how to reproduce it. Note the start time. Run the smallest test that triggers the issue, then inspect the matching entries.
Use dummy data on a when you can. If the issue only occurs live, agree on the exact test, who can read the logs and when extra logging will stop.
A clear test might be: submit one test contact form, check whether its email was queued, and match the request ID. That is easier to review than a day of unrestricted request dumps.
Verify that the log is not public
Check the known log URL while logged out. The server should refuse access or return no such file. Also check likely renamed or compressed copies created by your own logging process.
Test through the CDN and, with your host's help, at the origin. An edge rule does not prove that direct server access is blocked. Include any storage bucket used for exported logs.
Do not paste raw logs into public forums or issue trackers. Share a short, redacted sample through an approved support channel. Keep the unredacted evidence only where the team needs it.
Manage size, retention and alerts
A noisy warning can fill disk space even when no attack occurs. Set log rotation, a size limit and a retention period. The right values depend on traffic and how quickly your team reviews problems.
Someone must own the alert when logging stops or disk use rises. Our helps connect errors with other site events.
After the fix, turn off temporary debug settings, confirm normal logging still works, and handle old files under your retention policy. Check that backups do not keep exposed secrets longer than intended.
If a debug log was exposed
Restrict access first and preserve the evidence needed to assess the event. Identify the data in the file, the exposure period and any downloads you can confirm.
Rotate secrets that may have leaked. Deleting the file does not revoke a copied key. Use our to track recovery and follow-up work.
If your team needs help making this repeatable, our can include safe debugging and log reviews.
Frequently asked questions
Does disabling WP_DEBUG delete debug.log?
No. Changing the setting does not delete an existing file. Review old logs and handle them under your retention policy.
Can I keep WordPress error logging on in production?
Yes, with a controlled logging setup. Keep errors off public pages, protect log access, limit sensitive data and manage file size and retention.
Is a debug log safe if its URL is hard to guess?
No. Use access controls or a location outside the public web root, then test that the file cannot be downloaded.
What should I do if an API key appears in a public log?
Revoke or rotate the key and assess the exposure. Removing the log alone does not stop someone from using a copied secret.
