WordPress Error Logs: How to Enable Them

WordPress error logs are critical troubleshooting files that record PHP errors, warnings, and notices affecting your website when debug mode is enabled. By default, WordPress hides these messages from public view to protect your website’s internal structure and security. 

In other words, if your website is broken, the page is white, and nothing on screen tells you why, the error log is your answer. The error log is the answer. The catch is that WordPress ships with logging switched off, hides fatal errors behind a recovery page, and writes the log to a publicly accessible location that anyone can download, exposing sensitive site information.

This guide covers all three. You will enable logging without exposing it, get WordPress to show you the actual fatal error, and read a real stack trace to identify the plugin responsible.

The Four Places WordPress Errors End Up

The error log is actually four different files, and knowing which is which saves you from searching an empty file for an hour. 

1. The WordPress Debug Log

Records PHP notices, warnings, deprecations, and fatal errors generated by WordPress core, plugins, and your theme. When debugging is enabled, these messages are typically written to wp-content/debug.log, helping developers to identify and troubleshoot issues. 

2. The PHP Error Log 

Your hosting environment’s server-level PHP log, configured through PHP and your hosting/server settings. You can often access it through cPanel or your hosting dashboard under the “Error Log” or “Logs” section. It can capture PHP errors that prevent WordPress from loading properly, such as syntax errors, fatal errors, and memory-limit exhaustion. 

3. The Web Server Error Log 

The web server’s own log, typically from Apache or Nginx. It records server-level problems such as 500 errors, 502 Bad Gateway errors, connection failures, and timeouts, including issues that occur before or while the request reaches PHP. If the WordPress debug log is empty, but the site still returns server errors, this is the next place to check.

4. The Fatal Error Email 

After detecting a fatal PHP error, WordPress emails the site admin with details about the error and a Recovery Mode link. The email may identify the affected plugin or theme and include the error message, file, and line number. It helps identify and recover from fatal errors, although PHP or server error logs may offer more complete diagnostic details. 

Turn On the Debug Log

Edit wp-config.php in your site root, adding the following line:

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_LOG', '/home/username/logs/wp-debug.log' );

define( 'WP_DEBUG_DISPLAY', false );

Because placement matters, add these definitions before the following line, which is near the bottom of wp-config.php:

require_once ABSPATH . 'wp-settings.php';

Any code added below that line runs after WordPress has already configured error handling. WordPress will ignore these constants if placed incorrectly, which is why users often enable logging but see no results.

The following is what each code does: 

• WP_DEBUG: The master switch that enables WordPress’s debug mode. Must be set to true for any other debug constants to work. 
• WP_DEBUG_LOG: It sends errors to a file; define ‘WP_DEBUG_LOG ‘,true, and drops the file directly into your /wp-content/debug.log directory. Use a supported file path since WordPress 5.1, and you get the file you specify. 
• WP_DEBUG_DISPLAY: Set define( ‘WP_DEBUG_DISPLAY’, false ), which is mandatory for a live site. Core handles the underlying display_errors setting for you when this is false, so you do not need an extra ini_set line. 

Do Not Leave the Log in wp-content

If you set WP_DEBUG_LOG to true instead of a file path, WordPress saves the log to wp-content/debug.log – inside your public webroot. This means anyone can read yoursite.com/wp-content/debug.log in their browser.

That file contains absolute server paths, your directory structure, the plugins you run and their versions, and sometimes fragments of database queries. It is a free reconnaissance document for anyone probing your site.

You can handle it in two ways, but the better one is what the snippet above does: set WP_DEBUG_LOG to a path outside the webroot. On most shared hosts, a logs directory sits alongside public_html, so /home/username/logs/wp-debug.log works. Check that the path exists and is writable before you rely on it.

If your host will not let you write outside the webroot, block access at the server. Apache, in the .htaccess at your site root:

<Files "debug.log">

  Require all denied

 </Files>

Nginx, in your server block:

location ~* /wp-content/debug\.log$ {
  deny all;
 }

Test it by loading the URL in a browser. You want a 403, not a file download.

