Is Your WordPress debug.log Public? Check and Fix It

When WordPress debugging is switched on with logging, every PHP warning and error is written to a file: by default wp-content/debug.log. That file sits inside your website’s public folder, so on many servers anyone can open https://yoursite.com/wp-content/debug.log in a browser and read it.

Bots request that URL all the time, because it is a reliable way to learn about a site.

What a public debug.log gives away

• Full server paths, such as /home/u123456/domains/example.com/public_html/, which reveal the hosting account name and folder layout.
• Every plugin and theme that ever threw a warning, often with version-specific file names. That is a ready list of things to try known exploits against.
• Database errors showing table names and parts of SQL queries.
• Personal data when a plugin logs what it was processing: email addresses, order details, form submissions.

Logs grow for months without anyone looking, so a forgotten one can be hundreds of megabytes of history.

Check your site in ten seconds

Open https://yoursite.com/wp-content/debug.log in a private browser window.

• A 404 or 403 error: either the file does not exist or the server blocks it. Good.
• A page of text with dates and “PHP Warning” lines, or a download: the log is public. Fix it now.

Also look at Tools → Site Health → Info → WordPress Constants. If WP_DEBUG is true, debugging is on.

How to fix it

1. Turn debugging off on a live site. In wp-config.php:

   define( 'WP_DEBUG', false );

   If you need logging on production, keep errors off the page and send the log somewhere private (next step).

   define( 'WP_DEBUG', true );
   define( 'WP_DEBUG_DISPLAY', false );
   define( 'WP_DEBUG_LOG', '/home/youraccount/logs/wp-debug.log' );

   Since WordPress 5.1, WP_DEBUG_LOG accepts a file path. Point it at a folder outside public_html, and it can no longer be opened in a browser.

2. Delete the old wp-content/debug.log after reading anything you need from it.
3. Block the file name as a safety net. On Apache and LiteSpeed, add to the .htaccess in your site root:

   <Files "debug.log">
     Require all denied
   </Files>

   On Nginx, ask your host to deny /wp-content/debug.log.

Errors shown on the page

A related leak: with WP_DEBUG on and WP_DEBUG_DISPLAY not set to false, warnings are printed straight into your pages, sometimes above the header. Visitors and search engines see the same paths and plugin names. The free Ovanap Admin Toolkit’s site scan flags this setup, and the Pro Security Check also requests your debug.log URL the way a visitor would and tells you if it is downloadable.

Frequently asked questions

My host turned WP_DEBUG on for me. Is that normal?

Some one-click staging tools do. On a live site it should be off, or logging to a private path as shown above.

Is debug.log the only file to worry about?

Look for error_log files too. Many hosts write PHP errors to a file of that name in each folder. They usually cannot be opened from the web, but check by opening https://yoursite.com/error_log.