What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The fastest way to check a WordPress error log is to enable logging in wp-config.php, reproduce the problem, and open wp-content/debug.log. Keep errors hidden from visitors with WP_DEBUG_DISPLAY set to false. When you finish troubleshooting, turn debugging off and remove the log.
What the WordPress error log does
WordPress can record PHP notices, warnings and errors generated while your site loads. The record is a plain-text file named debug.log inside the site’s wp-content directory. Reading it is particularly useful when the browser shows a blank page or a generic HTTP 500 error instead of the underlying message. The log can reveal that an error occurred even when WordPress cannot display details on the page.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall
Logging is not normally a permanent production setting. A log can grow as requests continue, and its contents may expose server paths or other implementation details. Use it for a controlled troubleshooting session, protect it from visitors, and disable it after the fault is addressed. The configuration and file locations described here are documented by wp-staging, WPBeginner and WPBookster.
Before you edit anything
Record the symptom
Write down the exact URL, action and time that trigger the problem. For example, note whether the error appears when the home page loads, when a particular post is opened, or after saving a plugin setting. This gives you a specific event to look for after logging starts.
Make sure you can access the files
You need access to the WordPress installation through your hosting control panel’s File Manager or through FTP. The configuration file is usually in the site’s document root, often a directory named public_html. A managed WordPress service may restrict direct file access or expose its own debugging controls; if the paths or menus below are unavailable, follow that host’s documentation, such as the general guidance at hosting.com.
Use a reversible edit
Download a copy of wp-config.php before changing it, or copy the existing lines into a separate text file. Edit only the debug constants and preserve the file’s existing formatting. A malformed PHP line can prevent WordPress from loading, so do not add quotation marks, semicolons or brackets beyond the exact lines shown below.
Enable WordPress debugging and logging
- Open your hosting File Manager and go to the WordPress installation directory, commonly
public_html. With FTP, connect to the site and open its document-root folder. - Locate
wp-config.phpand choose View or Edit. Download it first if your host offers that option. - Find the existing line
define( 'WP_DEBUG', false );. Changefalsetotrue. If noWP_DEBUGdefinition exists, add the line shown in the code block below. - Add the logging and display settings immediately above the comment that says
That's all, stop editing! Happy publishing.(The wording can vary slightly between WordPress versions.) - Save the file. The three settings should look like this:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );WP_DEBUG turns on WordPress debugging. WP_DEBUG_LOG tells WordPress to write messages to the log file. WP_DEBUG_DISPLAY prevents those messages from being printed in the pages sent to visitors. The combination is important on a live site: you collect diagnostic information without replacing the site’s normal output with technical warnings. The same placement and settings are described by WPBookster, WPBeginner and wp-staging.
Check that the settings were saved correctly
Avoid duplicate definitions
If wp-config.php already contains a WP_DEBUG line, edit that line instead of adding a second one. Duplicate definitions can make it unclear which value WordPress is using and may produce a PHP notice. Keep one definition for each of WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY.
Check the position
The constants belong above the “stop editing” comment and before the file’s final PHP code. Do not place them inside a function, inside an HTML block, or after the closing PHP tag. If your host’s editor displays line numbers, confirm that the lines are in the same configuration section as the other define statements.
Confirm the intended live-site behavior
| Constant | Value during troubleshooting | Purpose |
|---|---|---|
WP_DEBUG |
true |
Enables WordPress debugging. |
WP_DEBUG_LOG |
true |
Writes debug messages to wp-content/debug.log. |
WP_DEBUG_DISPLAY |
false |
Keeps debug messages out of pages shown to visitors. |
Reproduce the error so WordPress writes it
- Open a new browser tab or an incognito window and visit the URL you recorded.
- Perform the exact action that caused the problem: submit the form, open the affected post, activate the suspected feature, or repeat the request that produced the 500 response.
- If the problem is intermittent, repeat the action once or twice while noting the approximate time. Avoid generating unnecessary traffic on a production site.
- Return to File Manager or your FTP client. Refresh the directory listing after the request completes.
The file may not exist before the first message is generated. A missing file immediately after enabling the settings does not necessarily mean the edit failed; first reproduce the error, then refresh the wp-content directory. This creation behavior is noted in the troubleshooting guidance from WPBookster.
Open wp-content/debug.log
Using cPanel File Manager
- Open the WordPress installation directory, commonly
public_html. - Open the
wp-contentfolder. - Look for
debug.log. Select it and choose View to read it in the browser, or choose Edit if you need to copy text for analysis. - If the editor is inconvenient, download the file and open it in a plain-text editor on your computer.
Using FTP
- Connect to the site and navigate to the WordPress installation directory.
- Open
/wp-content/. - Download
debug.logand open the downloaded copy in a text editor. Downloading avoids accidentally changing the log while you inspect it.
The location and cPanel workflow are described by WPBookster and the cPanel instructions at Prostack.
Read the log without losing the useful event
Start with entries created by your reproduction
Open the newest portion of the file first and compare its time with the request you just made. A log can contain older messages from previous visits, so the last entries are usually the most relevant to the symptom you just reproduced. If the file is long, copy the newest block into a separate text document before investigating.
Rank #3
Separate the triggering message from background noise
One page request can cause several messages. Treat entries that appear at the same time as a group, then look for the first message associated with the failed action. Record the complete line, including the file path and line number, rather than copying only a short phrase. Those details help identify which component needs attention.
Use the message to choose your next test
- If the newest entries appear only after a particular page or action, repeat that action once with the suspected feature disabled or avoided. A change in the resulting entries helps narrow the cause.
- If the log does not change, verify that you edited the active site’s
wp-config.php, not a different installation, staging copy or parked domain. - If the browser shows a blank page or 500 response but the log contains a new entry, use the logged file and line information as the starting point instead of trying to make the browser display the error.
These steps do not identify a specific plugin, theme or host fault by themselves; they establish which request generated a message and preserve the exact evidence for the person fixing the code or configuration.
Free tools Windows power users keep installed
One-click scans. No signup required.
When debug.log is missing or empty
The file has not been created yet
Reload the failing page after saving wp-config.php, reproduce the problem, and refresh File Manager. The file appears only after WordPress has something to log, according to WPBookster.
The directory cannot be written
wp-content must be writable for WordPress to create or update the log. If it is not writable, the log cannot be produced. Use your host’s supported permission or ownership controls rather than changing permissions blindly; a managed host may need to make this adjustment for you.
The wrong configuration file was edited
Sites with multiple domains, subdirectories or staging environments can have more than one WordPress installation. Confirm that the file you edited is in the same installation that serves the failing URL. Check the document root selected by the domain in your hosting panel before repeating the test.
Your host controls debugging
Some managed WordPress services restrict file access or provide a host-specific debugging switch. If the standard constants do not work, use the host’s instructions and ask support where its PHP or WordPress log is stored. The host-specific variation is documented in the guidance at hosting.com.
Handle a white screen or HTTP 500 error
A blank screen and a generic 500 response can conceal the message that would otherwise be printed in the browser. Do not turn on visible errors merely to make the page reveal the fault. Keep WP_DEBUG_DISPLAY set to false, reproduce the failure, and read wp-content/debug.log instead. This approach is specifically recommended for locating hidden messages in the troubleshooting material from WPBookster.
If the site remains unavailable after your edit, restore the backup of wp-config.php you made before changing it. Then confirm the syntax of each constant and repeat the procedure carefully. If you cannot regain access, contact the host before making additional configuration changes.
Protect the log while you investigate
- Keep
WP_DEBUG_DISPLAYset tofalseon a live site so visitors do not receive internal messages. - Share only the relevant lines with a developer or host. Remove any credentials, personal data or complete paths that the recipient does not need.
- Do not leave the log enabled while waiting for a fix. Every subsequent request can add more content and make the original event harder to find.
- Use a downloaded copy for analysis when possible, and avoid editing the live log itself.
The reason for these precautions is practical: the log can grow and can reveal file paths. The cleanup recommendation from WPBookster is to disable debugging and remove the file after the issue is fixed.
Turn debugging off after the fix
- Return to
wp-config.phpin File Manager or through FTP. - Change
define( 'WP_DEBUG', true );todefine( 'WP_DEBUG', false );. - Change
define( 'WP_DEBUG_LOG', true );todefine( 'WP_DEBUG_LOG', false );. - Leave no temporary setting that displays errors to visitors. The normal production state is for debug display to remain disabled.
- Save the file, reload the previously failing URL, and verify that the site behaves normally.
- Delete
wp-content/debug.logafter saving any lines your developer needs. If the file is recreated, check that one of the debug constants is still enabled or that your host has a separate logging mechanism.
Disabling both debugging and debug logging, then deleting the log, prevents it from continuing to grow or exposing paths. This sequence follows the cleanup guidance from WPBookster.
A repeatable checklist
- Back up
wp-config.phpand record the exact failing request. - Edit the active installation’s configuration file above the “stop editing” comment.
- Set
WP_DEBUGandWP_DEBUG_LOGtotrue. - Set
WP_DEBUG_DISPLAYtofalse. - Reproduce the error, then refresh the
wp-contentdirectory. - Open or download
wp-content/debug.log. - Match the newest entries to the time and action that failed.
- Check directory writability or host-specific controls if no file appears.
- Save the relevant evidence, restore normal site behavior, disable both debug settings, and delete the log.
What to give a developer or hosting support
Send the URL or action that failed, the approximate time, the complete relevant log entry, and whether the problem occurs consistently or intermittently. State whether you reproduced it with debugging enabled and whether the site displays a blank page, a 500 response or another symptom. Include the WordPress installation path only when the recipient needs it; paths can reveal information that does not belong in a public support request.
This package lets support compare the logged event with the request that triggered it without requiring you to expose the entire file. Keep the original downloaded log privately until the issue is resolved, then remove the production copy.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