If You Would Rather Use a Plugin

Both WP Debugging and Query Monitor toggle these constants from the admin area without you touching wp-config.php. That is reasonable if you don’t have file access. 

Two things you should know: First, they write the same constants, so all the placement and exposure caveats above still apply, including the default log location. Second, Query Monitor offers real-time debugging features that log files cannot provide. It profiles database queries, tracks hook execution, and identifies which specific plugin triggered each error, all visible in your admin bar.

Get WordPress to Show You the Real Fatal Error

The important part, which most guides leave out, may be one of the reasons why people follow every step correctly and still find nothing. 

WordPress has had a fatal error handler since 5.2. When a plugin causes a fatal error, WordPress catches it, shows visitors ‘there has been a critical error on this website’, emails the admin a recovery link, and pauses the offending plugin. This feature keeps your site accessible to visitors, but it interferes with debugging. When the handler catches an error, it prevents the full error message from appearing, meaning you can’t see what actually broke.

While you are debugging, switch it off:

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

After this, fatal error behave the way it should. You will get a white screen, and the full error with its stack trace will go into your log. 

Turn this back off when you are done. The handler exists for a reason, and you want it running on a live site.

Note the following two things: 

1. The recovery link in that email expires after a day by default
2. If a plugin got paused, it will stay paused until you either resume it from the recovery mode banner or, in a pinch, rename its folder over SFTP to force a clean deactivation. 

Find and Open the Log File

Follow the following steps to find and open the log file: 

1. Reproduce the Error 

The log only records what happens while logging is on. Load the page that breaks, or repeat the action that fails, and note the time to the minute. The timestamp is how you find your entry in a file with a thousand lines. 

2. Connect to Your Files 

SFTP with FileZilla, or your host’s File Manager in cPanel or Plesk; both will work. SFTP is faster after having saved the connection. 

3. Open It and Read the End 

Navigate to wherever you pointed WP_DEBUG_LOG. Download the file and open it in a plain text editor, such as Notepad, VS Code, or TextEdit, but not Word. 

You will find the newest entries at the bottom. Scroll to the end and work upward to your timestamp.

If you have SSH access, skip the download:

tail -n 50 /home/username/logs/wp-debug.log

Or watch it live while you reproduce the error in another window:

tail -f /home/username/logs/wp-debug.log

How to Read a WordPress Log Entry

Here is a real fatal error, the kind that takes a site down:

PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /home/username/public_html/wp-content/plugins/custom-orders/includes/class-order-sync.php:88

 Stack trace:

#0 /home/username/public_html/wp-includes/class-wp-hook.php(324): CustomOrders\OrderSync->sync_order(1420)

 #1 /home/username/public_html/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters('', Array)

 #2 /home/username/public_html/wp-includes/plugin.php(517): WP_Hook->do_action(Array)

 #3 /home/username/public_html/wp-admin/post.php(230): do_action('save_post', 1420)

 #4 {main}

 thrown in /home/username/public_html/wp-content/plugins/custom-orders/includes/class-order-sync.php on line 88

Read it in this order: 

The Last Line, Not The First: 

The error thrown in class-order-sync.php on line 88 is where the error actually happened. That path includes plugins/custom-orders, so the Custom Orders plugin is the culprit. That single detail is the answer to ‘which plugin broke my site,’ and that’s why this skill is worth ten minutes. 

The Message: 

‘Call to undefined function wc_get_product()’ means the code called a WooCommerce function that did not exist at that moment. Almost always, one of three things is happening: 

1. WooCommerce is deactivated, 
2. WooCommerce was updated and removed the function
3. The plugin ran too early in the load order to see WooCommerce yet 

The Stack Trace, Bottom Up: 

Read #4 upward, and you get the chain of events. The request hit wp-admin/post.php, which fired the save_post action, which ran through WordPress’s hook system, which called OrderSync->sync_order() on post 1420. So the error only fires when someone saves a post, which tells you exactly how to reproduce it. 

Notice, Warning, Deprecated, Fatal

