Every agency has the same discussion sooner or later. Updating by hand takes hours every week. Turning on auto-updates saves those hours, but then an update can break a client site in the middle of the night without anyone looking. Both choices have a cost. This guide explains what WordPress auto-updates really do, and how to set up a policy that keeps most of the time savings without the surprises.
What WordPress auto-updates do
- Core: minor WordPress releases (maintenance and security, for example from 7.1.1 to 7.1.2) are installed automatically by default. Major releases are not, unless you or the host turn that on.
- Plugins and themes: since WordPress 5.5 you can switch on auto-updates per plugin and per theme under Plugins and Appearance → Themes. They are off by default.
- A safety net for fatal errors: recent WordPress versions check whether the site still loads after a plugin auto-update, and step back to the previous version if the plugin causes a fatal PHP error.
What they do not check
That safety net only catches the most dramatic failure: a plugin that stops PHP. It does not notice a layout that falls apart on mobile, a contact form that no longer sends, a checkout that stalls, or a page builder that renders its sections as plain text. Those are exactly the problems clients notice first. Auto-updates also run whenever WordPress decides to, so the update can land during the busiest hour of a shop.
A practical policy for agencies
Instead of all or nothing, sort updates by risk:
- Low risk, automate: security releases of WordPress core, and small updates of simple, well-maintained plugins that do not change what visitors see.
- Medium risk, automate with a check: regular plugin updates. Let them run, but have something check the important pages afterwards, and be ready to roll back.
- High risk, test first: themes, page builders, WooCommerce and its extensions, and every major version jump. Run these on a staging copy first, check the pages that matter, then update the live site.
- Never automatic: sites with heavy customisation, or clients with a strict change process. Keep these manual and agree a maintenance window.
Three habits that make auto-updates safe
- Wait a few days after a release. Most broken releases are fixed within a day or two. Letting others go first removes a surprising share of the risk.
- Update one site first. When a plugin runs on twenty client sites, update one, check it, then the rest. If the first one breaks, the other nineteen are untouched.
- Always have a way back. A fresh backup right before the update, and a tested way to restore it, turns a broken update into a short incident instead of a lost day.
How Verploy automates updates safely
Verploy lets you automate on your own terms. With smart update rules you can choose to only fix vulnerabilities automatically, wait a few days after a new version is released, or only update once a version has gone live without problems on other sites. Out of the box it asks first. Every update is checked, and the risky ones are tested on a private copy of the site first. Updating one plugin on all sites goes in waves: one site, then two, then the rest. If something breaks after going live, Verploy rolls back from a snapshot taken just before. More on safe automatic updates.
Want the time savings of auto-updates without the surprises?
Every update is checked, and the risky ones are tested on a copy first. You choose what goes automatically. Start free on up to 3 sites, no credit card.