Skip to content
Website Rescue Rescue

WordPress Errors

There Has Been a Critical Error on This Website

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

WordPress hit a PHP fatal error and stopped loading the page. Check the recovery email or server error log for the failing plugin or theme, then disable that code via wp-admin recovery mode, FTP, or your host file manager.

The “There has been a critical error on this website” message means PHP crashed while WordPress was loading a request. Newer WordPress versions catch that fatal and show this screen instead of a blank page, and may email the admin a recovery-mode link. This guide walks through finding the crashing plugin or theme, restoring access safely, and confirming the site loads again before you update anything else.

Intermediate

What the error means

Since WordPress 5.2, uncaught PHP fatal errors are handled by the fatal-error recovery system. Instead of a white screen, visitors see the critical-error message while WordPress attempts to email the site admin a one-time recovery link. That link puts your browser into recovery mode: the faulty plugin or theme is paused for your session so you can log into wp-admin and deactivate it. The front end usually stays broken for everyone else until the bad code is actually disabled or fixed. Fatals often come from plugin/theme updates, PHP version changes, corrupt uploads, or custom code in functions.php—not from “WordPress being down” in a vague sense.

Common symptoms

  • Visitors see “There has been a critical error on this website” (sometimes with “Please check your site admin email inbox for instructions”)
  • wp-admin shows the same message, or only the front end or only admin is broken
  • Admin inbox receives a “Your Site is Experiencing a Technical Issue” email with a recovery link
  • Error started immediately after a plugin, theme, WordPress core, or PHP version change
  • Hosting error log or wp-content/debug.log shows “PHP Fatal error” or “Uncaught Error” with a path under wp-content/plugins or wp-content/themes
  • Site Health or recovery notices name a specific plugin or theme once you regain admin access

Most likely causes

  1. 01 Plugin incompatible with the current WordPress or PHP version after an update
  2. 02 Theme or child-theme PHP fatal, including a bad edit to functions.php
  3. 03 Must-use (mu-plugin) or drop-in (object-cache.php, advanced-cache.php) that loads on every request and fatals
  4. 04 Corrupt or incomplete plugin files after a failed update or interrupted upload
  5. 05 PHP memory exhaustion or max execution time hit during bootstrap
  6. 06 Custom code snippet, malware, or a poorly written hook throwing a fatal on init

What changed before the problem started

  • Plugin or theme update (manual click or automatic background update)
  • WordPress core update
  • PHP version change in the hosting control panel
  • New plugin installed or reactivated, or a code snippet added
  • Theme switch or direct edit to the active theme’s functions.php
  • Host migration or partial file restore that left mismatched plugin/theme files

Troubleshooting steps

  1. 01

    Use the recovery-mode email if you received one

    Open the WordPress “Your Site is Experiencing a Technical Issue” email on the admin address. Click the recovery link (it expires; a new one is sent if the error happens again). You should land in wp-admin with notices naming the paused plugin or theme. Deactivate that plugin under Plugins, or switch themes under Appearance → Themes. Click Exit Recovery Mode in the admin bar, then reload the front end in a private window. Success signal: homepage and /wp-admin/ load without the critical-error screen.

  2. 02

    Check hosting error logs for the exact fatal

    In cPanel (Errors / Metrics → Errors), Plesk, or your host’s log viewer, open today’s PHP or error log. Search for “Fatal error”, “Uncaught Error”, or “Allowed memory size”. Copy the file path—especially anything under wp-content/plugins/… or wp-content/themes/…. That folder name is your primary suspect. Success signal: you can name one plugin or theme slug from the log before you start renaming folders.

  3. 03

    Disable the suspect plugin via FTP or file manager

    If wp-admin is unreachable and no recovery email arrived, connect with SFTP/FTP or the host File Manager. Go to wp-content/plugins/, find the plugin directory from the log (or the one updated last), and rename it to something like plugin-slug.disabled. Reload the site. If it recovers, leave that plugin off. Success signal: front end and login page load; Plugins list in wp-admin shows the renamed plugin as broken/missing until you restore a good copy.

  4. 04

    Rule out the theme by forcing a default theme

    In wp-content/themes/, rename the active theme folder (and its child theme if used) by appending .disabled. WordPress should fall back to a bundled default theme such as Twenty Twenty-Four if one is installed. Reload home and wp-admin. Success signal: critical error gone after the theme rename means the theme (or child) was the crash source—restore a clean zip or undo the last theme edit.

  5. 05

    Enable debug logging without showing errors to visitors

    Edit wp-config.php above the “stop editing” line: set WP_DEBUG to true, WP_DEBUG_LOG to true, and WP_DEBUG_DISPLAY to false, and add @ini_set('display_errors', 0);. Reproduce the error once, then open wp-content/debug.log and read the newest stack trace. Turn WP_DEBUG back to false when done. Success signal: debug.log contains a dated fatal pointing at a specific file you can act on.

  6. 06

    Clear caches only after the fatal is gone

    Once the site loads again, purge page cache (caching plugin), host cache, and CDN/Cloudflare cache if used. Hard-refresh the homepage and a logged-out browser. Success signal: visitors see the restored site, not a cached critical-error HTML page.

