WordPress Debug Log Checklist

Quick Answer

A WordPress debug log checklist should confirm the incident scope, backup status, access owner, wp-config.php change, WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, log-file location, private-data handling, Site Health warning, cleanup step, and follow-up decision before an operator changes production debugging settings. For a small publishing site, the best fit is temporary log capture with public display disabled, a short error-summary note, and a hard reminder to turn debug mode off after the review.

Debug Log Decision Matrix

Situation	Better choice	Avoid
Public pages still load but warnings appear	Capture a short debug window and review the log privately	Leaving debug display visible to visitors
Admin or editor breaks after a plugin change	Pair the log with a plugin-conflict checklist	Updating multiple plugins before reading the first error
Site Health flags debug mode	Confirm whether logging is still needed, then turn it off	Treating debug mode as a permanent maintenance setting
PHP upgrade caused new errors	Capture baseline, log timestamped errors, and compare after rollback or fix	Blaming PHP without recording the WordPress, theme, and plugin context
Host support asks for details	Share a redacted error summary and timestamps	Pasting full logs with paths, tokens, emails, or private payloads

Who Should Use This Checklist?

Use this checklist when a WordPress operator needs to investigate plugin conflicts, theme warnings, PHP runtime changes, failed admin actions, AJAX issues, cron-related warnings, editor errors, or recurring Site Health debug warnings. It fits small editorial sites where the same person may handle content, plugins, hosting tickets, and update notes.

This is not a vulnerability scan, managed hosting runbook, or professional incident-response guide. It is a source-aware operating checklist for deciding when to collect WordPress debug evidence and when to stop collecting it.

WordPress documentation describes debugging constants that can be set in wp-config.php. WP_DEBUG enables WordPress debugging behavior, WP_DEBUG_LOG writes errors to a log file, and WP_DEBUG_DISPLAY controls whether errors are shown on pages. Site Health can also warn when debug information may be exposed or left enabled. The practical operator rule is simple: log privately, display nothing publicly, collect only enough evidence to make the next decision, then disable the temporary setting.

This article is source-derived analysis from official WordPress documentation. It does not claim that Yolkmeet inspected a private WordPress dashboard, production log file, host control panel, wp-config.php, user account, plugin setting, database, or server filesystem.

Step 1: Decide Whether Debug Logging Is Needed

Do not enable logging just because a site feels slow or confusing. Start with the symptom and the decision the log is supposed to support.

• [ ] Name the visible symptom: blank page, editor error, plugin warning, failed upload, failed scheduled task, AJAX issue, admin notice, or Site Health warning.
• [ ] Record when the symptom started.
• [ ] Record the most recent change: plugin update, theme update, PHP change, cache change, migration, form change, or hosting change.
• [ ] Confirm that a backup or rollback path exists before editing configuration.
• [ ] Decide who can access wp-config.php safely.
• [ ] Decide who will read the log and turn debug mode off afterward.

This first step keeps the workflow narrow. A debug log is useful when it helps identify a failing plugin, theme file, PHP warning, cron callback, AJAX request, or runtime mismatch. It is not useful when nobody will read the output or when the operator cannot safely edit the configuration back.

Step 2: Set The Debug Constants Safely

For a public site, the safer pattern is to log errors privately and avoid showing them to visitors. WordPress documentation describes the related constants in wp-config.php; the operator should treat that file as sensitive because it can also contain database credentials and environment settings.

Use this configuration checklist:

• [ ] Edit wp-config.php through the host-approved file manager, SSH session, deployment workflow, or support path.
• [ ] Set WP_DEBUG only for the review window.
• [ ] Set WP_DEBUG_LOG so errors can be reviewed after the request.
• [ ] Set WP_DEBUG_DISPLAY to keep errors off public pages.
• [ ] Do not paste secret values, credentials, salts, database details, or raw log contents into public notes.
• [ ] Save the exact time debugging was enabled.

The exact implementation belongs in the operator's private runbook, not in the public article body. Public content should explain the decision pattern, not expose site-specific file paths, credentials, or stack traces.

Step 3: Capture A Small Evidence Window

The log should answer a specific question. Keep the evidence window small enough that the next operator can read it.

Evidence field	What to record	Why it matters
Start time	When debug logging was enabled	Separates old warnings from current symptoms
Trigger action	Page load, editor save, form submit, upload, cron event, or plugin action	Connects a log line to the visible behavior
WordPress context	WordPress version, active theme, PHP version, and key plugin changed	Helps compare with Site Health and update notes
Error summary	Redacted message type, plugin/theme path pattern, timestamp, and repeat count	Gives support enough context without leaking secrets
Stop time	When debug mode was disabled	Proves logging did not become permanent

Avoid collecting broad logs for days. The longer a public site keeps debug logging active, the higher the chance that paths, internal filenames, plugin details, or user-related data appear in a place the team did not intend to monitor.

Step 4: Compare The Log With Site Health

The Site Health screen is useful because it exposes configuration and environment signals in one place. It can show status issues and technical details about WordPress, themes, plugins, media handling, server setup, database, constants, and filesystem permissions. It can also warn when debug information is enabled.

Use Site Health to sort the next action:

• [ ] If Site Health flags debug mode, decide whether the current review still needs it.
• [ ] If Site Health also flags REST API, loopback, update, filesystem, or PHP issues, record those alongside the log.
• [ ] If the log points to a plugin, use a plugin-conflict workflow before changing unrelated settings.
• [ ] If the log points to a theme template or block rendering issue, use a theme or template audit workflow.
• [ ] If the log points to PHP compatibility, use a PHP upgrade or rollback note.
• [ ] If Site Health is clean but the log repeats, document the specific trigger and owner.

