Enable WP_DEBUG and read the error log

Turn on WordPress debug logging to find the source of a white screen or a broken plugin, without showing errors to your visitors.

WP_DEBUG makes WordPress record the errors it would otherwise hide. It is the first step in diagnosing a white screen, a fatal error, or a plugin that does not behave. Applies to all WordPress sites.

Errors are written to a log file, not shown on the page — which is what makes this safe to use on a live site.

Edit wp-config.php

wp-config.php is in your site's root folder, normally public_html. Open it with cPanel's File Manager or an FTP client.

Opening wp-config.php for editing

Find the existing line:

define( 'WP_DEBUG', false );

Replace it with:

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

// Log errors to wp-content/debug.log
define( 'WP_DEBUG_LOG', true );

// Do not display errors to visitors
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

The debug constants added to wp-config.php

These lines must go above the comment /* That's all, stop editing! */. Anything after it is ignored, and the most common reason debugging appears not to work is that the constants were added at the bottom of the file.

If WP_DEBUG is not defined anywhere in the file, add the block above that comment.

WP_DEBUG_DISPLAY must stay false

WP_DEBUG_DISPLAY set to true prints errors into the page HTML for every visitor, including file paths and, on some errors, database detail. Leave it false and read the log.

SCRIPT_DEBUG

Some guides add define( 'SCRIPT_DEBUG', true );. That makes WordPress load unminified core JavaScript and CSS, which is only useful if you are debugging core files themselves. Leave it out otherwise — it slows every page load.

Reproduce the problem

Save the file, then go back to the site and do whatever caused the error. Nothing is logged until the error happens again.

Read the log

Open wp-content/debug.log.

Each entry gives the error, the file path and the line number. Work from the oldest entry, not the newest — a single fatal error usually cascades into several follow-on warnings, and the first one names the real cause.

A path under wp-content/plugins/some-plugin/ points at that plugin. Deactivate it and see whether the error stops.

Turn it off afterwards

Set WP_DEBUG back to false and delete wp-content/debug.log.

debug.log sits inside the web root and can be readable over the internet at example.com/wp-content/debug.log. It contains file paths and can contain query fragments. Delete it when you have finished, and do not leave debugging enabled on a live site indefinitely — the file grows without limit.