Debugging WordPress on a Live Site: A Safer Workflow

By Greg Nowak. Last updated 2026-07-16.

When a live WordPress site starts returning 500 errors, showing blank pages, or breaking checkout, every diagnostic change carries business risk. The objective is not simply to “turn debugging on.” It is to gather useful evidence during a short, controlled window while keeping technical details away from customers.

The following workflow helps business owners, operations leads, and agency teams investigate production problems without turning one fault into several. If the issue can be reproduced on staging, work there. When it only happens in production, make one change at a time and agree on a rollback point before starting.

Protect the site before changing anything

Confirm that you have a recent, restorable backup. Then record the time the problem started, the affected URL or user journey, and the most recent changes. Include plugin and theme updates, deployments, PHP upgrades, hosting changes, scheduled jobs, CDN rules, and third-party integrations.

Test the failure once before changing the configuration. Note whether it affects everyone or only particular users, browsers, locations, account types, or transactions. Those details often reveal more than a large undifferentiated error log.

Log errors without displaying them

WordPress recommends using its debugging tools on local or staging installations rather than live sites. When production debugging is unavoidable, edit the existing debug definitions in wp-config.php—do not create duplicates—and place them before the stop-editing comment:

// Temporary production diagnostics: log, but do not display.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

This normally writes messages to wp-content/debug.log without adding them to rendered pages. PHP’s own documentation also recommends logging instead of displaying errors on production systems.

The default log location may be accessible from the web. Where your server permits it, set WP_DEBUG_LOG to an absolute path outside the public document root:

define( 'WP_DEBUG_LOG', '/secure/path/wp-errors.log' );

Use a path that the PHP process can write to, restrict access, and remove or archive the file when the investigation ends. Logs can contain internal paths, email addresses, request data, and integration responses, so treat them as sensitive operational records.

Read the failure window, not the whole log

Reproduce the problem once, note the exact time, and inspect entries from that window. Prioritise fatal errors and exceptions that align with the failed request. Notices and deprecation warnings deserve maintenance work, but they do not necessarily explain today’s outage.

If debug.log remains empty, inspect the hosting control panel or server-level PHP error log. A syntax error or startup failure can happen before the runtime ini_set() call takes effect, so the WordPress log is not the only source of evidence.

What you observe	Investigate first	Controlled next test
The failure began after an update	The plugin, theme, or file named in the fatal error	Deactivate the likely component and reproduce once
Output differs between visitors	Page cache, CDN, object cache, then browser cache	Purge the relevant layer and retest the same URL
A form or checkout fails	PHP log, browser network response, and integration logs	Use a safe test transaction or staging reproduction
Scheduled work fails	Cron events, loopback requests, and queue logs	Run the specific job under controlled conditions
Core admin JavaScript is broken	Browser console and network panel	Temporarily enable `SCRIPT_DEBUG`

A focused triage matrix helps prevent unrelated production changes from obscuring the original fault.

Isolate plugins carefully with WP-CLI

If wp-admin is unavailable, WP-CLI can deactivate a suspected plugin without relying on the browser:

wp plugin deactivate plugin-slug

For broader isolation, first record what is active. During an agreed maintenance window, you can deactivate plugins while preserving an essential component:

wp plugin list --status=active
wp plugin deactivate --all --exclude=critical-plugin

Bulk deactivation can interrupt payments, forms, security controls, authentication, caching, and multilingual routing. On a commercial site, it is an incident action rather than a casual test. Start with the component named by the evidence and reactivate known-good plugins promptly.

If a normal plugin prevents WP-CLI from loading WordPress, the global --skip-plugins parameter can help the command start. Must-use plugins still load, however, so this option does not isolate everything.

Clear the cache layer you actually mean

Do not treat WP_CACHE as a universal cache switch. WordPress documents it as a setting that loads wp-content/advanced-cache.php; it does not automatically disable a hosting cache, CDN, persistent object cache, or browser cache.

WP-CLI can flush the WordPress object cache:

wp cache flush

That command does not purge every other cache layer. On multisite installations using a persistent object cache, it will typically affect every site and may create a production performance spike. Identify the cache owner and scope first. A targeted page or CDN purge is preferable when the symptom is limited to one URL.

Use deeper diagnostics only when justified

Leave SCRIPT_DEBUG off unless you are tracing WordPress core JavaScript or CSS. It loads development versions of core assets and is not required for ordinary PHP debugging. Likewise, avoid enabling SAVEQUERIES casually on production because collecting every database query adds overhead.

Check WP_ENVIRONMENT_TYPE as well. If WordPress sees the environment as development and WP_DEBUG has not been defined explicitly, it can enable debugging automatically.

Close the debugging window cleanly

Once you have enough evidence, restore the existing configuration rather than adding another block:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
define( 'SCRIPT_DEBUG', false );

Remove or secure the temporary log, restore deactivated plugins, clear only the caches affected by the fix, and test the original customer journey. Record the cause, evidence, changes, and follow-up work so the next person does not have to repeat the investigation.

If payments, memberships, personal data, multisite, recurring jobs, or shared caching are involved, early escalation is usually cheaper than prolonged production experimentation. Greg can help contain the issue, distinguish application faults from infrastructure symptoms, and turn the evidence into a practical repair plan. Get in touch to discuss the site and its current symptoms.