The update that nobody will press
The dashboard shows a red badge: twenty-three updates available. Some are years old. Everyone remembers the time someone clicked "update all" and the homepage turned into an error message on a Friday afternoon. Since then the rule is simple: nobody touches the updates.
The site still works. But every month the backlog grows, the gap between your versions and the current ones widens, and the next update becomes more likely to break something than the last.
Why updates break sites
WordPress core, plugins and themes are written by different people and updated on their own schedules. Breakage usually comes from how those pieces interact on your particular site.
| Cause of breakage | What it looks like |
|---|---|
| Theme or custom code relies on something a plugin changed | A layout or feature stops working after the plugin update |
| Two plugins conflict after one updates | White screen, critical error or a broken admin page |
| Plugin now needs a newer PHP version | The site falls over on older hosting |
| Customisations were made directly in plugin files | The update overwrites them and the feature vanishes |
| Several major versions skipped at once | Too many changes land together to diagnose |
The deeper cause is updating directly on the live site with no copy to test on and no quick way back. That turns each update into a bet.
What not updating costs
Most WordPress compromises come through known vulnerabilities in outdated plugins and themes, and those vulnerabilities are published, so attackers know exactly what to look for. Every skipped update keeps a door open.
It also changes who can work on the site. A developer asked to add a feature to a site several major versions behind has to catch up the updates first, or work around them, and both cost more than the feature itself. Some will simply decline the job. The site ends up frozen, not because anyone decided it should be, but because every change now carries the weight of the skipped updates.
The backlog also makes change harder. New features, new plugins and even hosting upgrades become risky because the site is built on old versions that will not work with them.
How we make updates safe again
- Take a full backup of files and database, and confirm it restores.
- Create a staging copy of the site on the same PHP version and configuration as live.
- Catch up the backlog on staging in controlled steps: core, then plugins in small groups, then the theme, testing key pages, forms and checkout after each.
- Fix what breaks, moving any customisations out of plugin and theme files into a child theme or a small custom plugin, so updates cannot overwrite them.
- Replace plugins that are abandoned or incompatible with maintained alternatives.
- Deploy the updated site to live at a quiet time, with the backup ready to restore if anything unexpected happens.
- Set up a routine: updates tested on staging on a regular cycle, automated visual checks of key pages, and a documented rollback.
Security fixes are the exception to the cycle. When a plugin you use has a published vulnerability, it gets tested and applied as a priority.
What the routine gives you
Updates stop being an event. They happen regularly, are tested before customers see them and can be reversed if needed. The site stays current, so new features and hosting changes are possible. Nobody has to be brave on a Friday afternoon.
Is your site stuck like this?
- The dashboard shows a long list of pending updates
- An update broke the site once and nobody has updated since
- There is no staging copy of the site
- Someone edited plugin or theme files directly
- You are not sure when the last backup was tested
- Security plugins warn about vulnerable versions