Introduction

When a WordPress site shows a blank page, a plugin error, or intermittent failures, the fastest way to diagnose the problem is the error log. This guide shows multiple, practical ways to find and access WordPress error logs   from enabling WordPress’ own debug log to checking Apache/Nginx and PHP logs on your host. Follow the exact steps below that match your setup (shared hosting, VPS, local dev), reproduce the error, and read the logs to pinpoint the issue.

1) Quick safety note before you begin

• Never leave debugging enabled on a live production site long term  logs can contain sensitive info.

• Always set WP DEBUG DISPLAY to false and use WP DEBUG LOG to write to a file when debugging live sites.

• Back up wp config.php before editing.

2) Enable WordPress debug logging (best first step)

Add the following to your wp-config.php above the line /* That's all, stop editing! Happy blogging. */:

define( 'WP DEBUG', true );

define( 'WP DEBUG LOG', true );      // writes to wp content/debug.log

define( 'WP DEBUG DISPLAY', false ); // hides errors from visitors

@ini set( 'display errors', 0 );

• After this, WordPress will write PHP notices/warnings/errors to wp content/debug.log.

• Reproduce the problem and then open wp content/debug.log to view entries (via File Manager, FTP, or SSH).

When finished debugging, turn WP DEBUG off:

define( 'WP DEBUG', false );

3) Where server & PHP error logs usually live (common paths)

Depending on your server, look in one of these locations (you may need SSH or hosting file manager):

• Apache (Debian/Ubuntu): /var/log/apache2/error.log

• Apache (CentOS/RedHat): /var/log/httpd/error_log

• Nginx: /var/log/nginx/error.log

• PHP-FPM: /var/log/phpX.Y fpm.log or /var/log/php fpm/error.log (replace X.Y with your PHP version)

• cPanel: /usr/local/apache/logs/error log or use cPanel → Metrics → Errors
  Plesk: Domains → your domain → Logs tab

• Shared hosting (no SSH): many hosts expose logs via the control panel (cPanel/Plesk/DirectAdmin)  look for “Error Logs” / “Raw Access”.

If unsure, create a phpinfo() page to find error log or error log directive location:

1. Create phpinfo.php in your webroot with <?php phpinfo(); ?>

2. Visit it in the browser and search for error log (then delete the file after).

4) Accessing logs via SSH (tail, less, grep)

If you have SSH access, these commands are invaluable:

• Stream live errors (watch as you reproduce the problem):

sudo tail f /var/log/nginx/error.log

sudo tail  f /var/log/apache2/error.log

• View the last 200 lines:

sudo tail  n 200 /var/log/apache2/error.log

• Search for recent PHP errors mentioning your file or plugin:

sudo grep  i "plugin name" /var/log/apache2/error.log

sudo journalctl  u php7.4 fpm  n 200

5) Accessing logs without SSH (cPanel / Plesk / Host dashboards)

• cPanel: Login → Metrics → Errors (short view) or File Manager → public_html/wp content/debug.log. Some hosts also provide Raw Access downloads.

• Plesk: Domains → your domain → Logs → filter by error, warning.

• Managed WordPress hosts (WP Engine, Kinsta, SiteGround): dashboards usually expose logs and slow query traces; check host docs.

6) Local dev environments (XAMPP, MAMP, LocalWP)

• XAMPP (Windows/Linux): Apache logs in xampp/apache/logs/error.log, PHP errors often in xampp/php/logs.

• MAMP (macOS): Logs in /Applications/MAMP/logs/.

• LocalWP: Use the GUI to open logs for each site (local MySQL, nginx/apache, PHP FPM logs).

7) Advanced: set a custom PHP error log file

If you want a dedicated log path (helpful on multi site or restricted hosts), add to wp config.php or php ini (requires host support):

@ini set( 'log errors', 1 );

@ini set( 'error log',  DIR . '/wp-content/my-php-error.log' );

Or in php.ini:

log errors = On

error log = /path/to/logs/php-errors.log

Make sure the webserver user can write to the file/directory (correct ownership and permissions).

8) Common troubleshooting checks when logs are empty

• Did you enable WP DEBUG LOG and reproduce the error?

• Is debug.log writable? (chmod 644 usually OK; owner should be webserver user).

• Are you looking at the correct date/time  check timestamps.

• Are PHP errors suppressed by display errors = Off and log errors = Off in php.ini? Enable logging.

• If using a caching plugin, clear cache and reproduce the issue.

9) How to read logs and act on entries (practical tips)

• Look for the timestamp matching when you reproduced the issue.

• Identify the error type (Fatal error, Warning, Notice). Fatal errors break execution (highest priority).

• Note the file path and line number in the stack trace (e.g., /wp content/plugins/plugin name/file.php on line 123). That tells you which plugin/theme to inspect.

• Google the error message or search WordPress.org forums   many errors are common and already solved.

10) After debugging: secure and cleanup

• Turn off WP DEBUG (set to false) and remove any phpinfo.php pages.

• Delete or rotate logs containing sensitive data. Use logrotate on servers to avoid huge files.

• If you created custom log files, keep them outside document root if possible.

Conclusion

Finding and accessing WordPress error logs is the single most effective way to diagnose site issues. Start by enabling WP DEBUG LOG to capture WordPress level errors, then check server PHP/Apache/Nginx logs for deeper issues. Use SSH commands to tail logs in real time, or rely on your host’s control panel if SSH isn’t available. For reliable performance and easier troubleshooting, choosing a trusted hosting provider like ARZ Host ensures you always have smooth access to logs, security features, and the support needed to keep your site running at its best.