Free WordPress site audit. Public-site review and a fixed quote when work is appropriate. Request a rescue audit →

WordPress fatal errors

There Has Been a Critical Error on This Website

That white page is WordPress catching a PHP fatal. The recovery email is optional. The log is the source of truth. Do not delete wp-config to “reset” it.

Direct answer

Since WordPress 5.2, an uncaught fatal in a plugin, theme, or drop-in is wrapped as “There has been a critical error on this website.” The site may still send a recovery-mode link to the admin email. If that email never arrives, you still have debug.log, the host error log, and file-level plugin rename.

Safe diagnostic sequence

  1. Take a backup or snapshot before you rename anything. If you cannot, stop and get hosting file access first.
  2. On staging or via SFTP, add temporary logging in wp-config.php: WP_DEBUG true, WP_DEBUG_LOG true, WP_DEBUG_DISPLAY false. Reload once. Read wp-content/debug.log. Turn display off so you do not leak paths to the public.
  3. The last PHP fatal names a file. If it is a plugin, rename that plugin folder. If it is the active theme, switch to a default theme via the database template / stylesheet options only when you understand the risk.
  4. If the fatal is in object-cache.php or advanced-cache.php, those drop-ins survive “disable all plugins.” Rename the drop-in, not the whole wp-content directory.
  5. PHP version jumps (7.4 → 8.2) surface old plugins. That is an update problem. See broken after a plugin update.

What not to do

  • Do not leave WP_DEBUG_DISPLAY on in production.
  • Do not delete the database to “start clean.”
  • Do not paste random functions.php snippets from a forum into the live theme.

Critical Error Rescue starts from $149. Final quote after we see the log line. CTA: Fix My WordPress Site.

Bug fixing · health checker

Broken or slow WordPress? Get a free site audit and a fixed quote after review.
Free audit