If you’re reading this with a broken website open in another tab: skip to the recovery steps below, they come first. The explanation of why this keeps happening can wait until your site is back.
Updates are the most common way working WordPress sites break. Not hackers, not hosting failures. Routine Tuesday update to a plugin, a theme, or WordPress core that conflicted with something else on the site. It’s so common that preventing exactly this is half the reason professional maintenance exists.
Last month a site came to us where an Elementor page builder update had silently broken the home page because of a version mismatch between PRO and standard Elementor; the owner found out three days later when a customer called. Ads running on an “empty” page, client ads budget wasted.
First: what “broken” looks like
Update failures usually show up as one of these:
- The white screen of death: a blank page, sometimes with a PHP error. Usually a fatal code conflict between the updated component and something else.
- “Briefly unavailable for scheduled maintenance”: stuck maintenance mode. The update was interrupted halfway; WordPress left its lock file behind.
- The site loads but looks wrong: broken layout, missing styles, weird spacing. Typically a theme update overwrote customizations, or a caching plugin is serving stale CSS against new HTML.
- Something specific stopped working: forms don’t send, checkout errors, images missing. The subtlest and most expensive kind, because nobody notices immediately.
Recovery, in the right order
1. Don’t keep clicking update on other things. The instinct to “update everything else and hope” compounds the problem and destroys the evidence of which change caused it.
2. Restore the backup, if you trust it. If you have a backup from before the update and you know it works, restoring is almost always faster than debugging. This is also the moment many owners discover their “backup” is six months old, stored on the same server, or was never actually tested. If that’s you, don’t restore blindly: a bad restore can make things worse.
3. No backup? Roll back the component. If you know which update broke things, the previous version of most plugins can be reinstalled from its own changelog/advanced view on WordPress.org, or via a rollback plugin, even if the admin still loads. Deactivating the suspect plugin via FTP (rename its folder in wp-content/plugins/) is the classic move when the admin is unreachable.
4. Stuck in maintenance mode? Delete the .maintenance file in the site root via FTP or your host’s file manager. Thirty-second fix.
5. Check the actual error. Enable WP_DEBUG_LOG in wp-config.php (never display errors on a live site) and read what PHP is actually complaining about. The error names the file, the file names the culprit.
6. If any of the above feels out of your depth, stop. Half of the rescue work we do is not fixing the original problem; it’s untangling the fixes that were attempted on top of it. Client came to us a few months ago after a junior developer tried to update plugins without checking the PHP version first. Instead of 15 minutes of work, we had a few hours of untangling to do.
Why this keeps happening
Here’s the part nobody explains to site owners. WordPress is an ecosystem: your site is WordPress core plus a theme plus typically 15–30 plugins, each written by a different team, each updating on its own schedule, each tested against WordPress, but not against each other, and never against your exact combination. Every update is a small compatibility experiment, and your live site is the laboratory.
Most updates are fine. But “most” multiplied across a couple hundred updates a year means a broken site is not bad luck, it’s a statistical certainty on a long enough timeline. The only question is whether the breakage happens somewhere safe or in front of your customers.
The boring solution: break the site where nobody can see it
The professional answer is unglamorous: test every update on a staging copy first.
A staging site is a private clone of your live site. Updates are applied there, checked: pages render, forms send, checkout completes and only then applied to the real site. When an update is going to break something, it breaks on the copy. Nobody outside ever knows.
This is the single clearest line between real maintenance and “auto-updates enabled” and it’s precisely what auto-updates can’t do, because auto-updates apply changes directly to production and no one looks at the result. Automated hosting maintenance has the same blind spot: it can apply updates, but it cannot notice that the mobile menu is now broken.
Across the 40+ sites we maintain, staging catches a breaking update roughly every few months. Updates that would each have been a live incident.
What a proper update routine looks like
For readers who want to do this themselves, this is the checklist, and it’s the same one we run:
- Verified, off-site backup taken before anything is touched
- Updates applied on staging, never live first
- Visual + functional check: key pages, checkout, mobile menu
- Updates promoted to live, same-day
- Post-update check on live (caches purged, forms re-tested)
- It’s written down: what was updated, what was blocked and why
Time cost: 30–90 minutes per site per cycle, done properly. That’s the honest reason maintenance costs money, and the honest reason “free” maintenance so often means “no maintenance.”
If your site is broken right now and you want it handled
We take over broken and half-recovered WordPress sites as a fixed-scope rescue: diagnose, restore or repair, then harden so the same failure can’t repeat. You’ll get a plain-English explanation of what happened. No blame, no jargon. And if you’d rather never think about updates again, that’s literally what our care plans are for: staging-tested updates on every site, every cycle.
Not broken, just worried? Start with the free Health Check. It will tell you, among other things, whether your backup would actually save you and how much update debt your site is carrying.