How to Read the WordPress Debug Log and Find the Problem

The WordPress debug log is a plain-text file that records every PHP error, warning, and notice your site throws — making it the single most reliable way to find out what is actually broken. Most site owners never look at it; the ones who do can usually pinpoint a problem in minutes instead of hours. This guide shows you how to turn it on safely, read what it says, and translate the noisy output into a concrete fix.

What the Debug Log Is (and What It Isn't)

WordPress ships with a built-in logging system powered by PHP's error-reporting functions. When debug mode is active, every fatal error, warning, deprecated-function notice, and database error gets appended to a file called debug.log, stored by default at /wp-content/debug.log.

What it is: a chronological record of PHP-level problems inside WordPress core, your plugins, and your theme.

What it isn't: a server error log (that lives in your hosting control panel), a JavaScript console (open browser DevTools for that), or a security audit trail.

Understanding the distinction matters because a blank debug log does not mean your site is healthy — it might mean logging simply isn't enabled yet.

Enabling the Debug Log Safely

Back up before you touch wp-config.php. A typo in that file can take down your site instantly. Download a copy via SFTP or your host's file manager before editing.

Open wp-config.php in the root of your WordPress install. Find the line that reads:

define( 'WP_DEBUG', false );

Replace that block — or add these lines immediately above the /* That's all, stop editing! */ comment — with:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

The critical line here is WP_DEBUG_DISPLAY false. Without it, PHP errors print directly onto your pages, visible to every visitor. With it, errors go silently to the log file instead. Never enable debug display on a live site.

Save the file, reload your site, reproduce the problem (click around, submit a form, complete a checkout), then check the log.

Custom log file location

Storing debug.log inside the publicly accessible wp-content folder is a mild security risk — anyone who guesses the URL can read your error messages, which can include file paths and database table names. Move it outside the web root by adding:

define( 'WP_DEBUG_LOG', '/home/yourusername/debug.log' );

Replace the path with an absolute server path one level above your public folder. Your host's file manager or a quick pwd in SSH will show you the correct path.

Finding and Opening the Log

Connect via SFTP (FileZilla, Transmit, Cyberduck) or your host's file manager. Navigate to wp-content/ and look for debug.log. If it doesn't exist yet, trigger an error first — load a page, then refresh the directory.

Download the file and open it in a decent text editor (VS Code, Sublime Text, even Notepad++ on Windows). Do not try to read a large log in a browser tab — files can grow to hundreds of megabytes on a busy site.

On a server with SSH access, tail the live log while you reproduce a problem:

tail -f /path/to/wp-content/debug.log

Anatomy of a Debug Log Entry

Every line follows a predictable structure. Here's a real-world example:

[24-Jun-2025 14:03:17 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wc_get_order() in /home/site/public_html/wp-content/plugins/my-custom-plugin/class-orders.php on line 84

Breaking it down:

• Timestamp — [24-Jun-2025 14:03:17 UTC]. Compare this to when the problem was reported to confirm you're looking at the right incident.
• Error type — PHP Fatal error. See the severity guide below.
• Message — Call to undefined function wc_get_order(). This tells you exactly what went wrong.
• File path — everything after in. This names the plugin, theme, or core file responsible.
• Line number — on line 84. This is where in the file the error was thrown.

Error Severity: What Each Type Means

A fresh debug log on a healthy site will almost always have a handful of Notices and Deprecated messages — that's normal. Fatals and Parse errors are the ones that break visible functionality.

Reading the Log Strategically

Start at the end, not the beginning

Log files accumulate over time. The most recent errors are at the bottom. In VS Code, press Ctrl+End (or Cmd+End on Mac) to jump straight there.

Match timestamps to the problem

If a customer reported a broken checkout at 2:15 pm, filter the log for entries around that time. Everything else is noise from previous incidents.

Look for repeating patterns

The same error appearing hundreds of times usually means a plugin is running on every page load and failing on every page load. That's your culprit.

Trace the file path to the plugin or theme

The file path in every log entry tells you exactly where the problem lives:

• /wp-content/plugins/plugin-name/ — a plugin issue
• /wp-content/themes/theme-name/ — a theme issue
• /wp-includes/ or /wp-admin/ — WordPress core (rare, often triggered by an incompatible plugin)

Decode the message itself

A few patterns you'll see constantly:

• "Call to undefined function X" — Plugin X tried to use a function from another plugin that wasn't loaded yet, or WooCommerce/ACF isn't active when expected.
• "Cannot redeclare function X" — Two plugins or themes are defining the same function name. Classic plugin conflict.
• "Allowed memory size of X bytes exhausted" — PHP ran out of memory. Often triggered after adding a heavy plugin. See the white screen of death guide for the memory limit fix.
• "require(): Failed opening required" — A file the code expected to exist is missing. Often happens after a botched update or partial migration.
• "Uncaught Error: Class 'X' not found" — An autoloader didn't register a class, frequently a plugin running on an incompatible PHP version.

Turning Off Debug Mode When You're Done

Debug mode should not run indefinitely on a production site. It adds marginal performance overhead and the log file will grow without limit. Once you've diagnosed the problem, set WP_DEBUG back to false and delete or archive the debug.log file so it doesn't accumulate stale data before your next debugging session.

When the Debug Log Doesn't Tell You Enough

Some problems don't produce PHP errors at all. A slow database query, a misconfigured redirect loop, a JavaScript conflict, or a server-level 500 error will leave the debug log silent. In those cases, reach for the server error log in cPanel/Plesk, browser DevTools, and a query monitor plugin — the debug log is one tool in a wider diagnostic toolkit, not the only one.

If you're seeing a critical error message or a 500 internal server error, the debug log is always the right first stop — but the fix itself might sit at the server or database layer.

When to Call a Professional

You've found the error, you've traced it to a plugin or theme — but the plugin is business-critical and you can't just deactivate it, the fix involves editing code you're not confident in, or the log is throwing dozens of different errors and you're not sure where to start. That's the moment to hand it off.

If the site is down or revenue is affected right now, Mend's Emergency Rescue gets a senior engineer on it the same day, with a backup-first workflow and a plain-English report of what was found and fixed. For a single contained error you just need resolved cleanly, the Quick Fix is built for exactly that.

If you want someone else to keep an eye on errors before they become emergencies, Mend's Care Plan includes uptime monitoring, managed updates, and regular backups — the conditions that catch most of these problems before a visitor ever sees them.

The debug log is one of the most powerful diagnostic tools WordPress gives you, and it's completely free. The engineers who fix WordPress sites fastest aren't smarter — they just go to the log first, every time. Now you can too.