WordPress Errors

"There Has Been a Critical Error on This Website" — What to Do Next

WordPress replaced the old blank screen with a message and an email. Here is how to use recovery mode properly, read the email it sends, and fix a WordPress critical error without guesswork.

Get Shielded
19 Jul 2026 5 min read
"There Has Been a Critical Error on This Website" — What to Do Next

"There has been a critical error on this website." It is a polite message that tells you almost nothing, and it appears exactly when you least want to read carefully.

The good news is that a WordPress critical error is more helpful than the blank white page it replaced. WordPress knows what went wrong, and it has almost certainly emailed you the details.

Check your email first

Before touching a single file, check the inbox for your site administrator address. WordPress sends a message titled something like "Your site is experiencing a technical issue."

That email is the most valuable thing you have. It usually contains the plugin or theme responsible, the exact file and line number, the error type, and a special recovery-mode link.

Check spam if it is not in the inbox. And note the obvious trap: if the admin email address is broken or belongs to someone who left the company, you will never see it. Worth fixing that now rather than during the next outage.

Use recovery mode

The link in that email logs you into the dashboard in recovery mode, with the problem plugin or theme paused. This is by far the easiest route back in — no FTP, no file manager, no guesswork.

Once inside, WordPress shows a notice naming the offending component. Deactivate or update it, then exit recovery mode.

Recovery mode links expire after 24 hours, so use it promptly.

If you cannot get the email

Turn on error logging manually. Add this to wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Reload the broken page, then read wp-content/debug.log. The last entries name the file and line. Turn debugging off again afterwards — you do not want errors written indefinitely on a live site.

Setting WP_DEBUG_DISPLAY to false matters. It keeps errors out of the page your visitors see, which would otherwise expose file paths publicly.

Fixing the common causes

A plugin conflict

The usual culprit. If the log names a plugin, rename that plugin's folder inside wp-content/plugins using FTP or your host's file manager. That deactivates it without dashboard access.

If nothing is named, rename the whole plugins folder to disable everything, confirm the site returns, then rename it back and disable plugins one at a time.

A theme problem

If the admin works but the front end does not, rename your theme folder. WordPress falls back to a default theme automatically. A recent edit to functions.php is a frequent cause.

A PHP version mismatch

Hosts upgrade PHP, sometimes without warning. Code written for an older version fatal-errors on the new one. If nothing changed on your side, check whether your PHP version did.

Update the affected plugin or theme. Moving PHP back a version is a temporary measure only — unsupported versions stop receiving security patches.

Memory exhausted

If the log mentions allowed memory size, raise the limit in wp-config.php:

define('WP_MEMORY_LIMIT', '256M');

If that has no effect, the cap is set at server level and your host must change it.

A syntax error you introduced

If the error appeared the instant you saved a change in the theme or plugin editor, this is it. A missing bracket or semicolon stops PHP entirely.

The log names the file and line. Fix it or restore the previous version. This is also the strongest argument against editing live code through the dashboard — there is no undo, and a typo takes the whole site down.

When it is not a bug

Occasionally a critical error is the visible edge of something worse. Malicious code that fails partway through throws a fatal error like any other code, and some infections deliberately break the admin to slow down the response.

Be suspicious if the log points to a file you do not recognise, if the error appeared with no changes made, if it returns shortly after being fixed, or if there are administrator accounts nobody created. Our guide to removing malware from WordPress covers the next steps.

The order that works

  1. Check the admin email for the fatal error notice
  2. Use the recovery mode link if you have one
  3. Otherwise enable debug logging and read the log
  4. Deactivate the named plugin or theme by renaming its folder
  5. Update it, or roll it back to the previous version
  6. Check PHP version and memory limit if the log points there
  7. Turn debugging off and confirm the site works properly
Resist disabling things at random. The log almost always names the cause, and ten minutes reading it beats an hour of guessing.

Making it less likely

Almost every critical error follows a change that was not tested first. Use a staging site for updates. Keep backups so rolling back is a real option. Never edit live code through the dashboard. Confirm the admin email address actually works, so the recovery email reaches a human.

And run uptime monitoring. A critical error on a Friday evening can otherwise sit unnoticed until Monday, which is an expensive weekend.

Our managed website plans cover exactly that — updates tested on staging, backups, and monitoring so problems are caught quickly rather than discovered by a customer.

Still stuck?

If the log is unclear, or you have no dashboard access and would rather not risk making things worse, our WordPress error fixing service can take it from here. We diagnose the actual cause, fix it, and explain plainly what went wrong.

Get in touch with your web address and anything from the error email — that usually gets us most of the way there.

Get Shielded

We build, host, secure and monitor business websites — cleaning up hacks and keeping sites online for clients across the UK, USA, Australia and the UAE.

Keep reading

Chat on WhatsApp