Nearly every WordPress troubleshooting guide reaches the same instruction eventually: turn on debugging. Most of them then give you one line to add, define( 'WP_DEBUG', true );, and move on.
That single line does something the guide usually does not mention. On a default configuration it prints PHP errors and warnings directly onto your pages, where anyone visiting the site can read them. Those messages often include server file paths. On a live site, that is both an embarrassment and an information leak, and it is entirely avoidable.
This page covers the safe version: logging errors to a private file, seeing nothing on the front end, and turning it back off afterwards.
Before you edit anything
You are about to edit wp-config.php. It is the file that holds your database credentials and your security keys, and a site with a broken wp-config.php does not load at all. A single stray character is enough.
Take a copy of the file before you change it. Download it, save it somewhere outside the site, and name it clearly. This is not the same as a site backup and it is not a substitute for one, but it is the specific, thirty-second precaution for this specific edit. If anything goes wrong you upload the copy back and you are exactly where you started.
If you have never edited a file on your server before, the two normal routes are your host's File Manager in their control panel, or an FTP or SFTP client. Both are fine. What is not fine is the dashboard file editor, which does not touch wp-config.php anyway and is a bad habit for other reasons.
The three constants, and what each one does
WordPress reads several debugging constants from wp-config.php. Three of them matter here and they do different jobs, which is exactly the part that gets lost when a guide gives you only the first one.
WP_DEBUG switches debug mode on. On its own, it makes PHP notices, warnings and errors visible.
WP_DEBUG_LOG sends those messages to a file instead of discarding them. With the standard true value, WordPress writes to debug.log inside your wp-content folder.
WP_DEBUG_DISPLAY controls whether the messages are also printed into the page output. This is the one that matters for a live site, and it must be set to false.
Setting the first without the third is the mistake. Setting all three correctly gives you a quiet site and a full log.
The edit
Open wp-config.php and find this line, which sits near the bottom of the file:
/* That's all, stop editing! Happy publishing. */
Everything you add must go above that line. WordPress loads the settings file after that comment, and constants defined below it are ignored, which is the reason people report that debugging "did nothing".
Look for an existing WP_DEBUG line first. Most installations already have one set to false. If it exists, change it rather than adding a second one, because the first definition wins and a duplicate will quietly do nothing.
Then set the three constants:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Save the file and reload your site. You should see no change at all. That is the intended result. If errors appear on screen, WP_DEBUG_DISPLAY is either missing, set after the stop-editing comment, or being overridden by something else, and you should undo the edit rather than leave the site in that state.
Where the log appears, and when
The file is created the first time an error is recorded, not the moment you save. If nothing has gone wrong yet, there will be no file, and that is not a failure of the setup.
By default the log lives at wp-content/debug.log. You reach it the same way you reached wp-config.php, through the File Manager or over FTP.
One thing to know about that location. In a default configuration, wp-content/debug.log is reachable by anyone who guesses the URL, because wp-content is a public folder. On many hosts it is blocked, on some it is not, and you should not assume. This is a second, practical reason to turn debugging off again as soon as you have what you need, and it is the reason this article treats debugging as a temporary state rather than a setting you leave on.
Some site owners point the log to a path outside the public web root instead, by giving WP_DEBUG_LOG a full file path rather than true. That is a better arrangement if you know where your web root ends and your host permits writing outside it. If either of those is unclear, the safer plan is the short session: turn it on, reproduce the fault, read the log, turn it off.
Reproduce the fault deliberately
The log only records what happens while debugging is on. So after you save the file, go and do the thing that breaks. Load the broken page, submit the form, open the screen that errors. If the fault only appears for logged-out visitors, use a private window.
Then look at the log. Reading it is a subject of its own, because a debug log is mostly harmless noise with the useful line buried in it, and knowing which lines to ignore is most of the skill. Our companion guide on finding the guilty plugin in a debug log covers that.
Turning it back off, which is the step people skip
When you are finished, set the constants back:
define( 'WP_DEBUG', false );
Then delete wp-content/debug.log. It is a plain text file and deleting it removes the record.
Leaving debugging on permanently has three costs. The log grows without limit, and on a busy site with a chatty plugin it can grow to a size that matters. The file may be publicly readable, as above. And a site running with debug constants set is a site whose next owner, or next helper, will assume something is being actively investigated.
What the debug log will not tell you
It records PHP errors. It does not record a plugin that is behaving wrongly without erroring, a styling problem, a caching problem, or a server-level failure that happens before PHP runs. If your site returns a server error page rather than a WordPress one, the useful record is your host's error log, not this one.
It also will not tell you which of two plugins is at fault when they conflict. It names the file where PHP gave up, which is often the victim rather than the cause. That distinction is worth holding on to, and it is why isolation testing still exists as a separate step.
Version context. Written against WordPress 7.1, released 2026-08-19, the current major release on our record. The debugging constants described here are long-standing core behavior and are not specific to 7.x. Understanding what a WordPress update actually replaces is useful background, because wp-config.php is one of the files an update does not touch, which is why an edit here survives updating.
