How to find the exact WordPress error message
The exact wording matters. A page that only says there has been a critical error gives less diagnostic information than the underlying PHP fatal error, file path and line number.
Start with what WordPress or the server already provides. Check the page itself, the WordPress recovery mode email sent to the site administrator, and the error log available through your hosting control panel. For front-end JavaScript failures, open the browser developer tools and check the Console while reproducing the problem.
If those sources do not reveal enough information, WordPress includes its own debugging constants. Before editing wp-config.php or any other file, take a full backup of the website files and database. WordPress recommends debugging on a development or staging copy rather than a live site. If you must enable logging on a live installation, do it only briefly, keep errors hidden from visitors and turn debugging off again when you have captured the fault.
If WP_DEBUG is already defined in wp-config.php, edit the existing setting rather than adding a second definition. The following configuration logs errors to wp-content/debug.log while preventing WordPress from deliberately displaying them in the page output:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Place the settings before the line that tells you to stop editing wp-config.php. WP_DEBUG_LOG depends on WP_DEBUG being enabled. Remember that debug.log can contain paths and other technical information, so do not leave it publicly accessible and do not leave debugging enabled unnecessarily.
How the WordPress error finder identifies the cause
The finder compares the text you paste with our library of common WordPress errors. It looks for recognisable messages and, where available, uses the file path to narrow the fault to a particular component.
A PHP fatal error often includes a path such as wp-content/plugins/example-plugin/. The directory immediately after wp-content/plugins normally identifies the plugin whose code was executing at the point PHP reported the error. A path below wp-content/themes can similarly identify the active or parent theme involved.
That does not automatically prove the named plugin caused the original problem. A plugin can fail because another component passed it unexpected data, because a dependency is missing, because a PHP upgrade exposed incompatible code or because the server ran out of memory. The file path tells you where execution failed, which is a much stronger starting point than disabling plugins at random.
If a recognised plugin or theme has a vulnerability record, the finder can point you to that record as additional context. Matching itself happens inside your browser. The pasted error text is not submitted to Web Support Services.
For recurring faults, our WordPress support information covers ongoing technical assistance.
What to do when WordPress is down right now
If the website is unavailable, first preserve the current state. Take a complete backup of the files and database before editing wp-config.php, changing PHP settings, renaming plugin directories or altering the database.
Note what happened immediately before the failure. A plugin update, theme change, PHP version change, deployment or hosting change can sharply reduce the search area. Check the recovery mode email and hosting error logs for the first fatal error rather than concentrating on secondary warnings generated afterwards.
If a recent plugin change is clearly implicated and you have a safe rollback or staging copy, reverse that specific change and retest. Do not delete WordPress core files or wp-config.php as a troubleshooting shortcut.
If you need hands-on assistance, our Emergency Fix costs £249 per incident and has a response within 2 working hours. Never send hosting, WordPress, database or email passwords in an ordinary email or support ticket.