Site Health is not a repair button. It is a triage surface. The best operator decision is the smallest reversible change that matches the evidence.

Step 5: Redact Before Sharing

Debug logs can include file paths, plugin names, email addresses, request details, database messages, or other internal data. Treat the log as private until it has been reviewed and redacted.

• [ ] Keep the raw log in an operator-only location.
• [ ] Share summaries instead of full log dumps when possible.
• [ ] Remove secrets, tokens, salts, database names, user emails, IP addresses, private URLs, and raw form submissions.
• [ ] Preserve enough context to identify the component and timestamp.
• [ ] If host support needs the raw log, use the host's private support channel.
• [ ] Do not attach raw logs to public WordPress posts, comments, source notes, or issue examples.

The useful public summary usually looks like: component, timestamp, error type, repeat count, triggering action, and next owner. It does not need the full stack trace unless the private support workflow requires it.

Step 6: Turn Debug Mode Off And Record The Decision

The cleanup step is part of the checklist, not an optional afterthought. WordPress Site Health documentation notes that debug information may disclose details or be left enabled after troubleshooting. Operators should treat a debug session as unfinished until it is closed.

• [ ] Turn off temporary debug settings when the evidence window ends.
• [ ] Confirm public pages do not show error output.
• [ ] Confirm the log file is not linked from public content or exposed by a plugin setting.
• [ ] Recheck Site Health if it previously warned about debug mode.
• [ ] Record the final decision: plugin follow-up, theme follow-up, PHP follow-up, host ticket, rollback, monitor, or no action.
• [ ] Add a review date if the same warning repeats.

For publishing operations, the best outcome is not a giant log. The best outcome is a clear next action: update a plugin, roll back a theme change, change PHP after staging, ask the host about server errors, or close the incident because the warning stopped after a reversible change.

What Should A WordPress Debug Log Checklist Include?

A WordPress debug log checklist should include the symptom, recent change, backup status, wp-config.php owner, WP_DEBUG setting, WP_DEBUG_LOG setting, WP_DEBUG_DISPLAY setting, logging start time, trigger action, redaction rule, Site Health review, stop time, cleanup confirmation, and follow-up owner.

The practical order is: decide whether logging is needed, enable only the needed debug constants, capture a short evidence window, compare the log with Site Health, redact before sharing, turn debug mode off, and record the next action.

Common Questions

Should WordPress debug display be enabled on a public site?

For a public publishing site, avoid showing debug output to visitors. Use private log capture for the review window and keep public display disabled unless a controlled development environment specifically requires on-screen debugging.

Is a debug log the same as Site Health?

No. A debug log captures runtime warnings and errors. Site Health summarizes status and configuration signals. Use them together: the log can point to a component, while Site Health can show whether the environment also has update, PHP, filesystem, REST API, loopback, or debug-mode warnings.

How long should debug logging stay enabled?

Only as long as needed to capture the symptom and make the next decision. For recurring issues, record a short scheduled window and owner instead of leaving debugging on indefinitely.

What should be shared with host or plugin support?

Share a redacted summary first: timestamp, component, error type, trigger action, WordPress version, PHP version, active theme, and relevant plugin. Share raw logs only through a private support channel when required.

What if Site Health warns that debug mode is enabled?

Treat that as a cleanup trigger. If an active review still needs logging, record the reason and end time. If no review is active, turn debug mode off and confirm the warning clears after the next check.

Source Notes

• https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/ checked 2026-06-10; used for source-derived analysis of WordPress debugging constants, WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, script debugging, and private log review.
• https://developer.wordpress.org/advanced-administration/wordpress/wp-config/ checked 2026-06-10; used for source-derived analysis of wp-config.php as the configuration surface for debugging and other environment constants.
• https://wordpress.org/documentation/article/site-health-screen/ checked 2026-06-10; used for source-derived analysis of Site Health status, Info fields, WordPress constants, server details, database details, filesystem permissions, and operator triage.
• https://developer.wordpress.org/reference/classes/wp_site_health/get_test_is_in_debug_mode/ checked 2026-06-10; used for source-derived analysis of WordPress debug-mode warnings, possible information exposure, public log accessibility, and the risk of leaving debugging enabled.
• https://developer.wordpress.org/themes/advanced-topics/debugging/ checked 2026-06-10; used for source-derived analysis of theme debugging, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, and storing debug output in the wp-content debug log.

No private WordPress dashboard, wp-config.php, debug log, filesystem, server error log, host control panel, database, plugin configuration, support ticket, Site Health export, production URL test, user record, or credential was inspected for this article. If a future operator adds redacted logs, screenshots, host tickets, or controlled staging evidence, attach those artifacts in the internal runbook and narrow public claims to match that evidence.

Internal Link Notes

Link to wordpress-site-health-review-checklist when the debug session starts from a Site Health warning. Link to wordpress-plugin-conflict-troubleshooting-checklist when the log points to a plugin or hook conflict. Link to wordpress-php-version-upgrade-checklist when warnings appear after a runtime change. Link to wordpress-backup-restore-checklist before editing configuration or rolling back. Link to wordpress-security-checklist-for-blogs when debug exposure becomes an access or information-disclosure concern.

Update Note

Review this checklist every 60 days. Recheck official WordPress debugging documentation, wp-config.php documentation, Site Health documentation, Site Health debug-mode reference, and theme debugging documentation before changing the workflow. Refresh earlier after a WordPress core release, host logging change, PHP version change, Site Health behavior change, plugin incident, theme incident, or accidental public debug-output exposure.