Something went wrong while you were using a plugin (a freeze, an endless spinner, a button that does nothing), or your site shows a blank screen or a “critical error”? Checking your PHP error logs is the first thing to do. WordPress is loud about its errors if you let it talk. Most people don’t, and they end up guessing.
The PHP error log is not your web server’s access or error log (Apache, Nginx). Those are about requests to your server. The one you want is about PHP, the code WordPress and its plugins run on.
What is the PHP error log?
It’s a plain text file where PHP writes down every problem it runs into: programming errors, but also memory, disk space and timeout issues. When a page breaks, it almost always tells you why, and where.
Don’t worry if it’s never empty. Warnings, notices and deprecation messages are logged too, and most of them are harmless. What matters are the lines written at the moment your problem happened, and above all the ones that say Fatal error.
Where to find the PHP error log
In your hosting panel
Usually, you can reach it through the admin panel of your hosting service (not the WordPress one: it can be Plesk, cPanel, or the host’s own system). For example:
- SiteGround: open Site Tools, then Site, then File Manager. You’ll find a folder called logs. For PHP errors specifically, look in the public_html folder of the domain for a php-errors.log file.
Through WordPress directly
If you’re lucky, you can read the log from inside WordPress. Whether it works depends on your hosting service. If the file is not found, or is empty, logging is probably disabled: turn it on with the wp-config.php settings below. If you still can’t find it, or it stays empty while you have issues, ask your hosting service for access to your PHP error logs (good hosts will help you troubleshoot at the same time).
With the Meow Apps Dashboard. Every Meow Apps plugin includes it (it’s a common library shared by all of them). Open Meow Apps → Dashboard and load the error logs: it reads the file PHP is writing to, splits it into separate errors, warnings and notices, and colors them so the serious ones stand out. It’s the simplest way to check.
With a dedicated plugin. A few plugins are made just to read the PHP error log. They work like the Meow Apps Dashboard, usually a bit simpler: they show whatever is in the file. You can try Error Log Monitor.
Turn on the PHP error log through WordPress
WordPress can write every error to a file for you, as long as your host allows it (most do). Add this to your wp-config.php file, right above the /* That’s all, stop editing! Happy publishing. */ line (older files say “Happy blogging”).
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Log errors to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Don't show errors to visitors
define( 'WP_DEBUG_DISPLAY', false );Errors now go to /wp-content/debug.log instead of a white screen, and WP_DEBUG_DISPLAY set to false keeps them hidden from visitors while you investigate. These are the settings WordPress itself recommends for debugging.
On many servers, anyone who knows the URL can open /wp-content/debug.log, and it can contain file paths and other details about your site. Turn it off once you’re done, or give WP_DEBUG_LOG a file path outside your public folder instead of true (WordPress supports this since version 5.1).
How to read it
Each line is one problem: when it happened, how serious it is, what went wrong, and exactly where. For example:
[23-Oct-2026 08:14:02 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /wp-content/plugins/some-plugin/includes/import.php on line 142- The date tells you if it matches the moment your problem happened. Old lines are history.
- The type: Fatal error and Parse error stop the page. Warning, Notice and Deprecated usually don’t, but they can hint at the cause.
- The message says what went wrong. Here, PHP ran out of memory.
- The file and line name the culprit. The folder after
/plugins/or/themes/tells you which plugin or theme it is.
Most of the time, the error names the culprit directly. Read it like a sentence, not a wall of text 😺
The order that finds the bug fastest
WordPress is your core install plus a theme plus a pile of plugins plus your own customizations. When something breaks, it is almost always at the seam between two of those. If the log alone doesn’t solve it, follow this order and don’t skip steps.
The order that finds the bug fastest
1. Read the error
If WordPress shows you an error, read it as explained above: file, line, message. If you only see “There has been a critical error on this website”, check the admin email inbox: WordPress usually sends the full error there, with a link to recovery mode so you can still get into your dashboard.
2. Turn on real error logging
No error on screen, nothing in the log? Turn on WP_DEBUG_LOG as shown above, reproduce the problem once, and look at the newest lines.
3. Halve the plugins
If the error doesn’t name a file, the plugin causing it is hiding in your active set. The fastest method is bisection: disable half your plugins. If the problem stops, the cause is in the disabled half; if not, it’s in the other one. Keep halving the guilty half. With 30 plugins you find it in about 5 rounds instead of 30 toggles. On a live site, the Health Check & Troubleshooting plugin lets you do this only for yourself, while visitors keep seeing the normal site.
4. Check the browser side too
If the page looks broken but the PHP log is quiet, the bug is in JavaScript or in a failed request. Open your browser’s developer tools and watch the Console and Network tabs while you reproduce the issue. A red request or a JavaScript exception is usually the bug. Quick guide here.
5. Switch to a default theme briefly
If everything above came back clean and the bug is still there, switch to a default theme like Twenty Twenty-Five for ten minutes. If the problem vanishes, your theme is the cause, and now you know it for sure. Switch back and dig into your theme (often its functions.php).
Common errors we have written about
Asking for help with the error in hand
Once you’ve found the error and the plugin behind it, you can write a support request that gets results. Plugin authors fix bugs fast when you give them the exact error line, the file, and what you were doing. “It doesn’t work” leads to a long back and forth. “Line 142 of import.php throws this fatal error when I click Import” often gets fixed the same week 😺
Still curious where PHP stores its log on different setups? There’s a good discussion on Stack Overflow: Where does PHP store the error log?
