Quick answer: To log WordPress errors, set
WP_DEBUGandWP_DEBUG_LOGtotrueinwp-config.php, and setWP_DEBUG_DISPLAYtofalseso visitors never see the messages. WordPress then saves errors towp-content/debug.log. Switch debugging off and remove the log when you finish.
When a site breaks, guessing is the slowest way to fix it. The faster route is to log WordPress errors, so you can see which file and which line caused the problem. This guide shows how to do that safely with the built-in debug log, how to read what it records, and how to switch it off again.
It is written for site owners, freelancers and developers who need to log WordPress errors and can edit wp-config.php. No extra plugin is required.
What Does It Mean to Log WordPress Errors?
WordPress is built on PHP. When PHP code runs into a problem, it produces a message such as a notice, a warning, a deprecation message or a fatal error.
By default, these messages are either shown on the page or silently discarded. When you log WordPress errors, they are written to a text file instead. That file gives you a time-stamped record you can read later, even if the error only appears now and then.
This is why it helps to log WordPress errors before you start changing plugins or themes.
The WP_DEBUG constant turns debug mode on. A companion constant, WP_DEBUG_LOG, tells WordPress to save the messages to a log file called debug.log.
Before You Start: Backup, Staging and Access
Official WordPress documentation says debug tools are meant for local and staging sites, not for live sites. If you must debug a live site, keep the session short and keep errors hidden from visitors.
Prepare these three things first:
- A recent backup of your files and database, so you can restore the site if an edit goes wrong.
- A staging copy of the site if your host offers one.
- File access through your hosting file manager or SFTP, because you will edit
wp-config.php.
A typo in wp-config.php can take the whole site offline. Copy the original file to your computer before you change it.
How to Log WordPress Errors in 5 Steps
Step 1: Open wp-config.php
The wp-config.php file sits in the root folder of your WordPress installation, next to the wp-content folder. Open it with your host’s file manager editor or with an SFTP client.
Step 2: Add the Debug Constants
Find the line that begins with That’s all, stop editing! Add the following code above that line, not below it.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );The first two lines turn debugging on and send messages to a file. The last two lines stop errors from appearing on public pages. Together, they let you log WordPress errors without exposing technical details to visitors.
Step 3: Save the File and Reproduce the Problem
Save wp-config.php and upload it again if you used SFTP. Then repeat the action that caused the error, such as loading the broken page, saving a post or placing a test order.
The log only records events that happen after you start to log WordPress errors. Errors from before you enabled it will not appear.
Step 4: Open the debug.log File
When WP_DEBUG_LOG is true, WordPress creates the file at wp-content/debug.log. Open it from your file manager or download it through SFTP and read it in a text editor.
Each line starts with a date and time. New entries are added at the bottom, so scroll to the end first.
Step 5: Turn Debugging Off When You Finish
Once you have found the cause, set WP_DEBUG back to false or remove the lines you added. Then download the log if you need it and delete it from the server.
Do not keep the setting on after you log WordPress errors for a specific problem. It can leave sensitive paths readable, and the cleanup checklist further down explains why.
What Each Debug Constant Does
Quick answer:
WP_DEBUGswitches debug mode on,WP_DEBUG_LOGsaves messages to a file, andWP_DEBUG_DISPLAYcontrols whether they appear on screen.
You do not need every constant. This table shows what each one does so you can choose only what your situation needs.
| Constant | Default | What it does |
|---|---|---|
WP_DEBUG |
false | Turns on WordPress debug mode so PHP errors and notices are reported. |
WP_DEBUG_LOG |
false | Saves reported messages to wp-content/debug.log, or to a custom file path. |
WP_DEBUG_DISPLAY |
true | Shows messages inside the page HTML. Set it to false to hide them. |
SCRIPT_DEBUG |
false | Loads the unminified versions of core CSS and JavaScript. It is mainly useful when working on core files. |
SAVEQUERIES |
off | Stores database queries and their timings. It has a performance cost, so use it only while debugging. |
For most jobs where you log WordPress errors, the first three constants are enough. Leave SCRIPT_DEBUG and SAVEQUERIES off unless you have a specific reason to use them.
How to Read the WordPress debug.log File
Once you log WordPress errors, the file can look overwhelming, but each entry follows the same pattern: a timestamp, an error level, a message, a file path and a line number. Here is an illustrative example:
[11-Oct-2026 09:14:02 UTC] PHP Warning: Undefined variable $settings in /wp-content/plugins/example-plugin/includes/helpers.php on line 48This sample is invented to show the format. The plugin name and line number on your site will be different.
Understand the Error Level
The level tells you how urgent the message is. Fatal errors need attention first.
| Level | Meaning | Usual priority |
|---|---|---|
| Fatal error | PHP stopped running the request. This often causes a white screen or a critical error message. | High |
| Warning | Something is wrong, but the script kept running. | Medium |
| Notice | A minor issue, such as using a value that was never set. | Low |
| Deprecated | Code uses a function that will be removed in a future version. | Plan an update |
Find the Source From the File Path
The path in the message points to the code that triggered it. Use the folder name to see who owns it:
/wp-content/plugins/plugin-name/means a plugin is involved./wp-content/themes/theme-name/means your theme or child theme is involved./wp-includes/or/wp-admin/means a core file is listed, but a plugin or theme often called it.
If the same plugin appears again and again, update it first. If that does not help, deactivate it and test again.
How to Show or Hide WordPress Errors on Screen
The log file is not the only place errors can appear. Visitors can see them too if display is on, which looks unprofessional and may reveal server paths.
You can log WordPress errors and still keep them off the page. To hide WordPress errors from visitors while keeping the log, use these two lines:
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );To show errors on the page, set WP_DEBUG_DISPLAY to true. Do this only on a local or staging site. On a live site, rely on the log file instead.
Move the Log File to a Safer Location
WP_DEBUG_LOG accepts a file path instead of true. That lets you log WordPress errors to a file outside the public web folder.
define( 'WP_DEBUG_LOG', '/path/outside/public_html/wp-errors.log' );Replace the sample path with a real, writable location on your server. WordPress documentation advises keeping error logs out of publicly accessible locations and deleting them after troubleshooting.
WordPress debug.log Not Created? Try These Fixes
If you try to log WordPress errors and no file appears, check the common causes below.
- No error has happened yet. WordPress only creates
debug.logwhen it has something to write. Trigger the problem again. - The constants are in the wrong place. They must sit above the That’s all, stop editing! line.
- The folder is not writable. If
wp-contentblocks writes, PHP cannot create the file. Ask your host to check permissions. - A duplicate definition exists. Another
WP_DEBUGline elsewhere in the file may override yours. Search the file for each constant. - A syntax mistake in wp-config.php. A missing quote or semicolon can break the site. Compare your edit with the code above.
- Your host uses its own log. Some hosts keep a server-level PHP error log in the hosting panel. Look there too.
If the site shows only a blank page, the PHP error log in your hosting panel is often the quickest place to look.
Other Ways to Check for WordPress Errors
The debug log is the most direct way to log WordPress errors, but it is not the only one. These tools can help when you cannot edit files or want a second view.
Site Health Screen
Go to Tools > Site Health in your dashboard. The Status tab lists critical issues and recommendations, including debug settings that display or log errors publicly.
The Info tab shows technical details about your site, which is useful when you ask a developer or host for help. Read more in the official Site Health documentation.
Query Monitor Plugin
Query Monitor is a free developer tool that reports PHP errors, slow database queries, hooks and more. By default, only administrators can see its output. It is aimed at troubleshooting, so install it when you need it and remove it when you are done.
Your Hosting Error Log
Most hosting panels provide a server error log. It can show errors that happen before WordPress loads, which the WordPress debug log cannot catch.
Security and Cleanup Checklist
Any file you use to log WordPress errors can contain file paths, plugin names and sometimes data from requests. Treat it as private. Run through this list when your troubleshooting is done:
- Set
WP_DEBUGtofalseor remove the debug lines fromwp-config.php. - Download the log if you need to share it with a developer.
- Delete
debug.logfrom the server. - Check that
/wp-content/debug.logdoes not open in a browser. - Restore any backups or staging changes you no longer need.
If the log reveals code you do not recognise, such as unfamiliar files in strange folders, treat it as a possible security problem. In that case, a website security and malware recovery package may be a safer route than editing files yourself.
Frequently Asked Questions
Where does WordPress log errors?
When WP_DEBUG_LOG is set to true, WordPress writes errors to wp-content/debug.log. You can also set a custom file path. Your host may keep a separate server-level log as well.
How do I log WordPress errors to a file?
Add define( 'WP_DEBUG', true ); and define( 'WP_DEBUG_LOG', true ); to wp-config.php, above the That’s all, stop editing! line. Then reproduce the error and open the log file.
Is it safe to leave WP_DEBUG on?
No. Official guidance treats debugging as a tool for development and staging. Turn it off after troubleshooting and delete the log so no one can read it.
How do I hide WordPress errors from visitors?
Set WP_DEBUG_DISPLAY to false and add @ini_set( 'display_errors', 0 );. Errors can still be saved to the log while staying off the public page.
Why is my WordPress debug.log empty?
An empty or missing log usually means no error has occurred since you turned debugging on, or the constants are in the wrong place. Check the folder permissions as well.
Next Steps
You now know how to log WordPress errors safely, read each entry and clean up afterwards. Start with the file path in the newest fatal error, then test the plugin, theme or custom code it points to.
If the log shows problems you cannot solve, or the site is down and you need it back quickly, see the WordPress error fix service. To catch issues earlier, a website care and maintenance package covers ongoing checks. You can also browse more WordPress guides.
