How to Read a WordPress Error Log and Find the Real Problem

When your WordPress site breaks, the error log is the first place you should look - but only if you know how to read it. Most site owners stare at walls of text that look like gibberish, copying random lines into Google and hoping for a miracle. The truth is that WordPress error logs follow a strict format, and once you understand the anatomy of an entry and which errors matter most, you can trace almost any problem back to its source. This article shows you how to enable logging, decode what you're seeing, identify the real problem among the noise, and fix the specific issues that trip up most people.

Enable logging in wp-config.php

WordPress error logging is off by default. You need to add or modify three constants in your wp-config.php file, which sits in your site's root directory. Connect to your server via FTP or your hosting control panel's file manager, download wp-config.php, and look for a section that starts with define( 'WP_DEBUG'. If it doesn't exist, add the following lines just before the comment that says "That's all, stop editing!":

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

Setting WP_DEBUG to true activates WordPress debugging mode, which causes WordPress to display all PHP errors, notices, and warnings. The second line, WP_DEBUG_LOG, tells WordPress to save those errors to a file instead of just showing them. The third line, WP_DEBUG_DISPLAY, prevents errors from appearing on your live site - critical if you're troubleshooting a production environment. The final line ensures PHP itself doesn't override this and display errors anyway.

After you save and re-upload wp-config.php, WordPress will create a debug.log file inside the /wp-content/ folder the next time an error occurs. If your site is already broken, triggering the error again will populate the log.

Read the structure of a log entry

Every line in debug.log follows the same anatomy. You'll see a timestamp in square brackets, the error type, the error message, the file path where the error occurred, and the line number. Here's a real example:

[22-Jan-2026 14:32:15 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wp_get_current_user() in /home/user/public_html/wp-content/plugins/custom-plugin/custom-plugin.php:47

The timestamp tells you exactly when the error happened. The error type here is "PHP Fatal error," which is the most severe. The message "Call to undefined function wp_get_current_user()" describes what went wrong. The file path and line number point you to the exact location in the code.

You'll encounter four main error types, and they matter in this order:

• Fatal errors - These stop execution completely. Your site breaks, pages won't load, or critical features die. Always fix these first.
• Warnings - These indicate a problem that doesn't stop the script, but something is wrong. A missing file, a deprecated function, or an incorrect parameter type.
• Notices - These are minor issues, often undefined variables or array keys. They rarely break functionality but signal sloppy code.
• Deprecated - A function or feature is outdated and will be removed in a future version. Not urgent, but should be addressed before updates.

When you open debug.log, it will almost always show entries from bottom to top, with the newest errors at the end. Scroll to the bottom first.

Match timestamps to actions

The timestamp is your map. If your checkout page broke at 2:30 PM and you see a fatal error logged at 14:30 UTC, that's your culprit. Matching timestamps to the action that caused the issue is the fastest way to isolate the problem when you have hundreds or thousands of log entries.

If you're troubleshooting intermittently, clear the log before you reproduce the issue. Download debug.log via FTP, delete its contents, save the empty file, and re-upload it. Then perform the exact action that triggers the error - submit a form, view a product page, run a plugin's import tool. Refresh the log immediately afterward. You'll see only the entries created by that action.

When errors pile up, focus on the first fatal error in a sequence. Later errors often cascade from the first failure. A plugin might call a function that depends on a variable set earlier in the script. If that variable never gets set due to an earlier fatal error, you'll see multiple errors, but only the first one is the root cause.

Trace the file path to the source

The file path tells you which part of your site is broken. If the path includes /wp-content/plugins/plugin-name/, the problem is in that plugin. If it shows /wp-content/themes/your-theme/, it's your theme. Errors in /wp-includes/ or /wp-admin/ usually mean a core file is corrupted or a plugin is calling WordPress functions incorrectly.

Line numbers are exact. Open the file in a text editor, jump to that line, and you'll see the code that triggered the error. Sometimes the problem is on that line. Other times, the issue is earlier in the function - a missing variable, a conditional that never executed, or a hook that fired too early. Read the surrounding context, not just the single line.

If the error is in a third-party plugin or theme you didn't write, you have three options: update to the latest version, contact support with the exact error and line number, or deactivate the plugin and replace it. Never edit plugin files directly unless you fork the code into a custom plugin, because updates will overwrite your changes.

What breaks

The log file grows to gigabytes and crashes your site

If you leave WP_DEBUG_LOG enabled on a live site with a poorly coded plugin, debug.log can balloon to hundreds of megabytes or even gigabytes. Your hosting account runs out of disk space, backups fail, and file operations slow to a crawl. I've seen logs hit 4 GB in a week from a single plugin that logged a notice on every page load.

Fix this by disabling logging in wp-config.php, deleting the log file via FTP, and only re-enabling it when you need to troubleshoot. If you must leave logging on, set up a cron job or use a plugin that auto-rotates or truncates the log daily.

Errors reference /home/user/ paths that don't match your server

Sometimes you'll see file paths in the log that point to a completely different server structure, like /home/olduser/public_html/ when your actual path is /var/www/html/. This happens when you migrate a site and WordPress or a plugin caches the old absolute paths in the database or in serialized options.

The error still tells you which file and line, but you have to translate the path. Search your database for the old path string and replace it with the new one using a tool like Better Search Replace. Some plugins also hard-code paths in their own config files - check the plugin's settings or reinstall it fresh.

The log shows the error but the fix doesn't take

You find the fatal error, update the plugin that caused it, and clear the log. The error keeps coming back. This happens when you have object caching enabled (Redis, Memcached) or a page cache that serves stale PHP. The updated code is on disk, but the server is still executing the cached version.

Flush all caches - object cache, page cache, CDN cache, and opcode cache (OPcache or APCu). Restart PHP-FPM if you have access to your server. If you're on shared hosting, contact support and ask them to flush the opcode cache. Then reproduce the error and check the log again. If the timestamp updates but the error persists, the fix didn't work - you're chasing the wrong file or line.

FAQs

Can I leave WP_DEBUG_LOG enabled permanently on a live site?

Technically yes, but it's a bad idea. The log file grows indefinitely unless you manage it, and you're exposing sensitive file paths and function names that attackers could use to probe your site. Enable logging only when troubleshooting, then disable it and delete the log. If you need persistent monitoring, use an error-tracking service like Sentry or Rollbar that rotates logs and alerts you to spikes.

What if debug.log doesn't exist even after I enable it?

WordPress only creates debug.log when an error actually occurs. If the file doesn't appear after you edit wp-config.php, either no errors have been triggered yet, or file permissions prevent WordPress from writing to /wp-content/. Check that the wp-content folder is writable (755 or 775 permissions). You can also create an empty debug.log file manually, set it to 644, and WordPress will write to it.

How do I read a log with thousands of repeated errors?

Search for unique error messages rather than scrolling line by line. Copy the log into a text editor that supports find and replace, then search for "Fatal error" first. Count how many distinct fatal errors exist. Next, look at the timestamps - if the same error repeats every second, it's triggered by a cron job or a page-load hook. If it appears sporadically, it's user-triggered. Focus on the first occurrence of each unique error, not the repetitions.

Can I log errors to a different location outside wp-content?

Yes. Instead of setting WP_DEBUG_LOG to true, set it to an absolute file path outside your web root. For example:

define( 'WP_DEBUG_LOG', '/home/user/logs/wp-errors.log' );

This keeps the log out of the publicly accessible wp-content folder and makes it easier to manage with server-level log rotation tools. Make sure the path is writable by the web server user.

What do I do if the error is in WordPress core files?

Errors in /wp-includes/ or /wp-admin/ usually mean the core files are corrupted, a plugin is calling core functions incorrectly, or you're running outdated code. Download a fresh copy of WordPress from wordpress.org, extract it, and replace everything except wp-content and wp-config.php. If the error persists, a plugin or theme is passing bad data to a core function - the log's stack trace will show the chain of calls leading to the error, and the earliest entry in your custom code is the real source.