What the critical error message actually means
When a visitor opens your site and sees nothing except the line “There has been a critical error on this website.” followed by a link to learn more about troubleshooting WordPress, PHP has hit a fatal error and stopped running. WordPress catches that failure and shows its own polite message instead of a raw error or an empty page. If you are logged in as an administrator, the wording is slightly longer and tells you to check your site admin email inbox for instructions.
That message is a safety net, not a diagnosis. It hides the real error from the public, which is good for security, but it also hides it from you. The real cause is written down somewhere else, and the first job is finding it. This page explains where to look, what you can try yourself, and how we handle it when you would rather hand it over. For the wider family of errors this one belongs to, our guide to common WordPress errors sets them side by side.
The recovery mode email: read it before you touch anything
When WordPress catches a fatal error, it usually sends an email to the address saved under Settings > General as the administration email. The subject line normally reads along the lines of “Your Site is Experiencing a Technical Issue”. Many owners delete it as spam, or never see it because that address belongs to a developer who left years ago.
The email is worth more than any guesswork. It typically contains:
- the name of the plugin or theme WordPress believes caused the failure;
- the error type and a message such as “Uncaught Error: Call to undefined function”, with the file path and line number;
- a special login link that opens the dashboard in recovery mode.
Recovery mode pauses the faulty plugin or theme for your login session only. You can then go to Plugins, see the paused extension flagged at the top, and deactivate it properly. Until you do that, ordinary visitors still see the critical error. People often log in through the link, see a working dashboard, and assume the public site is fine. It is not, until the extension is deactivated or fixed and you exit recovery mode.
When the email never arrives
No email does not mean no clue. The admin address may be wrong, the hosting server may not send mail reliably, or the message may sit in a junk folder. If your site rarely manages to send any mail at all, that is a separate problem worth fixing later; your host or an SMTP setup can usually sort it. For now, move to the error log.
The usual causes, roughly in the order we meet them
A plugin update that does not suit the rest of the site
Most critical errors we look at start the moment something was updated. A plugin calls a function that another plugin removed, or expects a newer PHP version than the server runs. If the error appeared straight after you clicked update, the page on a site that broke after an update walks through rolling back safely.
A clash between two extensions
Sometimes nothing was updated for weeks, then a new plugin is installed and the site falls over. Two extensions loading the same library, or a theme overriding something a plugin depends on, will often end in a fatal error. Finding which pair is at fault is its own job, and we describe it on the plugin conflict repair page.
The host changed the PHP version
Hosts retire old PHP versions on their own schedule. Code written for older PHP can stop working under a newer one, and the first sign is often this exact message. The email or log will usually mention deprecated or removed functions.
Memory running out
A heavy page builder, an import, or a large WooCommerce report can exhaust the PHP memory limit. The log line starts with “Allowed memory size of … bytes exhausted”. Raising the limit is sometimes the answer and sometimes only hides a plugin that is leaking memory; the log usually shows which plugin was running when memory ran out.
A code edit in the theme editor or functions.php
One missing semicolon or bracket in a theme file can stop the whole site. If someone recently pasted a snippet from a tutorial, start there.
What you can safely check yourself
Before changing a single file, make a full copy of the site: files and database. Your host’s panel often has a backup button. If something goes further wrong, that copy is how you get back to where you started.
- Search your inbox and spam for the recovery email. If you find it, note the plugin name and the file path it gives.
- Ask yourself what changed. An update, a new plugin, a snippet, a hosting message about PHP. Write it down with the time.
- Look at the error log. Many hosts show a PHP error log in the control panel. WordPress can also write its own log: adding
define( 'WP_DEBUG', true );anddefine( 'WP_DEBUG_LOG', true );towp-config.php, withWP_DEBUG_DISPLAYset to false so errors are not shown to visitors, sends messages towp-content/debug.log. Our walkthrough on switching on debug mode safely explains each line, and the post on reading an error log helps you make sense of the result. Turn debugging off again when you are done. - Disable the suspect plugin without the dashboard. Using FTP or your host’s file manager, open
wp-content/pluginsand rename that plugin’s folder, for example by adding-offto the end. WordPress treats a renamed folder as a missing plugin and deactivates it. If you do not know which one is at fault, renaming the wholepluginsfolder disables them all at once, which at least tells you whether a plugin is involved. - Test the theme the same way. If plugins are not the cause, renaming the active theme’s folder makes WordPress fall back to a default theme, as long as one is installed.
If renaming the folder brings the site back, do not just rename it back. Leave it disabled, then find out whether an update, a replacement or a fix to custom code is needed. Turning a broken plugin back on simply brings the error back.
Where DIY usually stops
Some situations are hard to untangle without a developer reading the code:
- the failing plugin is the one that runs your shop, bookings or memberships, so leaving it off is not an option;
- the error points to the theme, and the theme holds months of customisation;
- the log blames one file, but the real fault is a different plugin passing it bad data;
- the message comes back every few days, which usually means a scheduled task or a specific page is triggering it;
- you see files or admin users you do not recognise, in which case a hacked site investigation should come before any repair.
If the site keeps breaking in different ways, it is worth reading why some WordPress sites break again and again; the pattern behind repeated failures is often more useful to fix than any single error.
How we work on a critical error
You send us the error text, the recovery email if you have it, and a line about what changed. We reply with what we see and when we can start. A site that is down or a shop that cannot take payments is treated as urgent.
Once we have access, the first step is a fresh copy of files and database, so whatever we do can be undone. Then we read the actual fatal error, not the friendly message, and trace it to a file, a function and the change that triggered it. Where the host allows it, we reproduce the fault on a staging copy and test the fix there before applying it to the live site.
The fix depends on the cause. It might be rolling one plugin back, patching a line of theme code so it works on the current PHP, replacing an abandoned extension, or asking the host to restore a setting they changed. We tell you which, in plain language, and why.
When the site is working, we exit recovery mode, switch off any debugging we enabled, clear caches, and check the pages that matter to you: home, contact form, checkout, login. You get a short note explaining what broke, what we changed, and anything you should watch for. If you are in the USA or UK, note that our team works from India on IST, and payment from abroad is taken by PayPal or Wise.
A critical error is one of several faults our WordPress bug fixing service handles. If what you are looking at is a plain “500 Internal Server Error” from the server rather than this WordPress message, the 500 error repair page is the closer match.