"There has been a critical error on this website" is WordPress's built-in handler for a fatal PHP error. Unlike the older white screen of death, WordPress now catches the fatal and shows this message instead of a blank page, and usually emails the site admin a link to fix it. Start there: check the admin inbox for an email from WordPress with a "recovery mode" link, or turn on debug logging to see the real error.
The fix is almost always the same: find which plugin or theme file threw the fatal, then disable or update it. This is the modern equivalent of the classic white screen of death, and the isolation steps below mirror that process closely.
Check for the recovery mode email first
Since WordPress 5.2, a fatal error triggers an automatic email to the site admin address with a subject like "Your site is experiencing a technical issue." That email contains a special recovery mode link. Clicking it logs you into wp-admin in a safe mode that disables the broken plugin or theme only for your session, so you can log in, see which extension is flagged, and deactivate it properly from the Plugins screen.
If you don't see the email, check spam, and confirm the admin email address is correct under wp-admin → Settings → General. On a fresh install or one where the database is unreachable, the email may never send. In that case, skip to debug logging below.
Turn on WP_DEBUG to see the real error
The critical error message is intentionally vague for visitors. To see the actual PHP error, edit wp-config.php via FTP or the portal's file manager. Find this line:
define('WP_DEBUG', false);
Change it to these three lines:
define('WP_DEBUG', true);define('WP_DEBUG_LOG', true);define('WP_DEBUG_DISPLAY', true);
Save and reload the page. You'll either see the fatal error printed directly on the page, or find it appended to /wp-content/debug.log. The error tells you the exact file and line: a plugin path like /wp-content/plugins/some-plugin/file.php means that plugin is the cause; a theme path means the theme is. Turn WP_DEBUG_DISPLAY back to false once you're done. You don't want raw PHP errors visible to visitors on a live site.
Isolate the broken plugin or theme
If the debug log points at a plugin, deactivate it from wp-admin → Plugins, or if you can't log in, rename its folder via FTP or the file manager, for example /wp-content/plugins/broken-plugin/ to /wp-content/plugins/broken-plugin.bak/. WordPress treats a renamed plugin folder as deactivated.
If you can't tell which plugin is at fault, rename the whole /wp-content/plugins/ folder to force every plugin off, confirm the site loads, then rename it back and reactivate plugins one at a time from wp-admin, reloading after each one. The plugin active when the error returns is the culprit.
Theme errors follow the same pattern: rename /wp-content/themes/your-theme/ and WordPress falls back to a default theme. If the site recovers, the theme's code is the problem, usually a functions.php edit or an update that changed a function signature.
Common root causes
- PHP version mismatch. A plugin or theme using a function that was removed or changed in a newer PHP release. If you recently changed versions, go to Services → click your hosting → the PHP tile and try the previous version to confirm. See what PHP version should I use for WordPress for how to choose and test a version safely.
- A failed or partial update. An update interrupted mid-file-copy can leave a plugin with missing or corrupted files. Reinstalling the plugin fresh from wp-admin or by re-uploading it usually clears this.
- A plugin conflict. Two plugins that hook the same function or overwrite the same global can throw a fatal only when both are active together, which is why one-at-a-time reactivation matters more than testing plugins alone.
- Memory exhaustion. An "allowed memory size exhausted" fatal looks similar to other critical errors in the admin. The debug log will say so explicitly if that's the cause.
When to contact support
If the debug log doesn't point clearly at a file, or the error looks database-related rather than plugin or theme related, open a ticket from the portal under Support → New ticket, or use live chat. Our support is real humans, not a bot queue, and they can pull server-level PHP error logs you might not have file access to see, which sometimes catch issues the debug log misses entirely.