Key facts
- The message appears when WordPress catches a PHP fatal error and shows a safe fallback page
- WordPress emails the site admin a recovery mode link that lets you log in with the faulty plugin or theme paused
- Setting WP_DEBUG_LOG to true writes the exact error, file and line to wp-content/debug.log
- Renaming a plugin's folder by SFTP or file manager deactivates it without the dashboard
- A host upgrading PHP, for example from 7.4 to 8.x, is a frequent trigger for older plugins
- Memory exhaustion errors can be eased by raising WP_MEMORY_LIMIT, but the real cause still needs finding
- dijitul fixes critical errors remotely at £45 an hour + VAT
What the critical error actually means
Since WordPress 5.2, when a PHP fatal error stops a page from loading, WordPress shows 'There has been a critical error on this website' instead of a blank screen or a raw error dump. Sometimes it adds 'Please check your site admin email inbox for instructions.' The site itself is not deleted. Something in the code it runs has crashed.
The usual culprits, in rough order, are: a plugin that has just updated, a plugin that is not compatible with your PHP version, a theme update or edit to functions.php, a WordPress core update that a plugin was not ready for, and the server running out of PHP memory.
Step 1: use the recovery mode email
Check the inbox of the email address set as the WordPress admin email (Settings, General). Look for a message titled 'Your Site is Experiencing a Technical Issue', and check spam too. It names the plugin or theme that caused the error and contains a special login link.
- Click the recovery mode link and log in as normal.
- WordPress pauses the faulty plugin or theme for your session only.
- Go to Plugins, deactivate the named plugin, then exit recovery mode.
- Check the front of the site in a private browser window.
The link expires after a short time. If the email never arrived, which is common when a site's mail is not set up properly, move to step 2.
Step 2: find the exact error in debug.log
Open wp-config.php in your host's file manager or over SFTP. Above the line that says 'That's all, stop editing!', add or change these lines:
- define( 'WP_DEBUG', true );
- define( 'WP_DEBUG_LOG', true );
- define( 'WP_DEBUG_DISPLAY', false );
Reload the broken page, then open wp-content/debug.log. Look for a line starting 'PHP Fatal error'. It will name a file path such as wp-content/plugins/some-plugin/includes/class-x.php and a line number. The folder name tells you which plugin or theme is at fault. Common messages include 'Uncaught Error: Call to undefined function', 'Allowed memory size exhausted' and 'Cannot redeclare'.
Turn WP_DEBUG back to false once you are done, and delete the log, because it can reveal server paths to anyone who finds it.
Step 3: disable the faulty plugin or theme
Without dashboard access, go to wp-content/plugins and rename the faulty plugin's folder, for example from contact-form-x to contact-form-x-off. WordPress deactivates it on the next load. If you do not know which plugin it is, rename the whole plugins folder to plugins-off, check the site loads, then rename it back and reactivate plugins one at a time.
If the error is in your theme, rename the active theme's folder in wp-content/themes. WordPress will fall back to a default theme such as Twenty Twenty-Five if one is installed. If the log mentions memory, you can add define( 'WP_MEMORY_LIMIT', '256M' ); to wp-config.php as a short-term fix, but a plugin eating memory still needs investigating.
Step 4: check whether your host changed PHP
If nothing on the site changed but it broke overnight, your host may have upgraded PHP. Older plugins written for PHP 7.x often fail on PHP 8 because of removed functions and stricter type handling. Many control panels let you switch back temporarily, which gets the site up while the plugin is updated or replaced. Do not stay on an old version for long: see our guide to PHP end of life.
When to call dijitul
Call us if the log points at a plugin you cannot simply switch off (a booking system, WooCommerce, a page builder), if the error is in custom code, or if you would rather not edit wp-config.php on a live site. We fix the cause, not just the symptom, and test the site before handing back. One-off fixes are £45 an hour + VAT. If a blank page rather than a message is your problem, see the white screen of death guide.
Our WordPress support plans start at £25 a month + VAT and include updates applied and checked, daily backups and monitoring, which is how most critical errors are avoided in the first place. Get in touch if your site is down now.
Frequently asked questions
Is my WordPress site deleted when it shows a critical error?
No. Your content, database and files are still there. The critical error means a piece of PHP code crashed while building the page. Once the faulty plugin, theme or setting is fixed or disabled, the site normally comes back exactly as it was.
I did not get the WordPress recovery mode email. What now?
Many sites cannot send email reliably, so the recovery message never arrives. Check spam, then use debug.log to find the faulty file, or rename the plugins folder over SFTP or your host's file manager. dijitul can do this remotely if you share hosting access.
Can a WordPress update cause a critical error?
Yes. A plugin, theme or core update can introduce code that clashes with another plugin or your PHP version. That is why dijitul applies updates and then checks the site afterwards on every support plan, with a backup taken first so a bad update can be rolled back.
How much does it cost to fix a WordPress critical error?
dijitul charges £45 an hour + VAT for one-off fixes, with a 30-minute minimum and then 15-minute blocks. A simple plugin conflict is often fixed within the first hour. If custom code needs rewriting, we tell you upfront before doing more work.
Is it safe to leave WP_DEBUG turned on?
Not on a live site. Debug output and log files can expose server paths and plugin details that help attackers. Use WP_DEBUG_LOG with WP_DEBUG_DISPLAY set to false while you diagnose, then switch debugging off and delete wp-content/debug.log.
Why does only the WordPress admin show a critical error?
If the front of the site works but wp-admin crashes, the fault is usually in a plugin's admin code, a dashboard widget or an admin-only page builder screen. The debug.log steps still apply, and recovery mode works for admin errors too.
Related
Get it fixed
One-off fixes are £45 an hour + VAT. You'll know the likely cost before we start.