WordPress debug log: where debug.log lives, why it leaks and how to lock it down

The WordPress debug log is a text file of PHP errors, warnings and notices that WordPress writes to wp-content/debug.log when WP_DEBUG and WP_DEBUG_LOG are switched on in wp-config.php. Because it sits inside the public web folder, anyone can open https://example.com/wp-content/debug.log unless the server blocks it, and it tells them your server paths, your plugins and sometimes your database errors. This guide shows how to check whether yours is exposed, how to use the log safely while troubleshooting, and how to switch it off or move it out of reach on a live site. It is step 8 of the WordPress security checklist.

Quick answer

• Check it now: open https://yoursite.com/wp-content/debug.log. A page of text means it is exposed; a 403 or 404 is what you want.
• On production, set WP_DEBUG to false, or keep logging but point WP_DEBUG_LOG at a file outside the web root.
• Always set WP_DEBUG_DISPLAY to false on a live site, so errors never print into pages.
• Block .log files at the web server as a safety net, then delete the old debug.log.
• If it was exposed, read what it contained and change any secret that appears in it.

What is the WordPress debug log?

WordPress has three constants that control error reporting. They go in wp-config.php, above the line /* That's all, stop editing! */:

Two details from WordPress core's own code catch people out. WP_DEBUG_LOG only does something while WP_DEBUG is true. And because WP_DEBUG_DISPLAY defaults to true, switching on WP_DEBUG alone prints errors into your pages for every visitor. Since WordPress 5.1 you can give WP_DEBUG_LOG a file path instead of true, which is how you keep the log out of the public folder.

The file keeps growing until someone deletes it. Sites where debugging was turned on once, years ago, often have a debug.log of hundreds of megabytes.

Why an exposed debug.log is a problem

A debug log is written for developers, and it reads like a map of the server:

• Absolute paths, such as /home/clientname/public_html/wp-content/plugins/…, which reveal the hosting account's username and folder layout.
• Every plugin and theme that throws a notice, often with version-specific file names. Attackers match those against lists of known vulnerabilities.
• Database errors, with the table prefix and sometimes the failing query and the data in it.
• Whatever plugins log. Some plugins write API responses, email addresses, order details or tokens to the same file with PHP's error_log().

None of this is a break-in by itself, but it saves an attacker the reconnaissance, and personal data in the log is a data-protection problem of its own. Scanners request /wp-content/debug.log on WordPress sites for exactly that reason.

How to check if your debug.log is exposed

Open the address in a private browser window, or use curl:

curl -s -o /dev/null -w "%{http_code} %{size_download} bytes\n" https://example.com/wp-content/debug.log

• 200 with a size above 0: the log is public. Open it to see what it contains, then follow the fix below.
• 403: the server blocks it. Good, but also check that debugging is not still writing a growing file.
• 404: there is no file at that address. Check wp-config.php anyway, in case the log is written somewhere else that is public.

Check the other places logs end up, too:

• A custom WP_DEBUG_LOG path inside the web root, such as /wp-content/logs/debug.log.
• Files named error_log or php_errorlog in the site root and in /wp-admin/. Some hosts write PHP errors there regardless of WordPress's settings.
• Staging and development copies, where debugging is usually on. A public staging site with a public debug log is a common pair; see staging with WordPress.
• Folders that show a file listing, where a log, backup or export can be browsed directly. Directory listings and exposed files covers those.

What getReport checks

The WordPress security scan requests a fixed list of well-known public addresses and never guesses file names. Today it checks for readable .env and .git files, open directory listings and public staging copies:

A dedicated check for an exposed debug.log is planned for the WordPress Doctor. Like the other sensitive WordPress checks, it will show a plain yes or no to anyone who runs the report and the details only to the site's verified owner, and it will never display the log's contents. Until then, the one-line curl test above is the check.

How to use the debug log safely

When you need the log to troubleshoot a white screen, a critical error or a misbehaving plugin, turn it on in a way that writes to a private file and shows nothing to visitors:

// wp-config.php: temporary debugging on a live site
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/example/logs/wp-debug.log' ); // a folder outside the web root
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Use the absolute path of a folder next to, not inside, your site's public folder; your host's file manager shows the full path. Make sure the folder exists and PHP can write to it. With WP-CLI the same settings are:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG /home/example/logs/wp-debug.log
wp config set WP_DEBUG_DISPLAY false --raw

