To check the PHP error log on WordPress, add define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true); to your wp-config.php file. WordPress then writes all PHP errors to /wp-content/debug.log, which you can open via FTP or your hosting file manager.

Even the best WordPress themes can produce PHP errors. Error logs capture every warning, notice, and fatal error from your themes, plugins, and WordPress core. Without logging enabled, most PHP errors show as a blank white screen or vanish without a trace. For more details, see our guide on how to fix the 500 error in WordPress.

This guide covers four methods for checking your WordPress PHP error log: editing wp-config.php via FTP, accessing logs through your hosting control panel, using a plugin, and using WP-CLI from the command line.

What Is the WordPress PHP Error Log?

The WordPress PHP error log is a plain text file that records every PHP error, warning, and notice your website generates. When WP_DEBUG_LOG is enabled, WordPress writes these messages to a file called debug.log inside your /wp-content/ folder.

The log captures three types of messages:

  • Fatal errors: These crash the page entirely and are often the cause of the white screen of death. Database write failures - such as the could not insert post into the database error - often leave a specific MySQL error code in the log that pinpoints the exact table and cause.
  • Warnings: Non-fatal issues that may cause unexpected behavior -- often from outdated plugins using deprecated PHP functions.
  • Notices: Minor code issues that don't typically affect functionality but indicate code quality problems.

Each log entry includes a timestamp, the error type, the file path, and the exact line number where the error occurred. This information tells you precisely which plugin, theme, or core file is causing problems.

Method 1: Enable PHP Error Logging via FTP and wp-config.php

This is the most reliable method and works on any WordPress hosting environment.

Step 1 -- Connect to Your Server via FTP

Download and open FileZilla (a free FTP client). Enter your FTP credentials -- Host, Username, and Password -- and leave the Port field empty. Your hosting provider supplies these credentials, which you can usually find in your hosting control panel under FTP Accounts.

Step 2 -- Edit wp-config.php

Navigate to your WordPress root folder. Depending on your host, this folder is named root, www, public_html, or your domain name. Find wp-config.php and open it in a text editor.

Scroll until you see this line:

/* That's all, stop editing! Happy blogging. */

Immediately above that line, add:

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

The three constants do the following:

  • WP_DEBUG -- Turns on WordPress debug mode so PHP errors are captured.
  • WP_DEBUG_LOG -- Writes errors to the /wp-content/debug.log file instead of only displaying them.
  • WP_DEBUG_DISPLAY -- Set to false to prevent error messages from appearing on your live site where visitors can see them.

If define( 'WP_DEBUG', false ); already exists in your file, change false to true rather than adding a duplicate line. Save the file and re-upload it to your server.

Custom log path: You can also pass a file path string to WP_DEBUG_LOG instead of true. For example, define( 'WP_DEBUG_LOG', '/home/user/logs/debug.log' ); writes the log to a location outside your public web root, which is more secure.

Step 3 -- Open the Debug Log File

After enabling debug mode, visit a few pages on your site to trigger any errors. WordPress creates (or appends to) a file at /wp-content/debug.log. Access it via FTP the same way you accessed wp-config.php. Open the file in a text editor -- errors are listed chronologically with timestamps, file paths, and line numbers pointing to where each error started.

Method 2: Access PHP Error Logs via cPanel

If your hosting provider uses cPanel, PHP error logs are available without any FTP or wp-config.php editing.

  1. Log in to your cPanel account.
  2. Go to the Metrics section and click Error Logs.
  3. The log displays your site's most recent PHP errors -- typically the last 300 lines.

This method shows server-level PHP errors, which may include errors that WP_DEBUG doesn't capture. It's especially useful for diagnosing errors that happen before WordPress finishes loading -- like a corrupted wp-config.php or a missing PHP extension.

Managed WordPress hosts handle logs differently:

  • WP Engine: Access logs through the User Portal under "Logs" in your environment's management panel.
  • Kinsta: View PHP error logs in the MyKinsta dashboard under Sites > Your Site > Logs.
  • Cloudways: Find logs in the Server Management panel under Monitoring > Logs. Cloudways also has built-in log viewer tools that make this even easier.
  • SiteGround: Go to Site Tools > Statistics > Error Log.

Method 3: Use a Plugin to View PHP Errors

If FTP access isn't available and your host doesn't have a log viewer, a plugin can display PHP errors inside the WordPress admin dashboard.

Two popular options:

  • Query Monitor: Shows PHP errors, database queries, HTTP API calls, and hook information in the WordPress admin toolbar. The most full-featured option.
  • WP Debugging: A lighter plugin that enables WP_DEBUG and related constants through the admin panel -- no manual file editing needed.

