How to Read WordPress Error Logs

If your WordPress site has ever shown a blank white screen, thrown a “critical error” banner, or just started behaving strangely after an update, the answer to why is almost always sitting in a file you’ve probably never opened: the error log.

The problem is that most site owners either don’t know this file exists, don’t know how to turn it on, or open it once, see a wall of cryptic text, and close it again. That’s a shame, because the WordPress error log is the single most useful diagnostic tool you have — it tells you exactly which plugin, theme, or line of code caused a problem, down to the file name and line number.

This guide walks you through where to find your error log, how to turn logging on if it’s off, and how to actually read what it says — without needing to know PHP.

What Is a WordPress Error Log?

WordPress is built on PHP, and PHP has a built-in habit of recording every warning, notice, and fatal error it runs into while your site is loading. When error logging is enabled, all of that gets written to a plain text file instead of being silently ignored (or worse, displayed publicly to your visitors).

That file is usually called debug.log, and it lives inside your /wp-content/ folder. Some hosts also keep a separate, host-level PHP error log outside the WordPress installation entirely — more on that below.

Why This Matters for Your Site

A few reasons site owners should care about this, even if they never plan to touch code themselves:

• Faster fixes. A developer who’s handed a log file with the exact error, file, and line number can usually fix the issue in minutes. Without it, they’re guessing — and guessing costs you money and downtime.
• Catching problems before visitors do. Plenty of errors don’t crash the site outright; they just quietly break a form, a checkout step, or a layout on certain pages. The log often shows these long before a customer complains.
• Safer updates. Right after updating a plugin or theme is exactly when new errors tend to appear. Checking the log immediately after an update is one of the simplest habits that prevents a small conflict from turning into a broken site.

If your site is currently down or throwing a critical error and you need it working again today rather than after you’ve learned to read PHP notices, this is exactly the kind of job covered under WordPress bug fixing — send over the log (or access to the site) and the cause usually gets identified fast.

Where to Find Your WordPress Error Log

Option 1: Via FTP or File Manager

1. Connect to your site using FTP (FileZilla, for example) or your hosting file manager.
2. Navigate to /wp-content/.
3. Look for a file called debug.log.

If it’s not there, it means WordPress debug logging isn’t enabled yet — see the next section.

Option 2: Through Your Hosting Control Panel

Most managed WordPress hosts (SiteGround, Kinsta, WPX, Cloudways, etc.) expose PHP error logs directly in their dashboard, often under a section called “Logs,” “Error Log,” or “PHP Errors.” This log can catch server-level issues that never make it into WordPress’s own debug.log, so it’s worth checking both if one doesn’t explain what you’re seeing.

Option 3: Via a Plugin

If you’re not comfortable with FTP, plugins like WP Activity Log, Query Monitor, or simply Error Log Monitor will surface recent PHP errors right inside your WordPress dashboard. Query Monitor in particular is popular with developers because it also shows slow database queries and script conflicts — useful if your issue looks more like a performance problem than an outright error.

How to Enable Error Logging

By default, many WordPress installs have logging turned off or set to display errors directly on the page (which is a security risk — never leave that on for a live site). To enable proper logging instead:

1. Connect via FTP and open wp-config.php in your site’s root folder.
2. Find the line that says /* That's all, stop editing! Happy publishing. */.
3. Just above it, add:

php

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

This tells WordPress to record errors quietly into /wp-content/debug.log instead of showing them to visitors. Save the file, and reproduce whatever issue you were seeing — a new or updated debug.log file should appear.

Important: turn WP_DEBUG_DISPLAY off (as shown above) on a live site. Displaying raw PHP errors to visitors can expose file paths and plugin details that make your site an easier target.

How to Actually Read a Log Entry

This is where most people give up — the log looks like noise. It isn’t. Every line follows a fairly consistent pattern. Here’s a typical entry:

[27-Aug-2026 14:03:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function acf_add_local_field_group() in /home/site/public_html/wp-content/themes/mytheme/functions.php:142

Break it down piece by piece:

• Timestamp — [27-Aug-2026 14:03:11 UTC] — when it happened. Useful for matching the error to something you remember doing (installing a plugin, editing a page).
• Error type — PHP Fatal error — the severity. This is the important part to look at first.
• Description — Uncaught Error: Call to undefined function acf_add_local_field_group() — what actually went wrong. In this example, the theme is trying to call a function from Advanced Custom Fields, but that plugin isn’t active — a classic case of a theme depending on a plugin that got deactivated or removed.
• File and line number — /wp-content/themes/mytheme/functions.php:142 — exactly where the problem lives. This is the single most useful piece of information in the whole line, because it tells you (or your developer) precisely where to look.

The Four Error Types You’ll See

• Fatal error — stops execution completely. This is usually what causes a white screen or “critical error” message. Always fix these first.
• Warning — something went wrong, but WordPress kept running anyway. Often harmless on its own, but a pile of warnings usually points to a deeper compatibility issue.
• Notice — a minor, non-breaking issue, often about a variable that wasn’t set. Low priority, but worth cleaning up over time since notices tend to multiply after PHP version upgrades.
• Deprecated — a function that still works today but is scheduled for removal in a future PHP or WordPress version. Ignoring these is how sites suddenly break after a routine PHP update.

Common Patterns Worth Recognizing

A few recurring log messages come up again and again, and knowing what they mean saves a lot of guesswork:

• “Allowed memory size exhausted” — your site ran out of PHP memory, usually from a heavy plugin, a large import, or a low hosting memory limit.
• “Call to undefined function” — something is calling code from a plugin that’s inactive, missing, or was removed without updating the code that depends on it.
• “Maximum execution time exceeded” — a script (often a plugin doing something bulky, like an import or backup) took too long to finish.
• Repeated errors from the same plugin file — a strong sign that one specific plugin is the source of an ongoing conflict, especially after an update.

When to Bring in Help

Reading the log tells you what broke. Fixing it — without breaking something else, or without a fragile patch that fails again at the next update — is where experience matters. If you’re staring at a log full of fatal errors and undefined functions and would rather have someone who does this daily just resolve it, that’s a normal, one-off part of ongoing WordPress maintenance — regular log checks are one of the things that catch these issues before they become a full outage.

And if the errors keep coming back after every plugin or WordPress core update, that’s usually a sign the site’s underlying code (an old theme, outdated custom functions, unmaintained plugins) needs a proper cleanup rather than another one-off patch.

Key Takeaways

• Your error log lives at /wp-content/debug.log once logging is enabled — turn it on via wp-config.php with WP_DEBUG_LOG set to true.
• Never leave WP_DEBUG_DISPLAY on for a live site.
• Read each log line for four things: timestamp, error type, description, and file/line number.
• Fatal errors need fixing first; deprecated notices are early warnings worth acting on before the next PHP upgrade.
• If the log looks like gibberish or the same error keeps returning, that’s exactly the kind of thing worth handing off rather than debugging blind.