WP_DEBUG is one of the most useful troubleshooting tools built into WordPress. It does not fix errors for you, but it can help you find them.

When WP_DEBUG is enabled, WordPress can report PHP errors that might otherwise go unnoticed. This can help you identify whether an issue is coming from a plugin, theme, custom code snippet, or WordPress itself.

What WP_DEBUG Is Used For

WP_DEBUG is a WordPress constant that controls whether WordPress runs in debug mode.

In normal use, WordPress often hides many technical errors from visitors. This is usually a good thing because most site visitors don’t need to see warnings, notices, file paths, or other developer-focused information.

But when you are troubleshooting, hidden errors can make a problem harder to understand. Turning on WP_DEBUG gives WordPress permission to surface more information about what is going wrong.

This is useful when you are dealing with problems such as:

• A plugin or theme error
• A white screen or fatal error
• A failed import, export, checkout, or form submission
• A warning or notice in the admin area
• A problem that appeared after an update
• Custom code that is not behaving as expected

Put another way, WP_DEBUG helps you stop guessing and start working from actual error information.

How to Turn On WP_DEBUG

To enable WP_DEBUG manually, open your site’s wp-config.php file.

Find the line that says:

/* That's all, stop editing! Happy publishing. */

Then place this code above it:

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

This is the safest common setup for troubleshooting a live site because it enables debugging and logging without showing raw error messages to visitors.

After adding the code, save the file and reproduce the issue you are investigating. For example, reload the broken page, run the failed import again, submit the form, or repeat the action that caused the problem.

What Each Debugging Constant Does

WP_DEBUG is the main switch. Setting it to true turns on WordPress debug mode.

WP_DEBUG_LOG tells WordPress to write debugging information to a log file. In most cases, that file is located here:

/wp-content/debug.log

This is useful because you can review the error after the problem happens instead of trying to catch it on-screen.

WP_DEBUG_DISPLAY controls whether errors are displayed in the browser. On live sites, it is usually better to set this to false so visitors don’t see technical messages.

Together, these three settings let you collect useful debugging information while keeping the public-facing site clean and safe.

How to Read the Debug Log

Once logging is enabled, open the debug.log file and look for entries that appeared around the time you tested the problem.

A helpful log entry may include:

• The type of error
• A file path
• A line number
• A plugin or theme folder
• A function or method name
• A timestamp

For example, if the file path includes /wp-content/plugins/example-plugin/, the issue may involve that plugin. If it includes /wp-content/themes/your-theme/, the theme may be involved.

Do not assume every warning in the log is the cause of the problem. Focus on recent entries, repeated messages, fatal errors, and anything that lines up with the action you tested.

When Not to Display Errors Publicly

There is a big difference between logging errors and showing them to visitors.

Displaying errors publicly can reveal technical details such as server paths, plugin names, theme structure, or snippets of code behavior. That information is useful to you, but it does not belong on the front end of a live site.

That is why this setup is usually preferred:

define( 'WP_DEBUG_DISPLAY', false );

You still get debugging information in the log, but visitors do not see raw PHP messages on the page.

On a local or staging site, displaying errors may be acceptable because the site is not public. On a production site, logging privately is usually the better option.

Common Mistakes When Using WP_DEBUG

The first common mistake is editing wp-config.php without a backup. This file controls important WordPress settings, and a small typo can break the site. Always save a copy before changing it.

The second mistake is using curly quotes in code. The constants must use straight quotes, like this:

define( 'WP_DEBUG', true );

Not this:

define( ‘WP_DEBUG’, true );

The third mistake is leaving debugging enabled after troubleshooting. Debug logs can grow over time, and debugging output may expose technical information if settings are changed incorrectly.

When you are finished, turn debugging off by changing:

define( 'WP_DEBUG', true );

To:

define( ‘WP_DEBUG’, false );

Using WP Debug Toolkit Instead

You can use WP_DEBUG manually, but WP Debug Toolkit makes it easier by bringing the process within the WordPress dashboard.

It includes an Error Log Viewer that makes the WordPress error log easier to read and analyze. Instead of opening a raw debug.log file, you can review logged errors in a much more organized interface:

It also includes a Query Viewer for inspecting database activity. This can help you identify slow queries, inefficient plugin behavior, repeated query patterns, and possible database bottlenecks:

WP Debug Toolkit can also monitor your site for errors 24/7 and includes a crash recovery app that lets you disable or enable plugins and themes even when you can’t access wp-admin.

Final Thoughts

So, how do you use WP_DEBUG?

1. Turn it on when you need WordPress to report technical errors during troubleshooting.
2. Pair it with WP_DEBUG_LOG so those errors are saved to a log file, and set WP_DEBUG_DISPLAY to false on live sites so visitors don’t see raw error output.
3. Reproduce the problem, check the log, and use the file paths, line numbers, and error messages to narrow down the cause.

To make this process far easier, use a plugin like WP Debug Toolkit, which lets you handle everything from within the WordPress dashboard and provides professional interfaces that are far easier to read.

For other debug plugins, see Best Plugins for WordPress Debugging and Troubleshooting.