How to Enable WordPress Debugging (The Safe Way for Live Sites)

Enabling WordPress debugging tells WordPress to start capturing errors that would otherwise be silently suppressed. PHP fatal errors, warnings, notices, deprecated function calls — none of these show up anywhere useful by default. Once debugging is on, they get written to a log file you can actually read and act on.

The setup is straightforward, but there are a few constants to get right — and one combination that will expose errors to your visitors if you’re not careful. This guide covers the complete, safe way to enable WordPress debugging on a live site.

The Three Constants You Need

WordPress debugging is controlled by constants in wp-config.php. You need all three of these set correctly for safe, effective error logging on a production site:

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

Place these above the line that reads /* That's all, stop editing! Happy publishing. */

• WP_DEBUG — the master switch. Enables error reporting in PHP. Without this set to true, the other two constants do nothing.
• WP_DEBUG_LOG — writes errors to a file instead of doing anything visible. This creates (or appends to) /wp-content/debug.log, which becomes your WordPress debug log.
• WP_DEBUG_DISPLAY — controls whether errors print to the page. Its default is true, meaning if you only set WP_DEBUG without explicitly setting this to false, PHP errors will print to your pages for all visitors to see. Always set this to false on a live site.

For extra safety, add this line too — it suppresses error display at the PHP level in case a plugin overrides WP_DEBUG_DISPLAY:

@ini_set( 'display_errors', 0 );

Where the WordPress Debug Log Is Written

With WP_DEBUG_LOG set to true, WordPress writes errors to /wp-content/debug.log. This is the WordPress error log location by default. Some hosting environments write it elsewhere — Logmate’s System Info screen shows the exact path for both your PHP log and JS log files on your specific installation.

Reading the raw log file means FTP or file manager access every time something breaks. Logmate reads it for you from inside the WordPress admin — filterable, searchable, with occurrence counts and timestamps — so you can check your error log the same way you’d check any other dashboard screen.

Enabling SCRIPT_DEBUG for JavaScript Errors

The three constants above handle PHP error logging. For JavaScript errors, there’s a separate constant: SCRIPT_DEBUG.

define( 'SCRIPT_DEBUG', true );

This forces WordPress to load full, unminified versions of its own core scripts, making JavaScript error messages in the browser console readable rather than cryptic references into compressed bundles. Use it during active debugging sessions and disable it when done.

Logmate’s settings panel lets you toggle SCRIPT_DEBUG directly from the WordPress admin without editing wp-config.php. It also captures WordPress JavaScript errors from visitor browser sessions server-side — so you see browser-side errors even from visitors you’re not actively watching, without needing SCRIPT_DEBUG permanently on.

Enabling Debugging Without Editing wp-config.php

If your hosting provider’s control panel offers a debug mode toggle — as cPanel, Kinsta, WP Engine, and others do — you can enable WP_DEBUG from there without touching the config file. Check your host’s documentation for the specific option.

For SCRIPT_DEBUG specifically, Logmate handles the toggle from inside the dashboard. For the PHP debugging constants, a code snippets plugin that lets you add PHP to wp-config.php from the admin is another option, though FTP access to the config file is the most reliable method.

Frequently Asked Questions About Enabling WordPress Debugging

Is it safe to enable WP_DEBUG on a live site?

Yes, with WP_DEBUG_DISPLAY set to false. Errors go to the log file silently without any visible change for your visitors. The risk is only when WP_DEBUG_DISPLAY is left at its default of true, which prints errors to the page. Always explicitly set it to false in a production environment.

Will enabling debugging make my site slower?

Very slightly. PHP error checking adds minimal overhead to each request, and file writes to the debug log add a small amount of disk I/O. On most sites this is imperceptible. Where it becomes noticeable is on sites already generating thousands of log entries per hour — in that case, the high error volume is the performance concern, not the debug mode itself.

My debug log is filling up fast. What should I do?

A rapidly filling debug log almost always means a plugin or theme is generating the same WordPress PHP error on every page load. Open Logmate’s Logs screen and sort by occurrence count — the entry with the highest count is almost certainly the culprit. Once you identify the source, address it (update the plugin, contact the developer, or deactivate it temporarily) and set up Logmate’s automatic log retention to keep the file size manageable going forward.

How do I disable WordPress debugging when I’m done?

Set WP_DEBUG back to false in wp-config.php, or remove the define statement entirely. WordPress will stop writing to the debug log immediately. The existing log file remains on disk until you delete or purge it — Logmate’s purge function handles this from the settings panel without needing server access.

---

Enabling WordPress debugging is a five-minute setup that gives you complete visibility into what your site is doing under the hood. The key is always setting WP_DEBUG_DISPLAY to false before going live. Logmate handles reading those logs from inside your dashboard, adds JavaScript error capture on top, and manages log retention automatically.

You might also like:

• WordPress WP_DEBUG Explained: What It Does and How to Use It Safely
• WordPress Debug Log: What It Is and How to Use It
• How to View WordPress Error Logs (Every Method Explained)