WordPress Debug Log Exposure Checklist: Keep WP_DEBUG_LOG Out of Public Reach

Last reviewed: April 13, 2026

WordPress debugging settings are useful during development and incident triage, but they become a security and operational problem when they are left enabled in production without clear boundaries. The most common failure mode is simple: WP_DEBUG is enabled, WP_DEBUG_LOG writes to the default wp-content/debug.log location, and no one verifies whether that file is publicly reachable. In the best case, the log fills disk and creates noise. In the worse case, it exposes filesystem paths, plugin names, query fragments, stack traces, integration endpoints, or other details an attacker can turn into reconnaissance.

This is not just a developer hygiene issue. It is a production control issue. Operators should know whether debug output is rendered to browsers, whether logs are being written inside the web root, where those logs actually live, who reviews them, and how they are removed after troubleshooting. A production WordPress site can still use debugging when necessary, but the workflow has to be deliberate and temporary rather than accidental and persistent.

Who this guide is for

This article is for WordPress administrators, agencies, platform teams, and security-minded operators responsible for production sites. It is especially relevant for shared hosting, multi-site fleets, headless WordPress backends, and any environment where plugin troubleshooting happens directly on the live stack.

Key takeaways

• If WP_DEBUG_LOG is set to true, WordPress writes to the default wp-content/debug.log file unless you provide another valid path.
• Production debugging should hide errors from browsers, keep log files out of the public web root when possible, and include a clear removal step after the troubleshooting window closes.
• A safe debug workflow is not just about constants in wp-config.php; it also requires direct validation that the log file is not publicly reachable and that on-screen errors are not leaking into responses.

WordPress debug log exposure checklist

1. Check whether debugging is enabled at all. Start by reviewing the active values for WP_DEBUG, WP_DEBUG_DISPLAY, and WP_DEBUG_LOG in wp-config.php. WordPress core documentation is explicit about how these settings interact: WP_DEBUG_LOG and WP_DEBUG_DISPLAY do nothing unless WP_DEBUG is true. Operators should not guess what the site is doing based on memory or old runbooks. Read the active configuration and treat the result as current fact.
2. Assume the default wp-content/debug.log path is too exposed for steady-state production. The official debugging handbook notes that setting WP_DEBUG_LOG to true writes errors to debug.log inside the content directory. That default is convenient for development, but it is a weak long-term production destination because it lives inside the application tree and often inside the web root. WordPress also supports a valid custom file path for WP_DEBUG_LOG. If logging is required during production troubleshooting, prefer a controlled path outside the public document root whenever the hosting model allows it.
3. Make sure errors are not shown to browsers. Production users should not see notices, warnings, or stack traces in page output. The handbook example for debugging safely disables display while still allowing logging. That distinction matters because teams sometimes enable WP_DEBUG to catch an issue and forget that on-screen exposure is the more immediate user-facing failure mode. The right baseline is to keep WP_DEBUG_DISPLAY false on production and explicitly disable PHP display errors as well.
4. Verify whether the log file is publicly reachable. This step is where many teams stop too early. A correct-looking constant in wp-config.php does not prove the log is protected. Test the real URL path if the log is inside wp-content, and confirm it cannot be downloaded over HTTP. If the file returns 200 or exposes partial content through the web server, treat that as an incident-level finding. The response may contain filesystem paths, plugin names, fatal error traces, REST handlers, scheduled task issues, or integration hints that materially help an attacker profile the stack.
5. Use a time-boxed debug workflow instead of leaving production in a semi-debug state. A strong operator workflow has a start and end. Decide why debugging is being enabled, who approved it, where logs will be written, when the setting will be removed, and who reviews the captured output. Long-lived debug settings usually mean no one owns the cleanup step. That is how small troubleshooting changes turn into permanent production exposure.
6. Review the log for information that should not live there in the first place. Even when the file is not public, debug logs can accumulate sensitive operational data. Look for absolute filesystem paths, request payload fragments, plugin license details, database errors, external endpoint names, or credentials accidentally written by custom code. If the site or a plugin logs too much, the fix is not only to protect the file. The fix may be to reduce what gets written there at all.
7. Remove or relocate the log after the troubleshooting window. When the issue is resolved, reset the debugging constants to the normal production baseline and archive or delete the captured log according to your retention rules. Leaving yesterday’s debug file inside the application tree because “it might be useful later” is not a serious operations posture. If the data is valuable, move it to the right log destination and ownership model. If it is not, remove it.

Useful commands or validation steps

# Check current debug-related constants in wp-config.php
grep -nE \"WP_DEBUG|WP_DEBUG_LOG|WP_DEBUG_DISPLAY\" wp-config.php

# Look for the default debug log in the content directory
find wp-content -maxdepth 1 -name 'debug.log' -ls

# Test whether the default log path is reachable over HTTP
curl -I https://example.com/wp-content/debug.log

# Safer production-style debug example
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/var/log/wordpress/site-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

The final block mirrors the official WordPress debugging guidance with one important production adjustment: instead of the default wp-content/debug.log, it uses a specific server-side path. WordPress core supports that pattern because WP_DEBUG_LOG can be set to a valid file path. The point is not to keep debug enabled forever. The point is to keep troubleshooting controlled while avoiding public exposure.

What to verify before calling production debugging safe

• Users do not see PHP errors. The rendered HTML and API responses should not expose notices or warnings to browsers.
• The log destination is intentional. Operators should know exactly where debug output lands and whether that path is inside or outside the document root.
• The default public path is not serving the log. If wp-content/debug.log exists, confirm it is blocked or not used.
• There is an owner and end date. Temporary production debugging should have a specific person responsible for disabling it.
• Captured data is reviewed for oversharing. If custom code or plugins are logging sensitive fragments, that needs its own remediation rather than a quiet assumption that the file is “internal.”

Common mistakes

• Leaving WP_DEBUG_LOG at its default destination. This is convenient, but it often means logs accumulate in a path that is too close to public serving.
• Turning off display without checking file exposure. Hiding browser errors is necessary, but it does not solve the problem if the log file itself is downloadable.
• Using production as a permanent debugging environment. Debugging should be an exception path with cleanup, not a steady-state configuration.
• Assuming the web server blocks debug.log because it “probably should.” Operators should test it directly rather than rely on undocumented hosting defaults.
• Ignoring what custom code writes to logs. A protected log can still become a data handling problem if plugins or themes write secrets, tokens, or raw request content.

What to document or review next

• The approved production debugging procedure, including who can enable it and how long it may stay active.
• The exact safe log destination for each WordPress property or hosting cluster.
• Whether your web server, control panel, or hosting template applies any explicit deny rules to debug.log or similar diagnostic files.

Related reading

If the site still depends on visitor-triggered background execution, review WordPress WP-Cron Reliability Checklist: Disable Visitor-Driven Scheduling and Verify Jobs so troubleshooting output does not distract from missed scheduled work. If the environment is a backend-only content service, pair this control with Headless WordPress Security Checklist: 5 Controls to Enable Before Launch.

References and further reading

• WordPress Advanced Administration: Debugging in WordPress
• wp_debug_mode()
• Common APIs Handbook: wp-config.php
• Advanced Administration: Editing wp-config.php