A blank page and one line of text
Instead of your homepage, visitors see a plain white page with the sentence "There has been a critical error on this website." Sometimes the admin area is broken too, so you cannot log in to undo whatever happened. An email from WordPress with the subject "Your Site is Experiencing a Technical Issue" might have gone to an address nobody checks.
Nobody changed anything, as far as anyone knows. That is usually because the change happened automatically.
What actually triggers it
| Trigger | How it happens without anyone touching the site |
|---|---|
| Automatic plugin or theme update | The new version conflicts with another plugin or with your theme |
| Host upgraded PHP | Old code uses functions that newer PHP no longer supports |
| Memory limit reached | A plugin or large import needs more than the server allows |
| Corrupted or partial update | An update failed halfway and left files missing |
| Custom code in the theme | A snippet added long ago stops working with a newer WordPress |
The message itself is deliberately vague, for security. The real cause is written to the server's error log, which is where diagnosis starts.
What the outage costs
While the error shows, the site produces nothing: no enquiries, no orders, and ad clicks landing on an error. If it lasts, Google may start treating pages as unavailable. The pressure also leads to panic fixes, such as deleting plugins from the server, which can lose settings and data.
Critical errors also have a habit of appearing at awkward times. Automatic updates and host maintenance often run overnight or at weekends, so the site can be down for hours before anyone in the business looks at it. The first sign is often a customer mentioning it, which is not how you want to find out.
How we get the site back and keep it up
- Read the PHP error log and WordPress debug log to find the exact file and line that failed, rather than guessing.
- Use WordPress recovery mode or, if needed, the server, to disable only the failing plugin or theme, bringing the site back while we work.
- Check whether the host changed the PHP version or memory limits, and whether an automatic update ran just before the failure.
- Fix the underlying problem: roll back to the previous version, update the conflicting component, correct the custom code or raise limits where that is genuinely the cause.
- Test the repaired site on staging, including forms, checkout and logins, before applying the fix to live.
- Route WordPress's own error emails to a monitored address, and add uptime and error monitoring that alerts someone when a fatal error appears.
- Put in place a staging and update routine, so the next update is tested before it reaches the live site.
After the repair
The site is back with the real cause fixed, not just the symptom hidden. You know what went wrong in plain terms. Future errors alert someone who can act, and updates are tested away from customers first.
Is this what you are dealing with?
- The site shows "There has been a critical error on this website"
- You cannot get into the WordPress admin
- Automatic updates are switched on for plugins
- Your host recently announced a PHP upgrade
- WordPress error emails go to an address nobody reads
- There is no staging copy to test fixes on