Why updates sometimes break things, and why you still apply them
A WordPress site is the core software plus a theme plus plugins from different authors, updated on different schedules. Occasionally one update assumes a version of another that you do not have yet, and a layout shifts or a form stops sending. That is the risk. The alternative, not updating, leaves published vulnerabilities open on a site that automated scanners visit daily; most compromises we have cleaned up came through a plugin whose fix had been available for months.
So the answer is not to avoid updates; it is to make them safe. Backup, staging if you have it, a sensible order, and a check afterwards.
Backups first, and backups that restore
- A backup is the files (WordPress, theme, plugins, uploads) and the database (posts, pages, products, orders, settings). Both, or it is not a backup.
- Daily, automatic, stored off the site’s own server: your host’s backup service, or a backup plugin sending to cloud storage. A backup on the same server dies with the server.
- Keep at least two weeks of daily copies; a compromise is often discovered days after it happened.
- Test a restore quarterly, to staging or a local copy. A backup that has never been restored is a hope, not a plan.
- Before any update, take an on-demand backup as well, so the rollback point is minutes old.
The fifteen-minute routine
- Take a backup and confirm it finished.
- If your host provides staging, push the live site to staging and do steps 3 to 6 there first.
- Update plugins, a few at a time. Read the changelog for anything marked major or breaking. If a plugin has not been updated by its author in over a year, consider replacing it.
- Update the theme. If you have a child theme (you should, for any customised theme), the parent updates without losing your changes.
- Update WordPress core. Minor versions (6.8.1 to 6.8.2) are safe and can be automatic; major versions (6.8 to 6.9) deserve staging.
- Check: the homepage, one service page, one product page if a shop, the contact form (submit it), the checkout if a shop, and the site on a phone. Look at the browser console for errors if you know how.
- If anything broke: restore the backup, or deactivate the plugin you just updated and roll it back, then look for the fix.
- Note what you updated and when. Problems that appear two days later are usually traceable to the last round.
When to hand it to someone else
- The site is a shop. WooCommerce updates touch checkout, payments and stock, and a broken checkout costs orders every hour it is down. Staging is not optional here.
- A major version of the core, the theme, a page builder or WooCommerce is due. These are the updates that break things.
- The routine has stopped happening. If the dashboard shows twenty pending updates, the habit has gone and the site is exposed; that is the moment to buy the habit.
- PHP version changes at the host. Old plugins fail on new PHP; the host will usually warn, and the update needs someone who can read the errors.
This routine is the core of what a care plan does. Ours runs it weekly, with a backup before and a check after, as part of the £50 monthly that includes the hosting. Whether that is worth it depends on whether the fifteen minutes will actually happen every week; on most owner-run sites we take over, it has not for months.
