The site was working, a red badge was inviting you to update, and one click later the home page is broken or the dashboard is out of reach. The first thing to say, because it changes the whole line of reasoning: a WordPress update that breaks the site is almost never the culprit. It is the telltale. It brings to light an incompatibility that was already there, between two plugins, with a theme edited by hand, or with a version of PHP that nobody was watching any more. Repair first, understand second, get organized last.
What actually breaks during a WordPress update
Four families of failure, and only one of them is genuinely unpredictable.
- A conflict between two plugins that alter the same thing. A caching plugin and an optimization plugin that both rewrite the page code, for instance. Each works on its own; the new version of one no longer tolerates the other.
- An abandoned plugin that has not kept pace with core. It calls a function that has been removed from WordPress, and the core update turns that call into a fatal error. The classic symptom is a white screen when the dashboard loads.
- A theme edited directly, with no child theme. The theme update overwrites the edited files, and all the customization work vanishes in a single operation. Reversible if a backup exists, permanent if not.
- A PHP version upgrade on the host’s side. The most insidious of the four, because the client did nothing themselves: the site breaks overnight without any update having been launched. As of August 2026, PHP 8.1 has reached end of life and PHP 8.2 receives security fixes only, until the end of the year (supported versions on PHP.net). Hosts are therefore migrating their fleets, with or without a notice that anyone actually read.
Rolling back without making things worse
There are three ways back. The right choice hangs on a single question: do you already know what broke?
A targeted rollback of one plugin
This is the least destructive option: it touches neither the content nor the rest of the site. Beware of a common confusion: since WordPress 6.3, if a manual plugin update fails, the previous version is restored automatically. But when the update succeeds technically and breaks the site, no native button will take you back down. You need either a plugin dedicated to version rollback, or the archive of the previous version fetched from the plugin’s public listing, or a command line:
wp plugin update plugin-name --version=3.4.2Write down the version you are leaving before you update: without that number, rolling back turns into an investigation.
Restoring the snapshot taken before the update
Quick and clean, provided your host or your backup tool takes an automatic snapshot before every update. The price is always the same: you lose whatever was created in the meantime. On a brochure site that is painless; on a shop, restoring to the day before wipes out a day of orders. The backup also has to work, which means having tested it: see website backups that actually work.
Rolling back through the code repository
When the site is tracked in a code repository, every change is recorded separately, with its date and its author. Undoing one specific change becomes a single command, without touching the content or the day’s orders. It is the difference between a surgical rollback and a bulldozer, and it is the reason we advise keeping your site in a Git repository as soon as it contains any custom code.
Finding the culprit in ten minutes
If rolling back is not possible, the faulty component has to be identified. The method is bisection, not trial one by one. Deactivate everything, check that the site comes back, then reactivate by successive halves: with thirty plugins, five rounds are enough where the naive approach takes thirty. Without access to the dashboard, the same thing is done by renaming the wp-content/plugins folder over FTP or from the host’s file manager.
Two shortcuts often spare you all of that work. The PHP error log frequently gives the name of the offending file in a single line, and therefore the name of the plugin: turn on WP_DEBUG_LOG and read wp-content/debug.log. And the Tools, then Site Health page shows the PHP version that is actually running, which is not always the one you think. If the site is completely unreachable, start with the emergency protocol for the first 60 minutes of a website outage.
The real subject: updating without playing roulette
Repairing once is pointless if the procedure stays the same. Five points, and they fit into a quarter of an hour a month:
- A backup verified just beforehand, not a backup assumed to exist. Verifying means opening the archive and looking at its date and its size.
- A run on a staging copy before the live site.
- A read-through of the changelog for the structural plugins: the ones that handle payment, forms, SEO or the page builder. Any mention of a breaking change earns a thorough test.
- Updating in batches, three or four components at a time rather than all twenty-seven at once. If something goes wrong, you know immediately where to look.
- A visual check of the sensitive pages afterwards: checkout, contact form, login page. A site can display perfectly and no longer take a single payment.
And one rule of organization that is worth every technique put together: choose an update window, a Tuesday morning for instance. One click at 6pm on a Friday means an entire weekend with a broken site, and your customers discovering the problem before you do (WordPress documentation on upgrading).
Our position: automatic or manual, the right answer is a mix
It is a debate that is usually left in a fog. We would rather come down on one side: automatic for the minor security releases of core, manual and supervised for everything else. WordPress already applies minor releases automatically, and rightly so: they are targeted fixes, tested at scale, and the window between a vulnerability being published and its automated exploitation is counted in days. Major releases, structural plugins and the theme, on the other hand, get updated when someone is available to look at the result.
The underlying reasoning is one of asymmetric risk. Not updating costs little today and a great deal in six months, when the site has been compromised or is too old to move forward. Updating too early costs a day of troubleshooting. Updating without a safety net, on the other hand, costs dearly straight away. That last case is the one to eliminate, and it is precisely what our supervised updates and technical support cover. The opposite has its price too, set out in what happens without website maintenance.
What a staging site changes
A staging site is a complete copy of the site, at a private, unindexed address, on which you test before touching the live site. The cycle has three beats: test, approve, apply. Whatever breaks breaks on the copy, in front of one person, with no customer, no lost order and no emergency.
Nor is it only for updates: it is also where pages get rebuilt, where new features are tried out and where a migration is prepared. It is, in our view, the one investment that genuinely removes the fear of updating, because it moves the risk off the site your customers see.
Testing before applying is exactly what our WordPress maintenance service in Pau covers.
Frequently asked questions
Can you switch off all updates?
Technically yes, strategically no. A frozen site becomes vulnerable within a few months, because the flaws fixed elsewhere are public and exploited automatically. The question is not whether to update, but in what order and with what safety net.
How do you know if a plugin has been abandoned?
Three signals are enough, all visible on its public listing: the date of the last update, the WordPress version it declares itself compatible with, and the activity in its support forum. Beyond a year without an update, assume it will not be fixed again.
Should you update PHP?
Yes, but after testing on a copy. A PHP version that has reached end of life no longer receives any security fixes, and many plugins stop supporting it. The upgrade is prepared, not improvised.
What if rolling back is impossible?
Fix forward: identify the faulty component precisely, replace it with a maintained equivalent, and document the fix. It is often the right decision when the plugin in question is no longer developed.
Conclusion
Fear of updates is not the symptom of a fragile technology; it is the symptom of a site with no safety net. A properly equipped site, with a tested backup, a staging copy and a history of its code, gets updated without anyone holding their breath. The first thing to do today is the simplest: open your latest backup and check that it really exists.
