There has been a critical error on this website. Here is what that means.
WordPress hit a fatal PHP error and stopped loading rather than showing visitors a broken page. Your content and database are almost certainly fine. In most cases this is one plugin, one theme, or one setting, and it is fixable. This page walks through the full diagnostic path, starting with the fastest thing to check.
First, what actually happened
Since WordPress 5.2, when PHP hits a fatal error the site shows this generic message instead of a blank white screen or a wall of technical detail that would tell an attacker how your site is built. Three things happen at the same moment: visitors see the message, WordPress emails your admin address explaining what broke, and it activates recovery mode so you can still reach the dashboard. The message is deliberately vague to visitors. The email is not. That email is the single fastest route back into your site, and most people do not know it exists.
The fastest way back in, in order
Work down this list. Most sites recover somewhere in the first three steps. Do not start updating other things while the site is down, and do not make several changes at once, because that destroys the evidence of what actually broke.
Check your admin email for the recovery link
Look for a message with the subject line "Your Site is Experiencing a Technical Issue". Check spam and junk too, because it often lands there. That email usually names the exact plugin or theme that caused the fault and contains a time-limited link that logs you into the dashboard in recovery mode, with the broken component paused. If it is there, this is a five-minute fix.
No email? Try the recovery URL directly
Visit yourdomain.com/wp-login.php?action=entered_recovery_mode and see whether it lets you in. The email commonly fails to arrive because the site cannot send mail at all: no SMTP configured, DNS not set up, or the host blocking PHP mail. That is a separate problem worth fixing later, but it should not stop you now.
Turn on the debug log to see the real error
The visitor-facing message is vague on purpose. The underlying fatal error is specific and names a file and line number. Edit wp-config.php and add these lines above the "That's all, stop editing" comment: define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ). Reload the site, then read /wp-content/debug.log. The last fatal error line tells you the file responsible, which usually tells you the plugin.
Rule out plugins by renaming the folder
This is the step that resolves the majority of cases. Connect over FTP or your host's file manager, go to /wp-content/, and rename the "plugins" folder to "plugins-off". That deactivates everything at once. If the site loads, a plugin is your culprit: rename the folder back, then deactivate plugins one at a time from the dashboard until the site breaks again. The last one you touched is the problem.
Rule out the theme
If plugins were not the cause, rename your active theme's folder inside /wp-content/themes/. WordPress falls back to a default theme like Twenty Twenty-Four if one is installed. If the site loads on the default, the fault is in your theme, most often in functions.php, an incomplete update, or code that a newer PHP version no longer accepts.
Raise the PHP memory limit
Memory exhaustion causes a surprising share of critical errors, particularly on WooCommerce stores, Elementor sites and anything with a heavy plugin stack. In wp-config.php set define( 'WP_MEMORY_LIMIT', '256M' ). If your host allows it, raise the PHP memory limit in their control panel too, because the WordPress constant cannot exceed what the server permits.
Check whether the PHP version changed
If the error appeared right after a hosting change or an automatic PHP upgrade, an older plugin or theme is probably using syntax that the newer PHP no longer supports. Temporarily switching back to the previous PHP version in your hosting panel will confirm it. That is a diagnosis, not a fix: the real answer is updating or replacing whatever is incompatible.
The common causes, in rough order of likelihood
Knowing which of these you are dealing with is most of the work. The debug log usually tells you within seconds, which is why step three above matters more than it looks.
What not to do while your site is down
Most sites that end up genuinely hard to recover got that way in the twenty minutes after the error appeared, not from the original fault.
Where this stops being a DIY job
The steps above genuinely work, and if you can follow them you do not need to pay anyone. These are the points where most site owners hit a wall, and there is no shame in any of them.
You do not have FTP access
Half the steps above need file access, and plenty of site owners have never had those credentials, or inherited a site from a developer who never handed them over. Your host can usually provide them, but working out who your host even is can take longer than the fix.
The debug log means nothing to you
A line reading "PHP Fatal error: Uncaught Error: Call to undefined function" followed by a file path is perfectly clear if you write PHP and completely opaque if you do not. Knowing which part of that line matters is the difference between a ten-minute fix and an afternoon.
The culprit plugin is one you actually need
Finding the broken plugin is only useful if you can live without it. When the fault is in your booking system, your payment gateway or your page builder, deactivating it is not a fix, it is a different outage. That case needs someone to repair the conflict rather than remove the feature.
The site is a store and every hour costs money
Working methodically through seven steps is the right approach when the stakes are low. When a store is down during business hours, the calculation changes, and paying someone who has done this a hundred times is usually cheaper than the lost orders.
It looks like more than a fault
Unexplained admin users, files modified at times nobody was working, redirects to sites you do not recognise. If the critical error came with any of those, patching it leaves the actual problem in place.
You fixed it and it came back
A fault that returns after a fix means the root cause was never addressed, only the symptom. Usually that is a deeper incompatibility, a server-level constraint, or an automatic update quietly reinstalling the thing you removed.
We can fix it for you
Free diagnosis first, so you know the cause and the price before committing to anything. Fixed quote, no open-ended hourly billing. VAT is added where applicable.
Critical error fix
One site, one fatal error- Free diagnosis before you commit to anything
- We identify the exact cause, not just the symptom
- Fix implemented and tested
- Root cause addressed so it does not simply return
- Written summary of what broke and what changed
- Advice on preventing a repeat
- Fixed price agreed before work starts
Fix plus hardening
When the fault revealed a bigger problem- Everything in Critical error fix, plus:
- Full review of the plugin and theme stack
- Abandoned and conflicting plugins identified
- PHP version and memory configuration corrected
- Update strategy so this stops recurring
- Backup verification, because most backups are untested
- Staging environment set up if you do not have one
Suspected compromise
The error came with signs of a hack- Malware scan and manual file investigation
- Backdoor and injected code removal
- Entry point identified and closed
- Google blacklist removal if needed
- Security hardening after cleanup
- 14-day recurrence warranty
- WooCommerce stores from €699
Not sure this is a critical error at all? See WordPress help if the symptom is unclear, or WordPress fixes for other faults. If your store checkout specifically is failing, see checkout fixes.
How to make this the last time
Critical errors are rarely bad luck. Four habits prevent the large majority of them.
Test updates somewhere that is not your live site
Almost every critical error we see traces back to an update applied directly to production. A staging copy costs little, is offered free by many hosts, and turns "the site is down" into "the staging site is down and nobody noticed". If you take one thing from this page, take this one.
Know whether your backups actually restore
A backup plugin showing green checkmarks is not the same as a backup that works. Plenty of people discover on the worst possible day that their backups were incomplete, corrupted, or stored on the same server that just failed. Test a restore once, to a staging site, so you know where you stand before you need to.
Audit the plugin stack occasionally
Most sites accumulate plugins nobody has looked at in years, including some the original developer installed and abandoned. Every plugin that has not been updated in over a year is both a security risk and a future fatal error waiting for the next PHP upgrade. Removing what you do not use is free and reduces the surface area considerably.
Make sure the admin email is one you read
The recovery mode email is the fastest route back into a broken site, and it goes to whatever address is in Settings, General. On a lot of sites that is still the developer who built it in 2019. Check it now, while nothing is on fire, and confirm the site can actually send mail at all.
Questions people ask when this happens
Still stuck?
Send us the site address and, if you have it, the last few lines of the debug log. We will tell you what caused it and what fixing it costs. Free diagnosis, fixed quote, and if it is something you can fix yourself we will say so.
