WordPress Debug Log: How to Turn It On Safely and Read Your Error Log

When a WordPress site breaks, the error usually tells you exactly what went wrong and which plugin or theme caused it. The trouble is that WordPress hides errors by default. The debug log is how you see them.

Reading error logs is a daily part of fixing client sites for us. This guide shows how to turn the log on without creating a new problem, where to find it, how to read it, and what to do when the log comes back empty.

What the WordPress debug log is

WordPress runs on PHP. When PHP hits a problem, such as a plugin calling a function that no longer exists, it creates an error message. Normally WordPress keeps those messages out of sight. Debug mode makes WordPress collect them, and the debug log saves them to a file you can read later.

There are actually two kinds of logs you might look at:

• The WordPress debug log, which you turn on yourself. It records PHP errors, warnings and notices from WordPress, your theme and your plugins.
• Your host’s server error log, which is usually already running. It catches server-level problems, including some errors that happen before WordPress even loads.

When a site breaks, we check both.

How to turn on the debug log safely

Debug settings live in wp-config.php, in your site’s main folder. You can edit it with your host’s file manager or FTP. Back up the file before you change it.

1. Find a private folder. You want a folder your hosting account can write to that is outside your website’s public files, usually the folder above public_html or httpdocs. Many hosts already have a private “logs” or “private” folder. If you are not sure, ask your host.
2. Add these lines to wp-config.php, above the line that says “That’s all, stop editing!” Change the path to your private folder.
3. Repeat the problem. Load the page that breaks, or do whatever triggers the error, so it gets written to the log.
4. Download the log from the private folder and read it, as explained below.

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

WordPress’s own documentation confirms WP_DEBUG_LOG can be set to a file path, so the log is saved wherever you choose.

Why not use the default setting?

Most guides tell you to set WP_DEBUG_LOG to true. That saves the log as debug.log inside your wp-content folder, which is part of your public website. Anyone who knows the address can download it, and debug logs can include file paths, plugin versions, database errors and sometimes email addresses.

Blocking the file with a rule in .htaccess is not always enough, because some servers deliver files directly without ever reading .htaccess. Saving the log outside the public folder works on every host.

Never show errors to visitors

WP_DEBUG_DISPLAY set to false keeps the errors in the log and off your pages. Leave it out, and WordPress may print error messages right into your site for every visitor to see.

Where to find WordPress error logs

• Your debug log is wherever you pointed WP_DEBUG_LOG. If someone used the default setting, it is wp-content/debug.log.
• Your host’s error log is usually in the hosting control panel, under a name like Logs, Errors or Error Log. Some hosts keep a separate PHP error log.
• WordPress’s own email. When a plugin or theme causes a fatal error, WordPress may email the site’s admin address with the error and a special link to get into the dashboard.

How to read the log

Download the log and open it in a text editor. We use Sublime Text, but any plain text editor works. Start at the bottom, where the newest entries are, and look for lines with the same time as the problem.

Each line starts with a date and time, then the type of message:

The file path in each line tells you where the problem is. A path containing wp-content/plugins/ followed by a name points to that plugin. wp-content/themes/ points to your theme. A line that repeats hundreds of times is usually one problem, not hundreds.

Let an AI read it first

Here is our honest advice to site owners: download the log and give it to your preferred AI assistant. Ask it what is causing the problem. It can usually name the plugin or theme involved and explain the error in plain English. Before you paste it in, skim the log and remove anything private, such as customer email addresses.

Even if you still want someone to fix it, you will have the error, the file and a likely cause to hand over. That cuts down troubleshooting time, which saves you money.

Turn it off when you are done

We only turn debugging on while we are tracking down a problem. Once it is fixed, we turn it off. A debug log left running keeps growing, slows the site down a little with every error it writes, and becomes one more file someone might find. One we came across had reached 60 MB.

To turn it off, change the lines in wp-config.php to:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Then delete or move the old log file, and if you ever used the default setting, check that yoursite.com/wp-content/debug.log no longer loads.

When the log is empty

The debug log only catches what PHP reports. Some of the worst problems never show up in it.

When the standard log does not show the problem, we test the parts of the site that skip the cache, such as logins and checkouts, and sometimes build our own debugger and logger to record exactly what the site is doing. Logs also turn up problems nobody reported. On a nursing education site, reading the logs during an update showed old lesson links crashing about once a day instead of showing a normal “page not found.”

Questions people ask

Sources

1. WordPress, Debugging in WordPress.
2. WordPress, wp-config.php.