Most WordPress problems don’t announce themselves. A plugin throws a PHP warning on every page load, a scheduled task fails silently, or a theme function starts choking on malformed data — and none of it shows up on the front end until weeks later, when something finally breaks in a way a visitor notices. By then you’re troubleshooting under pressure instead of fixing a one-line warning while it was still harmless.
In most sites I build, the single habit that catches issues earliest — well before Site Health flags anything or a client emails to say the site’s down — is simply reading the error log. WordPress already writes one for you; it’s just switched off by default and most people never look at it.
Quick Answer
Turn on WordPress’s built-in debug log by adding two lines to wp-config.php. This writes every PHP error, warning, and notice to a file at wp-content/debug.log without showing them on the live site. Check that file on a regular schedule — weekly is enough for most sites — rather than waiting for something to visibly break.
Why This Matters
A PHP warning that fires on every page load is invisible to visitors but not free — it still costs server resources on every single request, and it’s usually the first sign that a plugin update introduced a compatibility problem. Left alone, small warnings tend to compound: a deprecated function notice today becomes a fatal error the day the underlying PHP version is upgraded and that function is removed entirely.
Error logs also give you a paper trail when something does go wrong. Instead of guessing which of your fifteen plugins caused a 500 Internal Server Error, the log usually names the exact file and line. That turns a stressful guessing exercise into a five-minute fix.
Step-by-Step Instructions
1. Enable WordPress’s built-in debug log
Connect to your site via FTP or your host’s file manager and open wp-config.php in the root WordPress folder. Find the line that says /* That's all, stop editing! Happy publishing. */ and add these lines just above it:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );WP_DEBUG_DISPLAY set to false is the important part — it stops errors from printing directly on the page where visitors (or worse, search engine crawlers) can see them. Everything still gets recorded, just out of public view.
2. Read and interpret the log file
Once enabled, WordPress creates wp-content/debug.log the next time an error occurs. Open it with any text editor or your host’s file manager. Each line follows a similar pattern: a timestamp, an error type (Notice, Warning, Deprecated, or Fatal error), a description, and the file and line number where it happened.
Fatal errors need attention immediately — they’re usually what’s causing a white screen of death or a broken page. Notices and deprecated warnings are lower priority but worth tracking, since they tend to point at a plugin that hasn’t been updated to match your current PHP version.
3. Check your host’s server-level error logs too
WordPress’s debug log only covers PHP inside WordPress itself. Server-level issues — memory limit failures, timeouts, or problems that happen before WordPress even loads — show up in your hosting control panel instead, usually under a section called “Error Logs” or “Raw Access Logs.” Most hosting dashboards separate this from the WordPress admin area entirely, so it’s worth checking both if the WordPress log looks clean but something’s still wrong.
4. Set up regular log review or automated alerts
A log nobody reads doesn’t help. Add a recurring reminder — weekly for a small site, daily if you’re running WooCommerce or handling regular traffic — to skim the file for anything new. If you’d rather not check manually, several security plugins can email you when a fatal error is logged, which is usually enough to catch the problems that actually matter without adding another daily task.
5. Clear and rotate the log so it doesn’t grow unmanaged
debug.log has no built-in size limit and will keep growing indefinitely if left alone — on a busy site with a recurring warning, it can reach hundreds of megabytes within weeks. After reviewing it, delete the file (WordPress recreates it automatically) or move it aside so you’re always looking at a fresh window of activity rather than scrolling through months of old entries.
Practical Tips
- Turn debug logging off (or at least set WP_DEBUG back to false) once you’ve resolved an issue you were actively chasing — leaving it on indefinitely just means a bigger file to sift through later.
- If wp-content/debug.log is publicly accessible at that URL, block it via your host’s file manager or a simple rule in your server configuration — it can leak file paths and plugin details to anyone who finds it.
- Cross-reference the timestamp of a logged error with your list of recent plugin or theme updates. Errors that start right after an update almost always trace back to that specific change.
Common Mistakes
- Leaving WP_DEBUG_DISPLAY on — this shows raw PHP errors to visitors, which looks unprofessional and can expose your file structure.
- Ignoring notices and warnings entirely — they’re rarely urgent on their own, but a growing pile of them is usually an early sign of a plugin conflict building toward a bigger failure.
- Never clearing the log — an unmanaged debug.log file can grow large enough to affect disk space on shared hosting plans, particularly if one recurring warning is firing on every page load.
When to Use This vs Alternatives
The built-in debug log is the right starting point for any site, since it costs nothing and needs no extra plugin. For sites where you want a broader health check rather than raw error output, pair it with the WordPress Site Health tool, which flags configuration and performance issues the debug log won’t catch. Larger or client-facing sites often benefit from a dedicated monitoring plugin that emails alerts automatically — worth the setup time once a site is generating meaningful traffic or revenue, but overkill for a small personal blog where a weekly manual check is plenty.
For a wider view of how ongoing upkeep like this fits into running a WordPress site, see the step-by-step guide to building a WordPress website.
WordPress.org’s own developer documentation covers the full set of debug constants available beyond the two used here, including options for logging to a custom file location: Debugging in WordPress.
Conclusion
Turning on WordPress’s debug log takes two minutes and gives you visibility into problems long before they become visible failures. Check it on a regular schedule, act on fatal errors immediately, and clear it out periodically — that’s the whole system, and it’s usually enough to catch trouble while it’s still a one-line fix.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.