How to fix «Your site is set to log errors to a potentially public file» in WordPress

Table of Contents

What exactly does this warning mean in Site Health?

Since version 5.2, WordPress introduced the Site Health tool to help administrators identify configuration and security issues. The message «Your site is configured to log errors to a potentially public file.» appears specifically when the system detects that the debug mode is active and configured to write to a standard file.

To understand severity, we need to look under the hood. When we develop or troubleshoot PHP and WordPress, we need to see what's going wrong. To do this, we use a constant in the file wp-config.php call WP_DEBUG_LOG.

This means that if someone visits tusitio.com/wp-content/debug.log, may download the complete error history of your site. Depending on your plugins and errors, this file may contain sensitive information.

Source of the warning due to WP_DEBUG_LOG configuration

The warning does not appear randomly. It is specifically activated when the value WP_DEBUG_LOG has been added and activated (set to true) in the site configuration file. This indicates to the system that PHP errors, warnings and notices are being actively written to an accessible physical disk.

According to documentation and technical discussions in kernel development, this check is intended to protect users who forget to disable development mode before moving to production.

• Technical source: You can read more about the developers' original discussion of this implementation in the WordPress Core Trac development ticket.
• Community discussion: There is also extensive debate about how this affects the health of the site in StackExchange - Development questions and answers.

The default public access vulnerability

The key concept here is that the generated file (debug.log) is technically considered a «regular file» (regular file). In terms of web servers (such as Apache or Nginx), unless explicitly told otherwise, any regular file within the public root of the document is servable to the end user.

In my experience auditing sites for clients, I have encountered files debug.log indexed by Google, which represents a massive security risk. You don't need to be an advanced hacker; it's enough to know the default WordPress folder structure.

The user community has long debated whether this file should be accessible by default or not. The reality is that, by design, WordPress prioritizes compatibility, and locking files by default could cause problems in certain server configurations.

To delve deeper into the community's perspective on this vulnerability, I recommend reading this discussion on Reddit about public accessibility of debug.log.

Why WordPress doesn't «fix» this automatically

You may be wondering: «If WordPress knows this is insecure, why doesn't it save the file to a secure location automatically?». This is an excellent question that touches on the technical limitations of web architecture.

Technical limitations in the verification of safe routes

Even if an advanced user tries to configure the WP_DEBUG_LOG out of the public folder (e.g., one level above the public_html), WordPress cannot verify with 100% certainty whether that location is actually secure programmatically.

This is due to the variability of hosting environments. A site may be running in a subdirectory, or the server may have «alias» configurations that make folders higher than ABSPATH remain publicly accessible through another URL.

The intent of the «Potentially Public» message is to alert the user to the fact that the file could be accessible depending on the general configuration of the system, transferring the responsibility for security to the server administrator, since there is no concrete way to check external accessibility automatically without making HTTP requests that could fail or give false positives.

For the more technical minded, the details of this design decision are documented in the WordPress Trac Ticket #46689.

Step-by-step solution: How to eliminate the error and secure your site

Now that we understand the «why», let's move on to action. If you see the error «Your site is configured to log errors to a potentially public file», you have three main ways to fix it, ordered from most recommended to most advanced.

Method 1: Disable Debugging (Recommended for Production Sites)

If your site is live and receiving real visits, you should not have the debug log enabled. The error log consumes disk resources (the file can grow to gigabytes) and exposes the above information.

The immediate corrective action after completing the debugging, recommended by experts, is not only to change permissions, but to disable the feature and remove the trace.

1. Access your site's files via FTP or your hosting's File Manager.
2. Locate the file wp-config.php at the root.
3. Find the lines related to debug and change them to false.

// Disables debug mode
define( 'WP_DEBUG', false );

// Disables saving to log file
define( 'WP_DEBUG_LOG', false );

// Prevents errors from being displayed on the screen
define( 'WP_DEBUG_DISPLAY', false );
        

Method 2: Change the location of the log file

If you are a developer and need to keep the registry active in a production environment (something I discourage, but sometimes it is temporarily necessary), you can force WordPress to save the file to a non-public path.

For this, instead of putting true in the constant, you can define a specific path:

// Define a path outside the public directory (public_html)
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/user/private_logs/my_site_debug.log' );
define( 'WP_DEBUG_DISPLAY', false );
        

Note: Even by doing this, the warning in Site Health is likely to persist. Remember what we mentioned about «Technical limitations». WordPress cannot verify that /home/user/logs_private/ is safe, so it will still warn you as a precaution. However, you will know that the file is safe.

Method 3: Protecting the file using .htaccess (For Apache servers)

If you cannot move the file or you prefer an extra layer of security, you can use the file .htaccess to prohibit access to any file with extension .log.

Add this code block to your file .htaccess:

Order Allow,Deny
    Deny from all
        

This will return a «403 Forbidden» error to anyone trying to access the file from the browser, but will allow WordPress to continue writing to it.

Best Practices: Ideal Workflow by Marcos Arcusin

In my day-to-day work developing solutions with Vue.js and WordPress, I follow a strict protocol to prevent the keyword «Your site is set to log errors to a potentially public WordPress file» from even being a concern for my clients.

Here I share with you my workflow to ensure income and stability:

1. Never debug in production

Always use a Staging (test environment). Most modern hostings offer this functionality at the click of a button. Activate WP_DEBUG_LOG only in the staging environment. If the error is production specific and is not replicated in staging, use the protection method by .htaccess and deactivate it as soon as you get the data you need.

2. Log rotation and cleaning

Log files can grow indefinitely. A log file debug.log file size of 2GB can knock your site down if you run out of disk space. Get in the habit of reviewing and deleting the file periodically.

3. Use of monitoring plugins

Instead of relying on a plain text file, consider using plugins such as Query Monitor for real-time debugging, or external services such as Sentry or New Relic to monitor PHP errors without exposing public files.

Conclusion

The warning «Your site is set to log errors to a potentially public file» is a friendly but firm reminder from WordPress about the importance of data security. It's not an error you should fear, but a setting you need to manage.

Recall the key points we have covered thanks to research from official sources:

• The warning comes from having WP_DEBUG_LOG active.
• The file debug.log is publicly accessible by default.
• WordPress can't «fix» it just because it can't validate server paths with certainty.
• The real solution is to deactivate debug and delete the file when you finish work.

Keeping your site clean from Site Health warnings is not just vanity; it is a fundamental practice to protect your business and your customers. If you follow the steps outlined above, you will not only eliminate the error message, but you will have raised the security level of your WordPress infrastructure.