Then reproduce the problem and read the newest lines:

tail -n 50 /home/example/logs/wp-debug.log

Each line has a timestamp, the type (Fatal error, Warning, Notice, Deprecated) and the file and line where it happened. The file path tells you which plugin or theme is responsible. Fatal errors are what break pages; deprecation notices are usually harmless and just noisy.

When you are done, switch debugging off again and delete the log. If you cannot write outside the web root, use true for a short session and delete wp-content/debug.log as soon as you have read it, with the server rule below in place.

How to switch the debug log off on production

For a normal live site, this is the whole configuration:

// wp-config.php: production
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Then delete the old file:

rm wp-content/debug.log

Your host still logs fatal PHP errors in its own error log, usually in the hosting panel, so turning off WordPress's log does not leave you blind to crashes.

Block log files at the server as a safety net

Settings get changed, and plugins sometimes write their own logs into wp-content. A server rule makes sure no .log file is ever downloadable, whatever writes it.

# nginx, inside the server block
location ~* \.log$ {
    deny all;
}

# Apache 2.4, in .htaccess in the WordPress folder
<FilesMatch "\.log$">
    Require all denied
</FilesMatch>

Reload nginx after the change (sudo nginx -t && sudo systemctl reload nginx). Test with the curl command above: it should now return 403. On managed WordPress hosting, ask support whether they block log files already; many do.

If your debug.log was exposed

1. Read it before you delete it. Copy it somewhere private and search it for passwords, API keys, tokens, email addresses and order or customer data.
2. Rotate anything secret it contains: API keys, SMTP passwords, payment gateway keys, database passwords.
3. Check your access log for requests to debug.log from addresses that are not yours, to know whether it was read.
4. Delete the file, switch debugging off and add the server rule.
5. Fix what it was logging. A log full of warnings from one plugin points to an outdated or broken plugin, which is a risk in its own right.
6. If it held personal data and was downloaded, treat it as a data breach and follow your data-protection duties.

Common mistakes

• Turning on WP_DEBUG without WP_DEBUG_DISPLAY set to false. Errors print into pages for every visitor, including paths and queries.
• Leaving debugging on after the fix. The log grows for years. Turn it off the same day.
• Relying on .htaccess on nginx. nginx ignores .htaccess files. Add the rule to the nginx config.
• Deleting the log without switching debugging off. WordPress writes a new one with the next warning.
• Copying wp-config.php from staging to production. Staging often has debugging on. Keep environment-specific settings separate, for example with WP_ENVIRONMENT_TYPE.

Questions people ask

Where is the WordPress debug log?

By default it is wp-content/debug.log, created when both WP_DEBUG and WP_DEBUG_LOG are true in wp-config.php. If WP_DEBUG_LOG is set to a file path instead, the log is at that path. Some hosts also write PHP errors to files named error_log in the folder where the error happened, or to a log in the hosting panel.

How do I enable the debug log in WordPress?

Add three lines to wp-config.php above "That's all, stop editing!": define( 'WP_DEBUG', true );, define( 'WP_DEBUG_LOG', true ); or a path outside the web root, and define( 'WP_DEBUG_DISPLAY', false ); so errors are not shown to visitors. Reproduce the problem, read the log, then switch debugging off and delete the file.

Is it safe to leave WP_DEBUG on in production?

No. With the default settings it prints errors into your pages, and with logging on it fills a file that anyone can download unless the server blocks it. Both reveal server paths, plugin names and sometimes data. Set WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY to false on a live site, and turn debugging on only briefly, logging to a file outside the web root.

Can I delete the debug.log file?

Yes. WordPress only appends to it; nothing depends on the old content. Read it first if you are troubleshooting or if it may have been public, then delete it. If debugging is still on, WordPress creates a new file with the next error, so switch it off in wp-config.php first or at least block .log files at the server.

What does a "deprecated" notice in the debug log mean?

It means a plugin or theme uses a function or argument that WordPress or PHP plans to remove in a future version. It does not break anything today, but it tells you which code needs an update before the next major upgrade. Check that the plugin named in the file path is up to date, and report the notice to its developer if it is.