# WordPress debug log: where debug.log lives, why it leaks and how to lock it down > The WordPress debug log is written to wp-content/debug.log, a file anyone can download unless your server blocks it. Here is how to check yours, use the log safely while troubleshooting, and switch it off or move it on production. Updated 2026-09-26 · WordPress & WooCommerce · HTML version: https://getreport.app/guides/wordpress-debug-log-exposed 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](https://getreport.app/guides/wordpress-security-basics-without-a-plugin). ## 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! */`: | Constant | What it does | Default | | --- | --- | --- | | `WP_DEBUG` | Turns debug mode on: PHP reports every error, warning and notice | `false` (but `true` when `WP_ENVIRONMENT_TYPE` is `development`) | | `WP_DEBUG_LOG` | Writes those messages to a file: `true` means `wp-content/debug.log`, a path means that file | `false` | | `WP_DEBUG_DISPLAY` | Prints the messages into the HTML of the page | `true` | 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`: ```bash 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](https://getreport.app/guides/staging-with-wordpress-plugins-and-host-tools). - Folders that show a file listing, where a log, backup or export can be browsed directly. [Directory listings and exposed files](https://getreport.app/guides/directory-listings-and-exposed-files) covers those. ### What getReport checks The [WordPress security scan](https://getreport.app/tools/wordpress-checker) 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: > **Free tool:** [WordPress security scan and health check](https://getreport.app/tools/wordpress-checker): Free WordPress security scan and health check from the outside: outdated core, closed plugins, exposed files, blocked indexing and classic launch mistakes. > **Check: No sensitive files are readable.** /.env holds database passwords and API keys; /.git exposes your source code and every secret ever committed. Both are the first things an automated scanner asks for. > > 1. Block dotfiles at the web server (nginx: location ~ /\. { deny all; }; Apache: RedirectMatch 404 /\..*$). > 2. Move .env outside the web root and rotate every credential in it; assume the file has already been copied. > **Check: No directory shows a file listing.** An auto-generated "Index of /" page shows every file in the folder, including backups, uploads and configuration files nobody ever linked to. > > 1. Apache: Options -Indexes in .htaccess; nginx: autoindex off; or put an empty index.html in the folder. > **Check: No public staging copy found.** A staging or dev copy that Google can index competes with the live site for its own content and often runs older, unpatched code. Anyone can find it. > > 1. Put the staging site behind HTTP authentication or an IP allow-list, or delete it when the launch is done. > 2. At minimum switch on "Discourage search engines" there and add a noindex X-Robots-Tag header. 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: ```php // 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: ```bash 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: ```bash 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: ```php // wp-config.php: production define( 'WP_DEBUG', false ); define( 'WP_DEBUG_LOG', false ); define( 'WP_DEBUG_DISPLAY', false ); ``` Then delete the old file: ```bash 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 # nginx, inside the server block location ~* \.log$ { deny all; } ``` ```apache # Apache 2.4, in .htaccess in the WordPress folder Require all denied ``` 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.