wordpress critical error
Act now: secure access and limit impact
When the message There has been a critical error on this site appears, the aim is not to understand it first, but to take control without making the situation worse. Start by avoiding haphazard manipulations (chain reinstallations, random file deletions). If you have access to the hosting (FTP/SFTP + cPanel/Plesk-type panel) and/or the database, you can intervene properly. Otherwise, temporarily put the site into maintenance mode via your host (if possible) or block public access (server rules) to avoid an avalanche of visits, inconsistent caching and attack attempts during the incident.
If WordPress administration is inaccessible, first check whether an automatic e-mail from WordPress has been sent to the administrator address: since several versions, WordPress sometimes provides a recovery mode with a unique connection link. If it exists, use it immediately to deactivate the element in question (plugin or theme). If you receive nothing, you'll need to use FTP and/or activate debugging.
Understanding the trigger: plugin, theme, update or server
In most cases, the critical error comes from a fatal PHP error, often linked to :
- a recently activated or updated plugin ;
- an updated theme (or builder) ;
- PHP version incompatibility;
- insufficient PHP memory ;
- a conflict between extensions ;
- incomplete updates (core, plugins, themes) ;
- incorrect file rights or file corruption.
It's useful to distinguish this message from white errors and server errors: sometimes, the incident is more akin to an HTTP 500 error. To find out more about the causes on the server side, you can consult this external guide on common causes of a 500 error on WordPress (configuration, .htaccess, limitations, etc.).
Enable debugging cleanly (without exposing visitors)
To identify exactly which file and line is crashing, enable logging rather than public display. In the wp-config.php file, add (or adjust) these constants:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
The aim is to write errors to wp-content/debug.log. If this file doesn't fill up, check the write permissions on wp-content, or check the PHP/Apache/Nginx logs in your hosting interface. Once you've found the cause, reset WP_DEBUG to false.
Isolating the most likely cause: plugins
Plugins are the No. 1 suspect, especially after an update or the addition of an extension. Even if you can't access /wp-admin, you can deactivate plugins via FTP :
1) Connect via FTP/SFTP.
2) Go to wp-content/.
3) Rename the plugins folder to plugins-old.
WordPress no longer finds the plugins, so it deactivates them. If the site comes back, you've confirmed the plugin track. Next, restore the folder to its original name and rename the plugin subfolders one by one (or disable them from the admin) to identify the culprit.
To avoid this type of saturation and conflict, it's important to keep a logic of extensions: it's better to have fewer plugins, but ones that are well maintained and compatible. On this subject, this internal content is useful for framing your choices without going overboard: How many plugins can I safely install?
Discover our offers for WordPress website maintenance
Testing the theme: switching to a default WordPress theme
If deactivating plugins doesn't change anything, the theme (or a child theme) may be to blame: functions.php, WooCommerce overload, code added in the wrong place, incompatibility with a PHP update, etc.
To test without admin access: via FTP, go to wp-content/themes/ and rename the active theme folder. WordPress will then attempt to switch to a default theme (e.g. Twenty Twenty-Four) if available. If no default theme is installed, upload one from your computer (unzipped) to wp-content/themes/ and rename the old theme.
If the site comes back, you've isolated a theme problem. At this stage, avoid random prod patches: restore a stable version of the theme (from backup), compare the changes, and identify the offending file via the log.
Resolve incomplete updates (core, plugins, translations)
An interrupted update (timeout, network outage, memory limit) sometimes leaves WordPress in an unstable state. Typical indications: a failed update message, missing files, or a site that goes into critical error immediately after the operation.
If you suspect this scenario, check for the existence of a .maintenance file in the WordPress root: if it's stuck, delete it. Then restart updates properly (or restore from backup). For concrete cases of update and publication errors, please consult this external guide: failed update and publication: possible solutions.
Adjust memory and PHP environment (without masking the real bug)
Increasing memory can make a crash go away, but beware: if an extension has a memory leak or is running too-heavy tasks, you're just putting off the problem. That said, there is a reasonable minimum threshold, especially with WooCommerce, builders and security plugins.
Possible actions:
- Increase WP_MEMORY_LIMIT in wp-config.php (e.g. 256M).
- Adjust PHP-side memory_limit in hosting (if allowed).
- Check PHP version: some extensions require a minimum version. PHP version upgrades must be staged, as they can also trigger an error if an older plugin is not compatible.
- Check max_execution_time and max_input_vars if you observe failures during heavy actions (import, large builder pages).
Control .htaccess and server rules
A corrupted .htaccess or rules added by a cache/security plugin can cause a server failure or error. Even if the message displayed is critical error, the root may be on the rewrite side or directives forbidden.
Quick test: rename .htaccess to .htaccess-old, then reload. If the site comes back, regenerate the permalinks from the admin (Settings > Permalinks > Save) to recreate a clean .htaccess. Then gradually reintroduce the necessary rules (cache, security), validating at each stage.
Repair based on a structured method (not on a whim)
The more elements you change simultaneously, the more you lose track of the cause. A robust method looks like this:
1) Capture symptoms: page concerned, triggering action, time of appearance.
2) Read logs (debug.log + server logs).
3) Disable plugins, then reactivate one by one.
4) Test a default theme.
5) Check versions (WP/PHP), memory limits, .htaccess.
6) Revert to a backup if restoration is more expensive than rollback.
7) Correct the root cause (plugin to be replaced, theme to be patched, version upgrade, etc.).
If you would like a complementary repair-oriented step-by-step guide with different scenarios, this external guide is a good reference: how to repair the There has been a critical error message.
Restoring a backup: when it's the most cost-effective solution
If your site is in production (e-commerce, lead generation, SEO traffic), the aim is to reduce downtime. In many cases, restoring a healthy backup (files + database) is the quickest solution, provided :
- know the acceptable loss window (commands, forms, content) ;
- then reapply the staging update to reproduce the bug;
- avoid restoring too far and losing important data.
To set up a reliable (and effective) strategy, here's an in-house best-practice guide: How to save automatically without slowing down your site
After recovery: avoiding relapse (maintenance, staging, monitoring)
Once the site is back online, the work isn't over. Without preventive measures, the incident is likely to recur at the next update or peak load. The most effective actions :
Discover our offers for WordPress website maintenance
- Set up a staging environment to test updates (core, plugins, themes).
- Enable monitoring (uptime + alerts) and log monitoring.
- Plan and validate updates (compatibility, changelogs).
- Check admin performance: slow administration is often the symptom of a pile-up of requests, cron, or heavy extensions, which can also increase the risk of crashes during operations. On this point, this internal article helps to diagnose : Slow in Admin Technical Causes
Security: a crash can also be a warning signal
In some cases, the critical error occurs after a compromise: code injection, modified files, creation of a ghost admin, or server overload caused by bots. If you observe unknown files, redirects or suspicious accounts, consider the incident as potentially security-related.
Without multiplying the tools, adopt the fundamentals: regular updates, trusted plugins, strong passwords, limiting login attempts, consistent file permissions, and off-site backups. To delve deeper into WordPress security, you can read this external content : security tips and best practices.
And if you'd like to expand your troubleshooting toolbox (breakdowns, malfunctions, strange behavior), this external resource includes numerous case studies: quick fixes for various WordPress bugs.
When to delegate: save time, protect SEO and reduce risk
If your site is a business asset, the real question isn't just how to fix it, but how to keep it from costing more next time. WordPress maintenance covers just that: controlled updates, testing, backups, security, monitoring, and rapid intervention.
There's also a direct impact on visibility: unavailability, slowness, server errors and instabilities can degrade the experience and, ultimately, quality signals. To link maintenance and organic performance, this in-house content provides a useful angle: SEO and Maintenance Le Lien Invisible.
Summary action plan (check-list)
- Use the WordPress recovery link if available.
- Enable WP_DEBUG_LOG (without displaying errors to visitors).
- Deactivate all plugins (FTP), then reactivate them one by one.
- Switch to default theme (FTP) to confirm/infirm theme track.
- Check .maintenance, restart updates properly.
- Monitor PHP memory/versions and server logs.
- Test .htaccess (renaming) and regenerate permalinks.
- Restore a backup if the diagnostic time exceeds the acceptable rollback time.
- Set up staging + backups + monitoring for prevention.
Need for support: intervention and ongoing maintenance
If you prefer a rapid resolution with a framework (diagnosis, correction, securing, prevention), you can consult our support solutions. This not only helps deal with the current incident, but also greatly reduces the likelihood of it recurring in future site updates or upgrades.
To outsource or not to outsource: the right decision criteria
The best rule of thumb is simple: if site downtime costs more (lost sales, leads, reputation, SEO) than maintenance, it makes sense to delegate. Conversely, a small, low-stakes showcase site can get by with a minimal routine, provided you're disciplined about backups and testing.
To help you decide, depending on your context (complexity, risks, internal resources), this internal content can guide your decision: Why entrust maintenance to an agency?.
