Short answer: your site is not fragile, and WordPress is not unusually unstable. Repeat breakage is caused by a small number of conditions that never got removed, and the reason they never got removed is that each incident was fixed as a symptom. Four conditions account for almost all of it: unmaintained components, customization stored where updates overwrite it, a server stack that does not match what WordPress now requires, and batched updating that makes it impossible to tell which change caused the failure. The last one is the cause of the other three persisting. Fix attribution first, and the rest becomes findable.
Version context (as of 2026-08-08): current stable is WordPress 7.0.2, released 2026-07-17. WordPress 7.1 is at Release Candidate 1 (published 2026-08-05) with final release scheduled for 2026-08-19. WordPress 7.0 raised the minimum PHP version to 7.4.
The uncomfortable reframe: you have an attribution problem
Here is the loop most sites are stuck in.
Nine updates are available. You click "update all", because that is what the button is for. Something breaks. You fix the visible symptom, or roll back, or deactivate whichever plugin looks guilty. The site works again. Six weeks later, eleven updates are available, and it happens again.
At no point in that loop does anyone learn which component caused it. Nine simultaneous changes produce one failure and no evidence. So the underlying cause survives every incident intact, and recurrence is guaranteed. The site is not getting more fragile. You are running the same experiment repeatedly without recording the result.
That is why the fix in this article is not a plugin or a setting. It is a habit that costs about five minutes per update cycle.
The four conditions that actually cause repeat breakage
1. Components nobody is maintaining
WordPress moves. A plugin that stopped receiving updates does not, and it fails a little more with each release until it fails completely. The same is true of themes.
This is the most common single cause of a site that breaks "every time", because unmaintained code is a permanent condition rather than a one-off event. Identify them and the pattern usually explains itself. What to do when a plugin you depend on is abandoned covers how to tell genuine abandonment from a plugin that is simply finished, and how to judge a replacement.
2. Customization stored somewhere an update overwrites
If somebody edited the theme's files, or added a custom template inside the parent theme folder, or edited a plugin directly, those changes are destroyed on every update of that component. The site then "breaks" in exactly the same way each time, and someone re-applies the fix, and the cycle is now formalized.
The tell: the same thing breaks after every update, and the fix is always the same edit. That is not a compatibility problem, it is a storage-location problem. Updating a theme without losing your customizations covers where each kind of change should live.
3. A server stack that is behind, or ahead
WordPress 7.0 raised the minimum PHP to 7.4, and WordPress.org recommends 8.3 or greater. Two failure shapes come from this: old PHP that current code cannot run on, and new PHP that old code cannot run on. Both produce errors that look like WordPress failing and are actually a mismatch.
Check at Tools > Site Health > Info > Server. Site Health also raises requirement issues on its Status tab, and it is the cheapest diagnostic on the site.
4. Volume
More components means more compatibility surface. A site with forty plugins is not forty times more likely to break than a site with one, but the relationship is not flat either, and much of the exposure is in plugins nobody has used in two years.
Counting is not the fix. Deleting the ones you do not use is.
The fragility audit: score your own site in fifteen minutes
Go down this list and count. Anything you answer badly is a permanent condition, not bad luck.
| Check | Where | A problem if |
|---|---|---|
| Plugins with no update in over a year | Plugins screen, then each plugin's page in the directory | Any of them handle logins, forms, uploads or payments |
| Plugins active but unused | Plugins screen | You cannot state what a plugin does for the site |
| Theme last updated | Appearance > Themes, then the theme's source page | Years of silence plus heavy customization |
| Direct file edits | Ask whoever built the site, or compare the theme folder to a fresh download | Anybody has ever edited theme or plugin files |
| PHP version | Tools > Site Health > Info > Server | Below the recommended version, or recently changed by the host |
| Site Health critical issues | Tools > Site Health > Status | Anything listed as critical |
| Premium licenses | Each premium plugin's settings | Any license expired, because updates stop silently |
| Backup restore | Your host panel or backup plugin | You have never performed a restore |
An expired license deserves particular attention, because from inside the dashboard it looks identical to abandonment: no updates appear, the plugin ages, and eventually it breaks.
The intervention: keep an update log
This is the part that ends the cycle, and it is almost never suggested. Five minutes per cycle, one table, kept anywhere.
| Date | What updated | What broke | Fix | Suspect |
|---|---|---|---|---|
| 2026-07-17 | Core 7.0.1 to 7.0.2, 6 plugins | Contact form stopped emailing | Reverted form plugin | Form plugin |
| 2026-08-08 | 4 plugins | Nothing |
After three entries a repeat offender is obvious in a way it never is from memory. Memory produces "it always breaks". A log produces "it is the same plugin, three times". Those are different problems and only one of them is solvable.
For the log to work, updates have to be separable. Which is the next part.
Batch smaller, and update in an order
You do not need to update one plugin per day. You need enough separation to attribute a failure.
A workable rhythm:
- Core alone, and check the site.
- Your critical plugins one at a time, the ones carrying money, forms, members or SEO, checking between each.
- Everything else in one batch. If that batch breaks something, you have narrowed it to a group you can bisect.
Order matters when a major core release is involved: update plugins and the theme first, then core, so that your components are as ready as they can be for the version they are about to meet. How to check plugin compatibility before updating covers how to work out which ones are at risk before you touch anything.
And check the right page. A homepage that loads proves very little. Check the page that would cost you money if it were broken.
Where auto-updates fit
If updates keep breaking your site, the instinct is to disable auto-updates entirely. That trade is worse than it looks: minor core releases carry most security patches and are the safest category to take automatically.
The better arrangement is selective. Auto-update the peripheral components, hand-update the ones carrying value, and attach one detection method to each hand-updated component. Should you turn on WordPress auto-updates works through this by site type, and the underlying rule is that auto-updates do not change whether something breaks, only how long it takes anyone to notice.
The permanent fixes, ranked by payoff
- Delete unused plugins. Free, immediate, and removes surface area permanently. Deactivated plugins still sit on the server as code.
- Replace or remove unmaintained components. The single biggest contributor to repeat breakage.
- Move file-level customizations into a child theme or the database. Ends the re-apply cycle for good.
- Get PHP onto a version WordPress recommends, with the host, and confirm the change can be reverted before making it.
- Set up staging, if the host offers it. This converts breakage from an incident into a rehearsal. See testing an update on a copy of your site first.
- Run the pre-update checklist each cycle, and keep the log.
What this cannot fix
Some breakage is genuinely not preventable at your end. A plugin author ships a bad release; a host changes PHP without notice; a major core release changes behavior a plugin depended on. Those will happen to a well-maintained site too.
The difference is what happens next. On an audited site with a log and a tested backup, that is twenty minutes and a rollback. On a site where nobody knows what is installed or why, it is a day. The goal is not a site that never breaks. It is a site where breakage is boring.
And the honest cost: every recommendation above takes time you would rather spend on the site itself. There is no version of WordPress maintenance that is free. There is a version that is predictable.
FAQ
Why does my WordPress site break after every update?
Almost always a persistent condition rather than bad luck: an unmaintained plugin or theme, customization stored in files that updates overwrite, or a PHP version that does not match what WordPress needs. Batched updating hides which one, so it never gets removed.
Is WordPress just unstable?
Core itself is heavily tested before release, and 7.1 went through beta and release candidate stages before its scheduled 2026-08-19 release. Most post-update failures come from third-party plugins and themes, which are maintained independently and to widely varying standards.
How many plugins is too many?
There is no number. Unused and unmaintained plugins are the problem, not the count. Ten plugins nobody maintains carry far more risk than thirty that are actively developed.
Should I stop updating to stop the breakage?
No. An outdated site with known vulnerabilities is a more reliable way to have a serious incident than an updated one is to have a broken layout. Change how you update rather than whether you update.
What is the single cheapest thing that reduces repeat breakage?
Deleting plugins you do not use, followed by keeping a short update log. Neither costs money and both attack the cause rather than the symptom.