Understanding the difference between notice, warning, deprecated, and fatal errors in your WordPress error log is the key to maintaining a healthy website. These entries represent different levels of PHP severity, telling you whether your website has minor informational issues or catastrophic crashes. 

However, among the four severity levels, only one is an emergency. 

PHP Warning:  Undefined array key “post_type” in /home/username/public_html/wp-content/themes/mytheme/functions.php on line 47

1. Warning: 

A warning means the code did something wrong but carried on; this one is an undefined array key. You will notice it before PHP 8, and it got promoted to a Warning, which is why upgrading PHP suddenly fills a lot of logs. A warning is worth fixing, but not on an urgent basis. 

PHP Deprecated:  Automatic conversion of false to array is deprecated in /home/username/public_html/wp-content/plugins/old-slider/slider.php on line 212

2. Deprecated: 

Deprecated means it works today but might break in a future PHP upgrade. This is an early warning list before a PHP upgrade and is not a live issue. Deprecations from a plugin that hasn’t been updated in three years are also a strong signal to replace it. 

3. Notice: 

Notice is informational. On a busy website, these make up most of your log and are the core reason it grows quickly. 

4. Fatal Error: 

A fatal error is a critical severity level; you will get a white screen, and you should always consider fatal errors to fix first. 

Common Log Entries and What They Mean

When the Debug Log Is Empty

Now you have enabled everything, but the file is not there, or it is there but completely blank. Work through these in a particular order. 

• The constants are in the wrong place: Below the wp-settings.php require line, they do absolutely nothing. This causes the issue more often than anything else combined. 
• The directory is not writable: If you pointed WP_DEBUG_LOG to a path, confirm the directory exists and PHP can write to it. A typo in the path produces silence, not an error. 
• A caching layer served the page: Page caching, a CDN, or an object cache means your PHP never ran, so nothing was logged yet. Purge the cache, test while logged in, or use a query string to bypass. 
• The error happens before WordPress loads: A PHP syntax error in wp-config.php itself, or a server-level 500, never reaches WordPress’s error handler. Check your host’s PHP error log and web server log too. 
• A second wp-config.php or an mu-plugin is overriding you: Some managed hosts inject their own debug settings. Search for other define ‘WP_DEBUG’ occurrences, including in wp-content/mu-plugins/. 
• The fatal error handler swallowed it: Cover the above and add WP_DISABLE_FATAL_ERROR_HANDLER.

Keeping the Log From Filling Your Disk

WordPress does not rotate the debug log; it appends forever. One plugin throwing a deprecation notice on every page load will produce a file measured in gigabytes, and on a shared host that means hitting your disk quota and taking the site offline. 

Truncate rather than delete, so the file handle and permissions stay intact:

truncate -s 0 /home/username/logs/wp-debug.log

Without SSH, open the file in your File Manager’s editor, select all, delete, save.

It’s best not to leave logging on. Enable it, reproduce the problem, read the log, turn it off. If you need continuous logging on a busy site, set up rotation with logrotate or use a plugin that caps the file size.

Turn Debug Mode Off

Set the constants back: define( ‘WP_DEBUG’, false );

You can leave the other lines in place, since they do nothing while WP_DEBUG is false, or comment them out to keep the file tidy. Now, remove WP_DISABLE_FATAL_ERROR_HANDLER completely, so the recovery handler protects your website again. 

If you are using a plugin, toggle debugging off there and deactivate the plugin if you won’t use it again. Then delete or truncate the log file, especially if it ever sat in wp-content. 

Do This on Staging, Not Production

What we discussed so far works on a live site, and often you have no choice because the bug only happens with real traffic and data. If you do have a choice, debug on a staging copy. 

The reason is not caution for its own sake. WP_DEBUG changes behavior, not just reporting. It turns off some caching, and if WP_DEBUG_DISPLAY is ever wrong, you leak file paths to visitors. Both are fine on a staging URL nobody is buying from. 

Take a backup before you edit wp-config.php either way. A stray character in that file takes the entire site down, admin included, and the fix requires SFTP access.

FAQs