If your WordPress site shows “There has been a critical error on this website”, that is a PHP fatal error: the site tried to run code it could not run, and stopped. Two things are true almost every time. WordPress has already emailed you the cause, and the cause is the last thing you changed. Start there, before you touch anything else.
Below is what the message really means, the fastest way to fix it, a table to match your situation to the likely cause, and the manual route for when no email arrives. If your site is a live shop and the checkout is down, skip to when it is not worth fixing it yourself.
The short version
The WordPress critical error is a PHP fatal error, and the cause is almost always the last plugin, theme or code snippet you touched. Three steps, in order:
- Log in at
/wp-admin/and read the message there — the wording is different from the front end, and it tells you whether WordPress emailed you. - Open your admin inbox and look for “Your Site is Experiencing a Technical Issue”. Its Recovery Mode link loads wp-admin with the broken extension already paused.
- No email? Turn on the debug log, read the last Fatal error line, and reverse the change it points at.
What the WordPress critical error actually means
People call it the WordPress critical error, the WP critical error, or just the critical error screen. It is one thing: a PHP fatal error that the site caught instead of dying silently.
Since WordPress 5.2, released in April 2019, a fatal PHP error no longer shows a blank white page. A feature called Fatal Error Protection catches the error, shows visitors the generic “critical error” message, and — the part most people miss — emails the site administrator a private link to Recovery Mode.
That email is the whole game. It usually names the plugin or theme that failed and the exact error, and its Recovery Mode link logs you into wp-admin with the broken extension paused, so you can fix or remove it without touching any files. In other words, the critical error is not a virus and not a lost site: it is one broken piece of code, and WordPress has already quarantined it for you.
The exact wording tells you whether the email was sent
WordPress does not print one message. It prints one of four, and which one you got is the first piece of diagnosis — before you touch a single plugin. The fatal error handler picks the wording from where the error surfaced and whether it managed to start Recovery Mode.
| The message you are looking at | Where you are | What WordPress already did | Do this first |
|---|---|---|---|
| “There has been a critical error on this website.” and nothing else | The front end, seen as a visitor | Deliberately told you the minimum — visitors get no detail | Log in at /wp-admin/ and read the message there instead |
| … “Please check your site admin email inbox for instructions. If you continue to have problems, please try the support forums.” | wp-admin or wp-login, single site | Started Recovery Mode and sent the recovery email to the admin address | Open that inbox — the email usually names the failing file |
| … “Please reach out to your site administrator, and inform them of this error for further assistance.” | wp-admin, multisite install | The same, but the email went to the network admin, not to you | Send whoever runs the network the exact message and the time it appeared |
| “… putting it in recovery mode. Please check the Themes and Plugins screens for more details.” | Already inside Recovery Mode | Paused the failing extension for you | Go to Plugins, or Appearance → Themes: the culprit is flagged there |
All four end with the same link, “Learn more about troubleshooting WordPress.” That link is generic documentation and the reason so many people paste the whole line into a search box. The sentence in front of it is the part that carries information.
The practical read: if your message is the bare one, WordPress never told you to check your email — but that does not mean no email was sent. It means you are standing on the front end, where WordPress says as little as possible on purpose. Log in and look again. If the message there mentions your admin email inbox, Recovery Mode started and the email exists, which makes the next section the fastest route back.
The fastest WordPress critical error fix: start with the email
- Open the inbox for your site’s admin email address (the one in Settings → General). Look for a message with a subject like “Your Site is Experiencing a Technical Issue”. It contains the Recovery Mode link and, often, the plugin or theme at fault and the error line.
- Click the Recovery Mode link. wp-admin loads with the failing extension paused. Go to Plugins (or Appearance → Themes) and you will see it flagged.
- If the culprit is something you just updated, that is your answer. Deactivate it, confirm the site is back, then either update again once its changelog says it supports your PHP version, or roll back to the previous version.
If the email never arrives, do not assume the worst — many sites simply cannot send email without SMTP configured. Move to the manual fix.
Match your situation to the cause
The critical error has a handful of common triggers. Match what you did last to the likely cause and the first thing to try.
| What you changed last | Likely cause | First fix | Call someone if |
|---|---|---|---|
| Updated a plugin | Plugin not compatible with your PHP or WordPress version | Deactivate it via Recovery Mode, or rename its folder in wp-content/plugins | It is your checkout, booking or membership plugin and you cannot lose it |
| Updated or switched theme | Fatal error in the theme’s code | Switch to a default theme (Twenty Twenty-Five) to confirm, then fix or replace | It is a custom theme with no backup or version control |
Edited functions.php or a code snippet | PHP syntax or fatal error in your edit | Undo the edit, or restore the file from a backup | You do not have the previous version of the file |
| Nothing — it appeared during an import or a traffic spike | PHP memory exhausted (WordPress defaults to just 40M for a single site) | Raise the limit in wp-config.php (see below) | Your host caps PHP memory at the server level and ignores the change |
| Moved host, or “updated everything” at once | PHP version mismatch across several plugins | Set a compatible PHP version in your hosting panel, then update extensions one by one | Several errors stack, or the log points at WordPress core |
If what you are looking at is not this message at all, the cause is somewhere else and so is the fix: a page that stays completely blank is covered in the white screen of death, and a database message has its own family of causes in “Error establishing a database connection”.
If no email arrived: the manual fix
No Recovery Mode email means you work from files. You need FTP or your host’s file manager, and a backup of wp-config.php and the database before you change anything.
1. Turn on the debug log
Edit wp-config.php and, just above the line that reads /* That’s all, stop editing! */, add:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Reload the site, then open wp-content/debug.log. The last line starting with Fatal error names the file — and therefore the plugin or theme — that failed. Keep WP_DEBUG_DISPLAY set to false so the errors go to the log, not onto the page where visitors (and bots) could read them.
2. Reverse the last change
If the log points at a plugin, deactivate it without wp-admin: in wp-content/plugins, rename its folder (for example woo-extra-thing to woo-extra-thing_off). If the site comes back, that plugin was the cause. If it points at your theme, switch the active theme back to a default one. Most critical errors end here, because most of them are a plugin you half-forgot you installed meeting a version it does not support.
3. If the log says memory is exhausted
A line like “Allowed memory size … exhausted” means a plugin or theme needed more PHP memory than it was given. Add this to wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );WordPress defaults to 40M for a single site, so 256M is a common, safe bump. If it changes nothing, your host is capping PHP memory at the server level regardless of this setting — that is a support ticket to your host, not another edit on your side.
When it is not worth fixing it yourself
The honest part. Reversing an update you made five minutes ago is not a job for anyone else — do it, and do not re-update until the plugin’s changelog says it supports your PHP version. You do not need us for that.
Where do-it-yourself turns expensive is a live shop. If the error names a payment or checkout plugin, or the site is mid-sale, do not experiment on the live site — every minute of a broken checkout costs orders, and renaming folders while customers are trying to pay is how a small problem becomes a bad afternoon. Take a backup, work on a staging copy, and switch back only once it is confirmed. And when two or three errors stack, or the log points at WordPress core or the database rather than one plugin, stop renaming folders: that is no longer a single broken extension, and someone should read the log properly. That is what our WordPress error-fixing service is for — backup first, diagnose the real cause, fix the broken part, no rebuilding.
Frequently asked questions
My message is longer than “There has been a critical error on this website” — is it a different error?
No, it is the same PHP fatal error. WordPress picks one of four wordings depending on where you are looking and whether Recovery Mode started: the bare sentence on the front end; “There has been a critical error on this website. Please check your site admin email inbox for instructions.” in wp-admin on a single site; “Please reach out to your site administrator, and inform them of this error for further assistance.” on multisite; and a longer one mentioning recovery mode once you are already inside it. All four end with the same link, “Learn more about troubleshooting WordPress.” The extra sentence is the useful part — it tells you whether the recovery email was sent, and to whom.
Does the critical error mean my site is hacked?
Almost never. A critical error is a PHP fatal error — a compatibility or code problem, not an intrusion. If you also see spam pages, unexpected redirects or admin accounts you did not create, that is a different problem: a compromised site that needs cleaning, not a one-line fix.
Will I lose my content?
No. The error stops code from running; it does not delete anything. Your posts, pages, media and WooCommerce orders are still in the database, untouched. Once the broken plugin or theme is removed or fixed, everything is exactly where it was.
I never got the recovery email — why?
Many WordPress sites cannot send email reliably because no SMTP is configured, so the recovery message never arrives. It is not a sign of anything worse. Use the manual route instead: turn on the debug log and reverse the last change.
The error shows only in wp-admin, or only on the public site — what does that tell me?
That the failing code runs in only one place. A plugin that loads a broken admin screen will break wp-admin while the front end still works, and the reverse happens with a front-end feature. The split narrows down which extension to suspect.
Can I just reinstall WordPress to fix it?
Rarely the right move. Reinstalling core does not touch the plugin or theme that is actually failing, and it can overwrite files you meant to keep. Find the failing extension first — reinstalling core is for corrupted core files, which is a small minority of these cases.
Sources (verified July 2026; the four message variants re-checked against WordPress core in August 2026): WordPress Developer — WP_Fatal_Error_Handler::display_default_error_template(); WordPress — Recovery Mode; WordPress Developer — Debugging in WordPress; Make WordPress Core — Fatal Error Recovery Mode in 5.2.