WordPress Error Diagnosis Tool

Most WordPress failures announce themselves in one of four ways: a completely blank page, a themed 'There has been a critical error on this website' notice, a raw HTTP status page from the server such as 500 or 503, or a message about the database. Those four buckets already narrow the cause enormously, and people skip past them because panic makes you want to start clicking. A blank page with a 200 status is nearly always PHP dying before it can print anything. A themed critical error means WordPress survived long enough to load its own error handler, so the fault is usually in a plugin or theme rather than in core. A 500 from the server with no WordPress branding at all points at .htaccess, a PHP version mismatch or a process limit on the host. A database message means credentials, a crashed table or a database server that has stopped answering.

Before running this tool it helps to note two things: what the page returns and what changed most recently. Open the page in a private window so caching does not lie to you, and check the status code in your browser's network tab. Then look at the last update, migration, PHP change or new plugin. In our own recovery work, the combination of status code plus last change identifies the cause outright roughly three times out of four.

The single most useful habit in WordPress recovery is reading logs before changing files. There are three logs worth checking and they are not the same thing. WordPress writes its own log to wp-content/debug.log once you set WP_DEBUG and WP_DEBUG_LOG to true in wp-config.php, with WP_DEBUG_DISPLAY set to false so visitors never see the output. Your host writes a PHP error log, usually reachable from the control panel under Logs or Errors, and that one catches failures that happen before WordPress boots. The web server keeps an access and error log that shows rewrite loops and permission problems that PHP never sees.

A useful fatal error line contains four pieces: the error type, the message, the file path, and the line number. The file path is the answer most of the time. If it sits inside wp-content/plugins/some-plugin, you have your culprit without any further testing. If it sits inside wp-includes or wp-admin, the trigger is usually something calling core incorrectly rather than core itself being broken, so keep reading the stack for the first wp-content path that appears.

If logs are empty and the symptom does not fit a clean category, work in the order that carries the least risk. Clear every cache layer you have, including the plugin cache, the host's server cache and any CDN, because a cached copy of a broken page keeps you chasing a problem you already fixed. Next, switch to a default theme by renaming your theme folder over FTP; WordPress falls back automatically and nothing is lost. Then rename the entire plugins folder to plugins-off, load the site, and if it recovers, rename it back and re-enable plugins in batches.

Two safety rules matter more than speed. Take a copy of the database and the wp-content folder before you edit anything, even if you are certain about the fix, and change one thing at a time so that when the site comes back you know why. Reinstalling WordPress is almost never the right first move; core files are the least likely thing to be broken and a reinstall destroys the evidence you need.