Enable WordPress Debug Logging Safely

Collect useful error details without exposing them

A blank page or failed save gives you little to send to support. An error log can record what happened behind that visible symptom, including the component involved and the time of the failure. The procedure below keeps that evidence away from public pages, explains how to collect one useful example and includes the cleanup needed after diagnosis.

Site Health warning that errors are displayed to visitors and a log can be publicly accessible — This unchanged WordPress documentation example shows the warning associated with public error output and a potentially exposed log. The procedure below uses hidden error output and a host-confirmed private log location. Absence of this warning does not prove that a log is protected. Credit: WordPress Documentation Team, CC0.

Check the host's log before editing files

Sign in to the hosting account, select the affected website and look for PHP logs or an Errors screen. Ask hosting support to locate the entry for the failed page if you cannot find it. Give them the page address, action and time, including your time zone. An existing error message can save you a configuration change.

Use a private staging copy for deliberate debugging. WordPress advises against leaving debug tools enabled on a live site. If the issue only occurs live, arrange a short controlled investigation with your host or developer, including how the log will be protected and removed.

Prepare a private log and a recovery copy

You need hosting File Manager or SFTP access, permission to edit this site's configuration and a current backup. Open the site's document root, the directory containing wp-admin and wp-content. Find wp-config.php there or in the parent directory. Our configuration file guide explains its role.

Download a copy of that file to secure storage before editing it. It contains credentials: do not leave a renamed backup in the public website directory or attach it to a public support post. Keep File Manager open so you can upload the original if the edit stops the site loading.

Ask your host for a writable absolute file path outside every public document root for this site. An absolute path is the full server location, not a web address. The example below deliberately contains a placeholder. If your hosting plan does not expose a private writable location, have the host collect the diagnostic log instead.

Add the diagnostic settings once

Use File Manager's text editor to open wp-config.php. Search separately for WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY. Update an existing definition rather than adding another. Insert missing definitions above the line containing That's all, stop editing! and before WordPress loads its settings.

Replace /HOST-CONFIRMED-PRIVATE-PATH/wordpress-errors.log with the exact location supplied by your host. Keep straight quote marks around the path. The values true and false have no quote marks. Do not add another opening PHP tag.

php

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/HOST-CONFIRMED-PRIVATE-PATH/wordpress-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reproduce the problem once

Save the file, then check the homepage. If the edit creates a new error, restore your saved configuration file immediately and ask for help checking the edit.
Note the time and repeat the original failing action once. Use a test draft for an editor error. Avoid repeating a real payment or customer email just to create a log entry.
Open the private log location in File Manager. Refresh its directory listing if necessary, then download or view the text file through the authenticated hosting tools.
If the file is missing or empty, stop and ask the host to check the path, write permissions and its own PHP log. An empty log does not establish that the site is healthy.

Read the message without editing the named file

Match the entry's timestamp to your test, allowing for the server's time zone. A Fatal error reports a request that could not finish; a Warning or Deprecated entry alone does not prove it caused your symptom. Record the message and component name. Do not paste the full log into a public forum.

A path under wp-content/plugins/ points to a plugin involved in the failure. Use the plugin conflict guide to investigate it. An allowed memory size exhausted message leads to memory troubleshooting; a parse error leads to syntax-error recovery. The filename is evidence for the investigation, not an instruction to change unfamiliar PHP.

Turn logging off and remove the diagnostic file

After collecting the required evidence, edit the same definitions so WP_DEBUG and WP_DEBUG_LOG are false. Leave WP_DEBUG_DISPLAY as false and keep displayed errors disabled. Restore any additional diagnostic settings you changed to their recorded values.

Save, check the homepage and dashboard, and securely retain only the relevant evidence needed for support. Remove the diagnostic file from its private location when it is no longer required. Confirm it does not reappear after a normal page visit. If logging continues, ask your host which other setting is writing it.

Reference material

These settings are described in WordPress debugging documentation. Hosting-specific paths and access controls must come from your hosting provider.

Get help with the next step

If the error message is unclear or the site cannot be tested without affecting customers, ask BugShield to investigate. Tell us which action fails and what the host has confirmed; a developer can assess the next step without asking you to experiment with unfamiliar code.

Questions answered

How to enable WordPress debug logging FAQs

Where is the WordPress debug log in this guide?

It is at the private absolute path agreed with your host and placed in WP_DEBUG_LOG. This guide deliberately avoids the public wp-content/debug.log default. Use authenticated hosting tools to read it.

Can I enable logging from the WordPress dashboard?

A host or diagnostic plugin can provide controls, but their protection and settings differ. The procedure here uses the configuration file. Ask your host to collect the log if file editing is outside your access or experience.

Why is no log file being created?

The action may not produce a PHP message, the path may be wrong, or the hosting configuration may prevent writing there. Check the host's PHP log and permissions with support instead of opening access to everyone.

Should I share the whole error log with a plugin author?

Share only the relevant excerpt through the author's private support channel. Remove passwords, tokens, customer information and private links. Keep the error type, component and timing needed to investigate.

Does a warning mean my site is unsafe?

A warning is a diagnostic message, not a security assessment. Relate it to the failed action and have the component maintainer investigate. Neither a warning nor an empty log establishes the site's security.

Keep troubleshooting

How to enable WordPress debug logging