Install either plugin from the WordPress.org plugin directory, activate it, and error information appears in the admin toolbar or a dedicated settings page.

The main limitation: plugins only capture errors generated after WordPress loads. If WordPress itself fails to start (a fatal error in wp-config.php or a core file), plugins won't catch it. For those cases, use Method 1 or Method 2.

Method 4: Check Error Logs with WP-CLI

If you have SSH access to your server, WP-CLI gives you the fastest way to check and manage WordPress error logs from the command line.

First, enable debug logging if it isn't already on:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Then view the last 50 lines of the debug log:

tail -50 wp-content/debug.log

To watch the log in real time as you browse the site (useful for reproducing a specific error):

tail -f wp-content/debug.log

Press Ctrl+C to stop watching. WP-CLI is pre-installed on most managed WordPress hosts and is the preferred method for developers who are comfortable with the terminal.

How to Read Common PHP Error Messages

Once you have the log open, here's what the most common error messages mean and how to fix them:

  • Fatal error: Call to undefined function... -- A plugin or theme is calling a function that doesn't exist. This usually happens after a PHP version update removes a deprecated function, or when a required plugin dependency is missing.
  • Warning: Cannot modify header information... -- Output (usually whitespace or HTML) is being sent before WordPress calls its header functions. Check the file and line number in the error -- it's often caused by extra whitespace before the opening <?php tag.
  • Deprecated: Function X is deprecated... -- The code is using a function removed or flagged for removal in a newer PHP version. Usually harmless for now, but report it to the plugin or theme developer so they can update their code.
  • Parse error: syntax error... -- A file contains broken PHP code, typically from a failed manual edit. The line number in the error points to the exact location of the syntax mistake.
  • Fatal error: Allowed memory size exhausted... -- WordPress has exceeded the PHP memory limit. Fix it by adding define('WP_MEMORY_LIMIT', '256M'); to wp-config.php, or increase the limit in your hosting control panel's PHP settings.
  • Fatal error: Maximum execution time exceeded... -- A script ran longer than the server's time limit (usually 30 seconds). This often happens during large imports or plugin operations. Increase the limit in php.ini or your host's PHP settings: max_execution_time = 120.

Secure Your Debug Log File

The debug.log file can contain sensitive information: file paths, database query details, and sometimes partial user data. Anyone who knows the default location can try to access it directly at yourdomain.com/wp-content/debug.log.

Three ways to protect it:

  1. Block direct access via .htaccess: Add this rule to the .htaccess file inside your /wp-content/ folder: 
    <Files debug.log>
Order allow,deny
Deny from all
</Files>
  2. Move the log outside your web root: Set a custom path with define( 'WP_DEBUG_LOG', '/home/user/logs/debug.log' ); in wp-config.php. This puts the file in a directory that isn't publicly accessible.
  3. Delete the log after troubleshooting: Once you've identified and fixed the errors, delete debug.log via FTP and set WP_DEBUG back to false.

How to Clear or Rotate the Debug Log

On busy sites, debug.log can grow to hundreds of megabytes. A bloated log file wastes disk space and becomes difficult to read.

To clear the log manually, connect via FTP and delete /wp-content/debug.log. WordPress creates a fresh one automatically the next time an error occurs.

For automatic rotation on Linux servers with SSH access, set up a logrotate rule:

/path/to/wordpress/wp-content/debug.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

This keeps four weeks of compressed log history and prevents the file from growing indefinitely. If you don't have SSH access, simply delete the file via FTP once a month while debugging is active.

Bonus: Enable SCRIPT_DEBUG for Theme and Plugin Development

If you're troubleshooting a JavaScript or CSS issue rather than a PHP error, add this constant to wp-config.php:

define( 'SCRIPT_DEBUG', true );

This forces WordPress to load the unminified versions of all core JavaScript and CSS files. It makes browser developer tools more useful because you can read the actual source code rather than compressed one-line files. Disable it when you're done -- minified files load faster.

Wrap Up

Enabling WordPress PHP error logging takes under 2 minutes via wp-config.php, and the debug.log file at /wp-content/debug.log captures everything from fatal crashes to minor notices. Always disable WP_DEBUG when you're done troubleshooting on a live site -- leaving it enabled can expose sensitive path information to visitors. If you need ongoing error visibility without debug mode, a plugin like Query Monitor gives you error data inside the WordPress admin without any code changes.

For a deeper look, see our complete guide to What Is WordPress?.

Show More

* read the rest of the post and open up an offer