You clicked update, and now something is wrong
It happens in a few familiar ways. The update screen finishes and the site goes blank or shows an error. Or everything loads, but the menu has vanished, the product pages look strange, or the contact form no longer submits. Sometimes you did not click anything at all: an automatic update ran overnight and you found out from a customer.
The useful fact is that you know roughly what changed. That is more than most broken sites offer, and it makes the repair far more direct. The aim is to get the site working again quickly, then work out whether the update can stay or needs to wait. If you are seeing a specific message rather than just odd behaviour, our guide to WordPress errors and what fixes them will help you name it.
Three kinds of update, three kinds of breakage
Plugin updates
These cause most post-update trouble. A new version may drop a feature another plugin relied on, require a newer PHP version than your server runs, or change how it outputs HTML so your theme’s styling no longer fits. When two pieces of code start fighting after one of them changes, the service page on plugin clashes explains how we narrow it down.
Theme updates
A theme update replaces the theme’s files completely. If anyone edited those files directly rather than using a child theme, those edits are gone the moment the update finishes. That is why a theme update so often ends with the layout looking wrong rather than a hard error. If your pages suddenly look unstyled or rearranged, our layout repair page goes deeper on that symptom.
WordPress core updates
Core updates are usually well tested, but an older plugin or theme that relied on behaviour core has since changed can break. Major core releases also sometimes update the database structure, which matters if you are thinking about going back to an older version.
When the update did not finish
While updating, WordPress puts a file called .maintenance in the site’s root folder and shows visitors “Briefly unavailable for scheduled maintenance. Check back in a minute.” If the update is interrupted, that file can be left behind and the message stays. Deleting .maintenance through the file manager usually clears it, though the interrupted update may also have left a plugin half-installed. Our post on getting a site out of maintenance mode covers this in detail. If WordPress emailed you to say an automatic update failed, the article on failed automatic updates explains what those messages mean.
What to do in the first half hour
Resist the urge to click update on everything else that is pending, or to restore the first backup you can find. Both can turn one problem into several.
- Write down what was updated and when. The Updates screen, the plugin list’s version numbers, a failure email from WordPress or your hosting panel’s file dates can all tell you. If several things updated at once, list them all.
- Take a copy of the site as it is now. Yes, even broken. If later orders, form entries or comments are in the database, you will want them, and a snapshot taken now means nothing tried from here on can lose them.
- Disable the most likely suspect. If you can reach the dashboard, deactivate the plugin that was just updated. If you cannot, rename its folder in
wp-content/pluginsusing FTP or the file manager. If the site comes back, you have your answer. - Check whether the site shows a WordPress error screen. If it says there has been a critical error, the fix for the WordPress critical error walks through reading the recovery email WordPress sends.
- Clear caches before judging. A caching plugin, the host’s cache or a CDN can keep serving the broken or the fixed version for a while. Check in a private browser window as well.
Rolling back: the options and their catches
Installing the previous version of one plugin
For plugins from the WordPress.org directory, older releases can usually be downloaded from the plugin’s page there, and tools such as the WP Rollback plugin make this possible from the dashboard. For paid plugins, previous versions are normally in your account on the vendor’s site. Going back one version is often the quickest way to restore service. The catch is that some updates change their settings or database tables on first run, and the older version may not read them correctly.
Restoring a backup
A full restore puts files and database back to a point in time, which fixes the breakage but also erases anything that happened since: orders, sign-ups, comments, edits. On a quiet brochure site that may be fine. On a shop it can quietly lose sales records. If a restore itself fails or produces new errors, our post about restores that do not go to plan explains the common reasons.
Downgrading WordPress core
This is the option we reach for least. Core updates may change the database, and an older core may not expect that. It also leaves you on a version without the latest security fixes. Usually it is better to fix or replace the plugin or theme that cannot cope with the new core.
Whatever you choose, a rollback is a pause, not a cure. Sooner or later the update needs to go on, because security fixes come with it.
Our approach when an update breaks your site
Start with a WhatsApp message or the contact form. Tell us which update ran, attach a screenshot, and say whether customers can still buy, book or reach you. After a look at the site we give you a straight account of the problem and a start time, and a store or booking system that is down is dealt with urgently.
The first step is a snapshot of the current state, so recent orders and messages are safe. The second is getting the site working, which normally means disabling or reverting only the update that caused the damage, not the whole site. We compare version numbers, changelogs and error logs to confirm which change is responsible rather than assuming.
Then we deal with the update itself on a staging copy of your site: we apply it there, find exactly what fails, and fix it. That might mean adjusting custom code, moving direct theme edits into a child theme so they survive the next update, replacing a plugin that has stopped being maintained, or waiting for a vendor fix with the old version held in place for now. Once it works on staging, we bring the update to the live site and check the pages that earn you money.
You get a short note of what broke, what we changed and what to watch for on the next round of updates. For clients in the USA or UK, our team is based in India and works IST hours; PayPal and Wise are both accepted.
Making the next update less dramatic
Signs an update is worth holding back
Not every update has to go on the day it appears. A few signals suggest waiting a little and testing first: the changelog mentions a major rewrite or a new minimum PHP version, the plugin’s support forum fills with reports of problems in the days after release, or the update touches something that handles money, such as a payment gateway or the cart. Security releases are the exception. When an update says it fixes a vulnerability, apply it promptly, on staging first if you can, but promptly.
Most of this can be avoided with a little routine: a fresh backup before each update, one plugin at a time rather than all at once, theme changes kept in a child theme, and important updates tried on staging first. The order you update things in also matters; our existing article on updating core, plugins and themes in the right order sets out a sensible sequence. If a plugin keeps causing trouble across releases, it may be time to replace it.
When the damage needs code-level work rather than a rollback, it moves into our service for fixing WordPress bugs.