How to Read Your WordPress debug.log (and Actually Fix What It Tells You)

WordPress's debug.log is one of the most useful files on a broken site and also one of the most intimidating — a single busy site can generate thousands of lines mixing genuine fatal errors with harmless deprecation notices from a theme that hasn't been updated since PHP 7. Here's how to actually read it.

First, make sure it's actually being written

Debug logging isn't on by default. Add this to wp-config.php, above the line that says /* That's all, stop editing! */:

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

WP_DEBUG_DISPLAY set to false is important on a live site — it stops errors from being printed directly on the page (which visitors would see) while still writing them to wp-content/debug.log for you to review privately.

The four severity levels, and which ones actually matter

• PHP Fatal error — the site (or that request) stopped working. Always investigate these first.
• PHP Warning — something went wrong, but PHP kept executing. Often points at a real bug (a function called with a missing argument, an array key that doesn't exist) even though the page still loaded.
• PHP Notice — usually minor (an undefined variable, for instance) and frequently harmless, but a high volume of notices from one plugin can be an early warning sign of sloppier code elsewhere in it.
• PHP Deprecated — a function or feature that still works today but is scheduled for removal in a future PHP version. Safe to ignore short-term, but worth tracking if you're planning a PHP upgrade — these are exactly what will break next.

The part everyone misses: which plugin or theme actually caused it

Every debug.log line includes a file path, and that path is the fastest way to identify the source — if the path contains /wp-content/plugins/some-plugin/, that plugin is the source, not WordPress core. The most common mistake is assuming an error is a "WordPress problem" when the file path clearly points at a specific plugin or theme. Before opening a support ticket with your host, check the path first — it'll usually tell you exactly where to look.

A realistic example

[03-Aug-2026 14:22:01 UTC] PHP Warning:  Undefined array key "size" in
/wp-content/plugins/example-gallery/includes/render.php on line 88

This tells you three things immediately: it's a Warning (site still loaded), it's from the "example-gallery" plugin specifically (not a theme or core issue), and it's a code bug where the plugin expected a "size" key that wasn't present. That's enough to report it to the plugin author with the exact file and line, or to update/replace the plugin if it's abandoned.

When the log is thousands of lines long

On a site that's been running with debug logging on for a while, the file can get enormous, mixing genuinely important fatals in with years of low-priority notices. Manually scrolling through it to separate what matters from noise is slow and error-prone — it's easy to miss the one fatal buried between hundreds of deprecation notices. Our WordPress debug.log Analyzer parses the whole file at once and groups every entry by severity and by the specific plugin or theme that caused it, so you can see at a glance whether you're dealing with one broken plugin or a dozen unrelated issues.

After you've found the cause

• Update or replace the offending plugin/theme if one is clearly responsible.
• If it's a core WordPress deprecation notice, check your PHP version against the WordPress compatibility table — you may be running a newer PHP than your WordPress version was tested against.
• Turn WP_DEBUG_LOG back off (or at least rotate/clear the log) once you're done — an ever-growing debug.log on a busy site will eventually eat meaningful disk space.