A WordPress site that displays a blank page, a critical error or a frozen form can put a stop to enquiries, requests for quotes and sales. The WordPress debugging It is a technical procedure, whilst the debug mode is used to collect and interpret errors.
It’s not enough to simply deactivate plugins at random. You need to record the error, identify the file involved and check that it has been fixed. Here is a practical guide, which is also useful if the dashboard is no longer accessible.
Key points for taking action without making the problem worse
- Always create a full backup of your files and databases before making any changes to your settings, plugins or theme.
- Enable debugging for a limited period and save the errors to the file
debug.log. - On a public website, hide errors from the front end. Visitors should not be able to see file paths, PHP messages or server details.
- Read through the log starting from the most recent lines and look for the first fatal error, not the most recent warning that appeared.
- If the site is down, isolate the plugin and theme first. Don’t change ten elements at once.
- Once the issue has been resolved, disable debugging and make a note of the cause, the action taken and the version to which the system has been restored.
A backup that has never been tested with an actual restore is no guarantee. It is merely a hope.
Before debugging: backups, staging and access
Debugging is useful, but a hasty change can create a second problem. First, check that you can access the WordPress backend, the hosting control panel and the files via the hosting file manager, an FTP client or SFTP. Also, keep a recent backup of the site.
Work on the staging environment when the website generates leads
An update may break a form, a services page, a WooCommerce checkout or an email integration. If your website is live and generates business every day, try out any changes and updates first in a WordPress staging environment.
Staging is a separate copy – in other words, a staging environment. Here you can enable logging, update plugins and test PHP code without exposing errors to customers. Protect it with a password and set it up as noindex.
Note down what changed just before the error occurred
A website often stops working after an update to WordPress, a theme, a plugin or the PHP version. Make a note of the date, time and symptoms: blank page, 500 error, slow performance, login blocked, form failing to send emails.
Also check your browser cache, CDN, caching plugins and server cache. A cached page that is out of date may look like a WordPress error, but it isn’t.
How to enable WordPress debugging in wp-config.php
To enable WordPress debugging, you need to edit the file wp-config.php, which is available in the main installation folder. You can do this using the hosting provider’s file manager or via SFTP.
Insert the constants in the correct place
Open wp-config.php using a simple text editor. Insert these lines after the database and security key settings, but before the line:
/* That's all, stop editing! Happy publishing. */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Save the file and repeat the action that causes the problem. WP_DEBUG enables error logging. With WP_DEBUG_LOG When active, the log is written to wp-content/debug.log.
Do not display PHP errors to visitors
WP_DEBUG_DISPLAY set to false prevents errors, warnings and internal paths from appearing in the page’s code. The PHP directive display_errors It may affect server-side rendering, but no PHP errors should be displayed to visitors to a live website.
Displaying a PHP error does not help the customer. It may give the impression of a lack of reliability and reveal useful details to those looking for vulnerabilities. The most prudent configuration is to have logging enabled but error display disabled during a quick check in production.
If the WordPress log is not sufficient, compare it with the server’s PHP log using error_log. The path depends on the hosting provider and the server configuration.
Debugging plugins, such as WP Debugging, can make it easier to enable constants. However, for a reliable technical check, it remains essential to be familiar with the main configuration file.
The debug constants you actually need
The official documentation on WordPress debugging This describes the main WordPress debugging constants. Do not enable them all without good reason. Each option collects different information, and some affect performance.
WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY
WP_DEBUG Enables debug mode. On its own, it can display PHP errors, notices and warnings, helping you to distinguish between warnings and fatal errors.
WP_DEBUG_LOG logs errors to the file /wp-content/debug.log. This is useful when the problem does not always occur or only affects certain pages. It also checks error_log, the server’s PHP file, which may contain additional information relating to debug.log.
WP_DEBUG_DISPLAY determines whether errors are displayed in the HTML. Keep it set to false on the live site. The log retains what is needed, without exposing technical messages to the public.
SCRIPT_DEBUG for CSS and JavaScript
SCRIPT_DEBUG Force WordPress to load the unminified versions of the core CSS and JavaScript files. This is useful if a menu isn’t responding, the editor is behaving strangely or a JavaScript function is throwing an error.
Add this line only whilst testing:
define( 'SCRIPT_DEBUG', true );
It doesn’t resolve a conflict. It helps you view files more clearly whilst analysing them.
SAVEQUERIES and database slowdowns
SAVEQUERIES It logs every query to the MySQL database, the time taken and the function that called it. It can highlight inefficient plugins or custom code that generate excessive queries.
define( 'SAVEQUERIES', true );
This option creates overhead and may impair site performance whilst queries are being collected. Use it only for a brief diagnostic check, preferably in a staging environment, and then remove it. A slow site does not need more data collected indiscriminately; it needs the correct cause to be identified.
How to read debug.log without getting lost in the warnings
A debug.log It may contain hundreds of lines. Not all of them are equally serious. Start with the lines created at the exact time you reproduced the problem.
If the action is not recorded, check that WP_DEBUG is set to true and that WP_DEBUG_LOG is active. For systematic troubleshooting, also check the server’s PHP log or the output generated by error_log.
Identify the type, file and line of the error
A log entry usually includes the date, the type of error, the file path and the line number. The error messages They should be interpreted in conjunction with all this data, not in isolation.
The most significant PHP errors are often Fatal error, Uncaught Error e Parse error. A warning does not always cause the site to crash. A fatal error does. Look for the first fatal error that appeared after opening the problematic page. The file mentioned may belong to a plugin, the theme or a custom function.
Distinguish the cause from the symptom
If the log refers to a file within wp-content/plugins/plugin-name/, that plugin is the prime suspect. If the path is within the active theme, check the templates, added functions and PHP compatibility.
A PHP memory-related error message may be a symptom. Before increasing the limit, check whether a plugin is repeatedly sending requests, running queries or performing resource-intensive operations. For more information on handling errors, conflicts and updates, see the A guide to WordPress support for SMEs.
White Screen of Death: recovering a frozen website
The White Screen of Death is a blank page with no content. It may be caused by a fatal PHP error, an incompatible plugin, a faulty theme or insufficient memory. In such cases, do not disable error handling without first diagnosing the issue in a controlled environment.
Don’t start by editing WordPress core files. The Official guide to common mistakes It advises you to check your plugins and theme first.
Disable plugins via FTP or a file manager
If you are unable to access wp-admin, the WordPress backend may be inaccessible even when the files are still accessible. You should therefore access the site’s files via FTP or a file manager and rename the folder:
wp-content/plugins
For example, turn it into plugins_old. WordPress will no longer be able to find the plugins and will temporarily deactivate them all. If the site comes back online, restore the folder to its original name.
Then reactivate the active plugins one by one from the dashboard. After reactivating each one, check the homepage, the contact page, the members’ area and key commercial functions.
If the problem persists, try the theme and contact your hosting provider for support
If the blank page persists, temporarily switch to a default WordPress theme, if available. Also check the server’s PHP error logs, which are often stored in the file error_log, and the PHP version configured by the hosting provider. These logs are separate from those managed by WordPress.
Avoid making direct changes to the database to disable extensions unless you know exactly what you are doing. An incorrect value may compromise settings, user roles or serialised data. If SFTP is unavailable, ask your hosting support team to restore file access or check the server log. When the site is completely inaccessible, do not rely on debugging plugins to resolve the issue.
After the repair: technical and safety checks
Just because a website is back online doesn’t mean all issues have been resolved. Check the forms, login, checkout, email, service pages and ad tracking.
Turn off debugging as soon as you’ve finished
Once the analysis is complete, make the change again wp-config.php:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
Remove these as well SAVEQUERIES e SCRIPT_DEBUG if you added them for testing purposes. Keep the logs, including error_log, only for as long as necessary, and protect them from unauthorised access. If they are needed for subsequent analysis, do not delete them automatically.
Turn a fault into a preventative maintenance opportunity
Update the core, theme and plugins after taking a verified backup. Remove any unused extensions and administrator accounts that are no longer needed. Check the logs, uptime, security and functionality of forms, logins, checkouts, emails and tracking every month.
The technical maintenance of the website It prevents a minor warning from turning into a page that can’t be accessed at the worst possible moment. For a corporate website, monitoring isn’t a luxury. It’s part of the job.
Frequently Asked Questions about WordPress Debugging
Where is the debug.log file located?
With WP_DEBUG_LOG When active, WordPress normally saves errors in the path /wp-content/debug.log. You must also have WP_DEBUG set to true.
Can I leave WP_DEBUG enabled on the live site?
Only for as long as is necessary to carry out a targeted check. Keep WP_DEBUG_DISPLAY on false, sort out the problem and then disable debugging.
Why doesn’t the debugger display any errors on screen?
Check WP_DEBUG_DISPLAY, the cache and the hosting configuration. In some development environments, it may be useful to set WP_DISABLE_FATAL_ERROR_HANDLER on true to view fatal errors.
The log must guide every action
WordPress debugging isn’t an automatic solution. It’s the quickest way to stop guessing and start testing.
Enable the logs, isolate the cause, test the fix and switch everything off once the site is stable again. A reliable corporate website is also built on these procedures, which are often unseen but prove crucial when enquiries and requests come in.
