When your WordPress site stops working, it can be frustrating. You might see a “white screen of death” or a strange error message. But you can find out exactly what went wrong. WordPress error logs tell you what happened, where it happened, and why.
Think of an error log as your website’s flight recorder. It saves key events that lead to a crash. This guide shows you how to set up logs, find issues, and prevent future problems. You can become a confident troubleshooter.
What Are WordPress Error Logs?
The term “error log” can mean a few different files. They all track problems, but for different parts of your site.
- WordPress Debug Log (debug.log): This is your main tool. When you enable it, it records errors from WordPress core, themes, and plugins. It is key for finding plugin conflicts or theme function problems.
- PHP Error Log: Your server creates this log. It records errors related to PHP code. This includes when a memory limit is exceeded or there is a syntax error. Your hosting provider sets the location of this file.
- Server Error Log (Apache/Nginx): This log captures bigger server‑level problems. It includes file permission issues or .htaccess errors. You will find details on “500 Internal Server Error” messages here.
Step 1: Enabling WordPress Debug Logging
To start, you must tell WordPress to log errors. The best way is to edit your wp‑config.php file.
- Always back up your wp‑config.php file before you make changes.
- Connect to your site with an FTP client or your host’s File Manager.
- Find and open wp‑config.php in your WordPress root directory.
- Just before the line /* That’s all, stop editing! Happy publishing. */, paste this code:
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable Debug Logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Disable display of errors and warnings on the front end
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
You can also use a plugin like WP Debugging. You can also check your hosting dashboard. Many hosts have a one‑click button to enable debug mode.
Step 2: Finding and Accessing Your Error Log
After you turn on logging, make the error happen again on your site. The details will be saved to the debug.log file. This file is in your /wp-content/ folder.
You can view it with your host’s File Manager, an FTP client, or your hosting dashboard’s “Log Viewer.” For advanced users with SSH access, you can use tail -f /path/to/wp-content/debug.log to watch the log in real time.
Step 3: How to Decode an Error Message
Error logs have a set pattern. Here is a sample error decoded:
[31-Aug-2025 10:25:15 UTC] PHP Fatal error: Uncaught Error: Call to undefined function my_custom_function() in /home/user/public_html/wp-content/themes/my-awesome-theme/functions.php:123
- Timestamp: [31-Aug-2025 10:25:15 UTC] is when it happened.
- Severity: PHP Fatal error is how serious it is. Other types are Warning and Notice. A fatal error stops the page from loading.
- Error Message: Call to undefined function my_custom_function() is what went wrong.
- Location: /…/themes/my-awesome-theme/functions.php:123 is the exact file and line number.
Step 4: A Workflow for Solving Any Error
- Enable Logging: Turn on WP_DEBUG_LOG.
- Reproduce the Error: Do the action that causes the problem.
- Analyze the Log: Open debug.log and find the most recent fatal error.
- Identify the Source: Look at the file path in the error. Does it point to a plugin or a theme?
- Fix the Problem: Take specific action based on the error type.
This workflow is your base. Now we will look at more advanced ways to find the cause when it is not obvious.
Advanced Debugging: Isolating Conflicts
Sometimes the error log points to a file but the real cause is a conflict between two different things. Here is how to find the exact source.
The Classic Conflict Test
This process is the best way to find plugin or theme conflicts.
- Switch to a Default Theme: Activate a theme like “Twenty Twenty‑Four.” If the error goes away, your original theme had the problem. Check its functions.php file or custom templates for issues.
- Deactivate All Plugins: If the theme was not the issue, deactivate all of your plugins.
- Check Again: See if the error is gone. If it is, you know one of the plugins is the problem.
- Reactivate One by One: Activate your plugins one at a time. Check for the error after each one. The one that makes the error come back is the one causing the conflict.
Best Practices for Custom Code
You can prevent many common issues if you write custom code.
- Prevent “Cannot Redeclare” Errors: Before you define a function in your theme or plugin, wrap it in a function_exists() check. This prevents a fatal error if another plugin tries to use the same function name.
if ( ! function_exists( 'my_custom_function' ) ) {
function my_custom_function() {
// Your code here
}
}
- Log Your Own Variables: You can write your own messages to the debug.log. This lets you see the value of a variable at a certain point.
// Place this in your code to inspect an array or object
if ( WP_DEBUG ) {
error_log( 'My variable contains: ' . print_r( $my_variable, true ) );
}
Deep Dive: Understanding PHP and Server‑Level Errors
Knowing more than just basic WordPress errors will help you solve harder problems.
Memory Limit vs. Execution Time
These two server resource errors are often confused.
- Fatal error: Allowed memory size of … bytes exhausted: This is about space. PHP ran out of RAM to do a task.
Fix: Increase the memory limit with define( ‘WP_MEMORY_LIMIT’, ‘256M’ ); in wp-config.php. - Fatal error: Maximum execution time of 30 seconds exceeded: This is about time. A script took too long to run. This often happens during data imports or when a slow external API is used.
Fix: You can increase the time limit in your php.ini file or with .htaccess. The best long‑term fix is to make the slow script faster.
PHP Version Compatibility
WordPress, themes, and plugins have minimum PHP version needs. An error like Parse error: syntax error, unexpected T_FUNCTION on a modern server can mean you are running a very old plugin. That plugin is not compatible with your server’s PHP version.
Action: Make sure your plugins and themes are updated. Check that they are compatible with your server’s PHP version. You can check your PHP version through your hosting panel or the “Site Health” tool in WordPress.
Proactive Measures: Error Prevention and Monitoring
The best way to handle errors is to stop them before your users see them.
Staging Sites are a Must
A staging site is a private copy of your live site. Always test updates on a staging site first. This lets you find issues and fatal errors in a safe place. You do not affect your visitors.
Automated Error Detection and Alerts
You do not have to check logs every day. You can set up systems to tell you automatically.
Monitoring Services: Tools like Sentry, ManageWP, or New Relic can track errors in real time. They can send you an email or a Slack message when a critical problem happens.
Custom Alerts: A developer can set up a custom PHP error handler. This can email you whenever a fatal error is triggered.
Using Logs for Security
Error logs are also a useful security tool. You can spot strange activity by checking your logs.
Failed Login Attempts: You can use a code snippet to log failed logins. This helps you spot brute-force attacks.
add_action( 'wp_login_failed', function( $username ) {
error_log( "Security: Failed login attempt for user '{$username}' from IP " . $_SERVER['REMOTE_ADDR'] );
});
Probing for Vulnerabilities: Your server’s access and error logs might show repeated requests for files that do not exist. This can be a bot scanning your site for weak spots.
Conclusion: From Reactive to Proactive
After you fix the problem, set debugging back to false on your live site.
define( ‘WP_DEBUG’, false );
You now have the skills to fix errors. You can also find complex conflicts and understand deeper server issues. You can use a proactive plan to keep your site healthy and secure.
