The short answer
"There has been a critical error on this website" means WordPress hit a PHP fatal error, usually from a plugin, theme or PHP version change. Check the site admin inbox for WordPress's recovery mode email, work out what changed last, and roll back that one thing. It is rarely a hack, and your content is still in the database.
What the message means
Since WordPress 5.2, when PHP hits a fatal error (code that can't continue), WordPress catches it and shows a plain page: "There has been a critical error on this website." Sometimes it adds a line telling you to check the site admin email inbox for instructions. Your content is still in the database. One piece of code has stopped pages from loading.
On older sites, and for errors the handler can't catch, the same fault shows as a blank white page, which is where "white screen of death" comes from. Different symptom, same kind of problem.
This page covers a broken site with no attacker involved. If you're seeing redirects, spam pages or admin users you don't recognise, go to hacked website cleanup instead.
Safe first checks
Look for the recovery mode email
When WordPress catches a fatal error it emails the admin address set under Settings, General, usually with a subject like "Your Site is Experiencing a Technical Issue". The email normally names the plugin or theme at fault and includes a recovery mode link. Logging in through that link pauses the faulty code for your session only, so you can reach the dashboard and deactivate or update it. Visitors keep seeing the error until you do.
Often the email never arrives. The admin address may belong to a past developer, or the server may not deliver mail sent from PHP. Check the spam folder, then carry on.
Work out what changed last
Critical errors rarely come from nowhere. Did a plugin or theme update, did automatic updates run overnight, did someone paste code into functions.php, has the host announced a PHP upgrade? The answer usually points at the cause.
Roll back that one change
Undo the single thing that changed. Without dashboard access, you can deactivate a plugin by renaming its folder in wp-content/plugins through your host's File Manager or SFTP, for example by adding ".off" to the name. WordPress treats a plugin it can't find as deactivated. The same trick works on the active theme, as long as a default theme is installed to fall back to. If you can't pin down the change, restoring from before the error is the next option, with one warning covered below.
Common causes
| Cause | What usually happened | Usual fix |
|---|---|---|
| Plugin update | The new version needs a newer PHP or WordPress version, or clashes with something else on the site | Roll back the plugin, then test the update on staging |
| Plugin conflict | Two plugins load different copies of the same library or declare the same function | Deactivate one, report it to the developer, or replace it |
| Theme or functions.php edit | A pasted snippet with a missing bracket, or a function that already exists | Correct or remove the snippet |
| PHP version change | The host moved the account to PHP 8 and old code calls functions removed in PHP 8.0, such as create_function() | Update the plugin or theme, or replace it if it has been abandoned |
| Memory limit | The log says "Allowed memory size ... exhausted", often during an import or on a heavy page builder layout | Find what is using the memory; raise WP_MEMORY_LIMIT only as far as the hosting allows |
| Disk full | Logs or backups filled the hosting space, so file and database writes fail | Clear space and stop whatever filled it |
| Interrupted update | WordPress core files were left incomplete | Replace core with a fresh copy of the same version |
Two messages look similar and aren't. "Error establishing a database connection" points at the database server or the credentials in wp-config.php. "Briefly unavailable for scheduled maintenance" means an update stalled and left a .maintenance file in the site root.
How we diagnose a critical error
- Back up the files and database as they are, so nothing we try can make things worse.
- Read the PHP error log. On cPanel hosting there is often an error_log file in the site folder. If not, we switch on WordPress debugging in wp-config.php: WP_DEBUG and WP_DEBUG_LOG set to true, WP_DEBUG_DISPLAY set to false, so errors are written to wp-content/debug.log instead of the screen.
- Find the file and line the fatal error names. That tells us whether the fault is in a plugin, the theme, a custom snippet or core.
- Fix it at the source or roll that component back, working on a staging copy when the fix isn't obvious.
- Test the pages that bring in money: contact forms, bookings, checkout and logins.
- Switch debugging off and delete debug.log, which anyone who knows the path could otherwise read.
- Explain in plain English what broke and what to change so it doesn't recur.
Often the first lines of the log name the culprit. The slower jobs are conflicts that only show on certain pages, and abandoned plugins that have to be swapped for something maintained.
What not to do while the site is down
- Don't delete the whole plugins folder or reinstall plugins at random. You might clear the error and lose settings the site relies on.
- Don't restore an old backup over a WooCommerce or booking site without thinking. Orders, bookings and form entries made since that backup are lost. Restore to staging and compare, or restore files only.
- Don't leave WP_DEBUG_DISPLAY on. It prints file paths and errors to every visitor.
- Don't drop PHP to an unsupported version as a permanent fix. The site comes back running software that no longer gets security patches.
- Don't keep clicking Update and hoping. Each attempt changes the evidence.
Preventing the next one
Critical errors are mostly an update problem, and the answer is a routine rather than avoiding updates. Skipping them trades a broken site for a hacked one.
- A staging copy where updates are tested first. Staging is part of our managed web hosting.
- Daily backups that are known to restore. See cloud storage and backup.
- Updates applied by someone who checks the site afterwards, with a rollback ready.
- PHP upgrades planned and tested in advance.
- Monitoring, so the error is found by us before a customer finds it. Our server maintenance page covers the monitoring we run, including disk space trends.
On sites we manage, our team applies updates and runs daily backups, and if something breaks after an update we roll back from a backup rather than leave you with a broken page. That is part of our managed support care plans, from $249 a month for hosting, updates, security and small changes. If the site is old enough that a new build makes more sense than another repair, see our WordPress website builds.
WordPress support from Brisbane
Our in-house team works from 1 Cheshire St, Pallara, and repairs WordPress sites remotely for businesses anywhere in Australia. We've been building and looking after websites for 17 years and host 200+ client sites on our own cPanel/WHM server. Send the site address and the exact error through the contact page, or call 07 3067 8910, Monday to Friday 8:30am to 5:30pm. We take a first look and quote the repair before starting. Want to talk about keeping it from happening again? Book a call.