When a live WordPress site starts throwing 500s, white screens, broken checkout steps, or random admin errors, the wrong move is to turn on noisy debugging in public and hope for the best. The better move is to collect evidence quickly, keep customer-facing pages clean, and narrow the problem to code, configuration, or cache. For business owners, operations leads, and agency teams, that usually means a short, controlled debugging window, not an open-ended experiment.
WordPress' current developer docs are clear on two points: debug tools are mainly meant for local or staging environments, and if you must use them on a live site, errors should be logged rather than displayed in page HTML. That distinction matters because public error output can expose file paths, plugin names, server details, and broken layouts right when users are trying to buy, log in, or submit a form.
Start with the safe version of debug mode
Before editing anything, make sure you have a fresh backup or a staging copy, note the time the issue started, and list the most recent changes: plugin updates, theme releases, hosting changes, CDN rules, cron jobs, or DNS moves. Then edit wp-config.php and place the following block before the line that says /* That's all, stop editing! Happy blogging. */.
// Log WordPress and PHP issues without showing them to visitors.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // Or use a custom path outside the public web root.
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
// Only enable this if you are tracing core JS/CSS issues.
define( 'SCRIPT_DEBUG', true );This keeps errors out of the rendered page while sending them to wp-content/debug.log. If your host allows it, a custom log path outside the public site root is even better. WordPress also supports that pattern directly through WP_DEBUG_LOG.
What changed from older advice
Older snippets often enable WP_DEBUG_DISPLAY and display_errors on a live site. That is not the version I would use in production. It is fine on local or staging, but on a public site it creates unnecessary risk and can make a user-visible problem worse. Current WordPress guidance prefers logging with display disabled when you need to investigate safely.
I would also avoid treating define( 'WP_CACHE', false ); as a universal debugging switch. In real projects, caching is usually spread across multiple layers: a WordPress plugin, an object-cache drop-in, server-side page cache, CDN cache, and sometimes browser cache. Flipping one constant may do nothing useful, or it may create false confidence that caching is off when it is not.
Use cache clearing and isolation deliberately
If the issue looks stale or inconsistent across visitors, clear the actual cache layer involved instead of changing unrelated constants. If you have WP-CLI access, the standard object cache command is:
wp cache flushThat flushes the object cache, but WordPress warns it can affect all sites in a multisite install and has a production performance cost. It also does not replace clearing CDN or full-page cache rules in Cloudflare, your host, or a caching plugin.
If the error appeared right after a plugin deployment or update, isolate that variable quickly. WP-CLI makes this safer and faster than clicking around in a broken admin panel:
wp plugin deactivate plugin-slug
wp plugin deactivate --all --exclude=critical-pluginThe first command tests a likely culprit. The second is a broader isolation pass when you need to rule out plugin conflicts fast without taking down absolutely everything. That is often the quickest way to tell whether you are looking at a plugin issue, a theme issue, or an infrastructure problem.
A practical triage sequence
- Reproduce the problem once or twice with logging enabled. Do not leave debugging on for longer than needed.
- Open
wp-content/debug.logor your custom log file and look for timestamps that match the failure window. - Separate fatal errors from noise. Deprecation warnings matter, but they rarely explain a sudden outage on their own.
- Check whether the failing path is frontend, admin, AJAX, cron, checkout, or a specific integration. That tells you where to narrow the search.
- If the issue is visual or JavaScript-related in WordPress core admin screens, use
SCRIPT_DEBUGtemporarily so unminified core assets load. - If your stack uses
WP_ENVIRONMENT_TYPE, define production settings explicitly. WordPress notes that adevelopmentenvironment type can turn onWP_DEBUGwhen it is not otherwise defined.
Turn it back off cleanly
Once you have the evidence you need, switch the site back to normal production behavior. A clean rollback matters just as much as the debugging window itself.
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
define( 'SCRIPT_DEBUG', false );Then archive or delete the log file. WordPress' own documentation warns that logs in publicly accessible locations are a security risk. If you had to debug directly on production, keep the window short, document what you found, and move the deeper fix to staging if the root cause is not obvious.
When it makes sense to bring in help
If the problem touches checkout, memberships, multilingual plugins, search, cron jobs, object caching, or a multisite setup, fast diagnosis usually pays for itself. The expensive part of WordPress outages is rarely the five-line config change; it is the lost time spent guessing between theme code, plugin conflicts, server behavior, and cache layers.
If you need a practical second pair of eyes, Greg can help you triage the issue, protect the live site, and turn the findings into a clear fix plan your team can act on.
Need help with this kind of work?
Need help debugging a live WordPress issue without making it worse? Greg can triage it and turn the findings into a clear action plan. Get in touch with Greg.