WordPress Site Down After Update: Step-by-Step Recovery Guide

WordPress not working after an update? Most outages have one of four causes: a stuck maintenance mode, a plugin conflict, an incompatible theme, or insufficient PHP memory. The first step is always the same - check the website administrator's email. Since WordPress 5.2, the system automatically detects fatal PHP errors and immediately sends an email with a recovery link. In most cases you can get back into your site without FTP access or touching any code, as long as you follow the steps in the right order.

Why Does WordPress Stop Working After an Update?

The most common cause is a plugin or theme incompatibility with the new version of WordPress or PHP. Every update changes parts of the core - and a plugin written for an older API may not work without errors with a new one. In practice, when managing websites we repeatedly encounter the same scenarios:

• Plugin conflict - one of the installed plugins is not compatible with the new WP version or with another plugin after the update.
• Incompatible theme - the theme uses deprecated functions that the new WP version removed or changed.
• Insufficient PHP memory - the update increased memory requirements and the server hits its limit.
• Interrupted update - the core update did not complete (internet outage, timeout), the site remained in maintenance mode.
• PHP version change on the server - the hosting provider changed the PHP version simultaneously, and some plugins do not work with the new version.

Good news: each of these problems has a proven solution. Check the symptom table below so you know where to start.

Symptom on the site	Most likely cause	First step
„Briefly unavailable for scheduled maintenance“ - page not displayed	Interrupted update, stuck .maintenance file	Delete the .maintenance file from the site root
„There has been a critical error on this website“	Fatal PHP error - plugin or theme	Check admin email, use the recovery link
White blank page (WSOD)	PHP error without recovery email, or PHP memory limit	Enable WP_DEBUG in wp-config.php
wp-admin works, front-end does not	Theme or page-builder plugin issue	Switch to default theme (Twenty Twenty-Five)
Site works, wp-admin does not	Security plugin, or 403 from firewall	Rename the plugins/ folder via FTP/file manager

First Step: the Recovery Mode Email from WordPress

Since WordPress 5.2: if a fatal PHP error occurs, the system immediately sends an email to the administrator's address with a link to recovery mode. This mechanism is built directly into the core - it does not require any plugin or special setup.

The email has a subject line similar to: „Your Site is Experiencing a Technical Issue.“ It contains:

• A description of the error and the file where it occurred (e.g. a specific plugin).
• A recovery mode link - a special URL, typically valid for one day.

Clicking the link takes you into wp-admin in recovery mode. WordPress in this mode blocks the problematic plugin or theme only for you, while other visitors can still see the site (possibly with an error, but without being harmed by further interventions). Deactivate the plugin the email identifies as the source of the error - the site usually recovers immediately. The full mechanism is described in the official WordPress recovery mode documentation.

If the email did not arrive or you cannot find it, check your spam folder. If it is not there either, the email address under Settings → General may be incorrect - and that is a signal to also check the email configuration on your site. For more on comprehensive WordPress site management, see our complete guide to WordPress site management.

Site Stuck in Maintenance Mode - How to Fix It in Two Minutes

The symptom is clear: the page displays the message „Briefly unavailable for scheduled maintenance. Check back in a minute.“ If this message persists for more than a few minutes, the update was interrupted and the site is stuck.

During every core, plugin or theme update, WordPress temporarily creates a .maintenance file in the site root directory. After a successful update it deletes it automatically. If the update was interrupted - for example by a connection drop, a server timeout, or simultaneous update of multiple plugins - the file remains and the site cannot recover on its own.

Steps: deleting the .maintenance file

1. Log in to the File Manager in your hosting cPanel, or connect via FTP.
2. Navigate to the WordPress root directory (usually public_html/ or the folder named after your domain).
3. Show hidden files (files starting with a dot are hidden by default - in cPanel choose „Show hidden files“).
4. Find the .maintenance file and delete it.
5. Reload the site in your browser - it should work immediately.

If you delete the file but the site still shows an error, the update genuinely failed and the cause is elsewhere. Continue with the following steps - the problem may be a plugin conflict.

„Critical Error“ or White Screen: How to Enable Debug Mode

If the site shows „There has been a critical error“ or a blank white page and the recovery email did not arrive, you need to identify the exact PHP error. WordPress has a built-in debug mode that is activated by adding constants to the wp-config.php file.

Open wp-config.php in the file manager or via FTP and insert the following just before the line /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

A full list of available debug constants is available in the WordPress debugging documentation.

Setting WP_DEBUG_DISPLAY to false ensures errors are not shown directly on the page to visitors - they are logged only to wp-content/debug.log. Open that file and look for the first line starting with Fatal error or PHP Fatal error. That line will tell you exactly which plugin or function caused the problem.

After diagnostics, remember to disable debug mode - set WP_DEBUG back to false or remove the lines. Debugging on production should only last as long as strictly necessary.

Special case: PHP memory limit