When to stop troubleshooting

Stop DIY changes if you lack file or hosting access, the recovery email never arrives and you cannot reach FTP/SFTP, logs point to core corruption or unknown malware, disk space is full and MySQL/PHP keep failing, or every isolation step still fatals. Extended guessing on a live store or lead-gen site increases downtime—hand off with the recovery email (if any), log excerpts, and a confirmed backup timestamp.

Information to collect before requesting help

  • 01 Exact on-screen message and whether front end, wp-admin, or both are affected
  • 02 Screenshot of the critical error page
  • 03 Recovery email contents naming a plugin or theme (if received)
  • 04 Relevant lines from the host error_log or wp-content/debug.log
  • 05 What changed in the last 24–48 hours (updates, PHP, deploys, theme edits)
  • 06 WordPress version, PHP version, and hosting provider/panel type
  • 07 Whether a recent full backup (files + database) exists and when it was taken

How a professional repairs the problem

A technician pulls the fatal from the host log or recovery-mode notice, then safely disables the offending plugin, theme, mu-plugin, or drop-in without wiping the whole stack. They restore wp-admin and front-end access, verify key pages load, and clear caches. Next they update or replace the broken code, confirm PHP compatibility, and optionally reinstall clean files from official zips. If the crash followed a bad auto-update or looks like malware, they restore from a verified backup, scan for compromise, and leave you with a short note on what to stage-test before the next update batch.

Frequently asked questions

Is a critical error the same as the white screen of death? +
Often the same root cause—a PHP fatal—but newer WordPress versions show the critical-error message (and may send recovery email) instead of a blank page. Fix the underlying fatal either way; do not treat them as unrelated problems.
Will renaming a plugin folder delete my settings? +
No. Renaming only stops the plugin from loading. Options usually stay in the database until you uninstall the plugin properly from wp-admin. Content in posts and pages remains.
Why did I not get a recovery email? +
The admin email in Settings may be wrong, the host may block PHP mail, spam filters may quarantine it, or the crash may happen before WordPress can send mail. Use FTP or the host file manager to disable plugins when the email never arrives.
Can I just raise the PHP memory limit? +
Only if the log shows memory exhaustion. Raising memory will not fix undefined functions, type errors, or incompatible plugins—and masking a leaky plugin with endless memory increases is not a real fix.
Should I reinstall WordPress core first? +
Usually no. Most critical errors come from wp-content code. Reinstall core only after plugins and themes are ruled out, or when logs clearly point to corrupted wp-admin or wp-includes files.
Does recovery mode fix the site for all visitors? +
No. Recovery mode pauses the bad extension mainly for your admin session so you can deactivate it. Visitors keep seeing the critical error until you actually deactivate or replace the faulty code.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.