If debug.log contains the message Allowed memory size of ... bytes exhausted, the cause is not a plugin conflict but insufficient PHP memory. The fix is to increase the limit directly in wp-config.php by inserting the line define( 'WP_MEMORY_LIMIT', '256M' ); before the closing comment. If your hosting plan does not allow increasing PHP memory to at least 256 MB, the problem will recur after every major update - that is a signal the site has grown and the plan is underpowered.

How to Find the Problematic Plugin or Theme: Step by Step

When debug.log shows a plugin name, or you know the cause is a plugin but not which one, work systematically. The goal is to isolate the culprit without unnecessarily touching the database or settings.

When you have access to wp-admin

1. Go to Plugins and deactivate all plugins at once (check all, Bulk Action → Deactivate).
2. Check whether the site works. If it does, a plugin conflict is confirmed.
3. Activate plugins one by one and check the site after each activation.
4. When the error returns, the plugin you just activated is the culprit.
5. Leave it deactivated, contact the plugin author or look for an alternative.

When you have no access to wp-admin (FTP or file manager only)

1. Via FTP or file manager navigate to wp-content/.
2. Rename the plugins/ folder to plugins-off/. WordPress deactivates all plugins automatically.
3. Check the site. If it works, the cause is in one of the plugins.
4. Rename the folder back to plugins/.
5. Now inside plugins/ rename individual plugin subfolders one at a time (each plugin has its own subfolder) until you find the culprit.

If deactivating all plugins does not help, the problem may be in the theme. Rename the active theme's folder (e.g. themes/theme-name/ to themes/theme-name-off/) - WordPress will automatically activate the default theme and the site should work. For a fuller picture of safe update procedures - including how to use a staging environment - see our article on WordPress updates without the risk of breaking your site.

In practice managing client sites, we find that security and SEO plugins are the most common culprits - they tend to react to core changes more sharply than standard functional plugins. If you do not know what you last updated, look in the Plugins section at the „Last Updated“ column - plugins updated on the same day are the first candidates to check.

When to Restore a Backup and How to Do It

A backup is your last resort - and at the same time the fastest fix if you know a backup exists and is current. If the site is complex with many plugins, custom modifications or WooCommerce orders and diagnosis takes time, it is sometimes faster to restore the pre-update backup than to track down the culprit.

In practice this means having a backup no older than 24 hours before every major update. We covered the backup strategy in detail - including the 3-2-1 rule and restore testing - in our article on WordPress backup strategies. If no backup exists and the site is down, you may face a situation requiring manual database or code repair - work for a specialist.

Prevention: Why It Happens and How to Avoid It

A post-update outage is not bad luck - it is a symptom that the site has no safe update process in place. In practice when managing sites we see that sites without a staging environment have a significantly higher rate of post-update problems than sites with a properly configured process.

Three measures that almost eliminate post-update problems:

1. Back up before every update. Database and files. Always before, never after.
2. Update incrementally, not all at once. Core separately, plugins one by one - so you know exactly what caused a problem if one occurs.
3. A staging environment for more important sites. Test the update on a copy of the site first, then transfer to production. For sites with an e-shop or custom modifications this is the standard. For more on WordPress security hardening see our 10-point WordPress security checklist.

Summary: When You Cannot Solve It Yourself

Most post-update WordPress outages can be resolved on your own - recovery email, .maintenance file, plugin deactivation. If the site does not recover after going through all the steps, the problem may be deeper: incompatible custom code, a corrupted database, or a server-level conflict. In that case it makes sense to hand the repair to a specialist.

If you want to be sure that site updates happen without outages - now and in the future - as part of our monthly site support and care we back up before every update, test on staging, and resolve any conflicts before visitors see them. Free consultation - we will tell you honestly whether your site needs this kind of care.

FAQ

Frequently asked questions.

Why does WordPress show the message „There has been a critical error on this website“?

WordPress displays this message when a fatal PHP error occurs - most often caused by an incompatible plugin or theme. Since version 5.2 WordPress automatically sends an email to the administrator with a recovery link, through which you can access wp-admin and deactivate the problematic plugin.

How do I get into wp-admin when the site is not working after an update?

The fastest route is the recovery link from the WordPress email. If the email did not arrive, log in to your hosting file manager and rename the wp-content/plugins/ folder to plugins-off/ - WordPress will deactivate all plugins and wp-admin should become accessible.

How long does it take for a site to leave maintenance mode after an update?

If the update succeeded, it takes a few seconds. If the site stays in maintenance mode longer, the update was interrupted and the .maintenance file in the root directory was not deleted automatically - you need to delete it manually via FTP or file manager.

Is it a good idea to update all plugins at once?

No. When you update plugins one by one and check the site after each update, you immediately know which plugin caused a problem when one occurs. Bulk updating is faster, but when something breaks you have to search for the culprit among all the plugins updated at once.

What do I do when there is no backup and the site is not working?

Work diagnostically: enable WP_DEBUG in wp-config.php, identify the error file in debug.log, deactivate the problematic plugin via FTP. If the site does not recover even after deactivating all plugins and switching the theme, the cause may be a corrupted database or custom code - in that case we recommend a specialist.