It depends on the site. WordPress 5.5 added dashboard controls for plugin and theme auto-updates, off by default, and the core team calls keeping everything updated an easy way to stay safe from known vulnerabilities. For small brochure sites, turn them on for trusted plugins. For revenue critical sites, update on a schedule through staging.
What WordPress actually does
The core team's announcement for WordPress 5.5 explains the setup. WordPress core is configured to update itself automatically for new minor versions. Plugin and theme auto-updates became a dashboard feature, with an Automatic Updates column on the Plugins page, and the announcement notes they are disabled by default. Administrators must turn them on. Language packs for plugins and themes have always updated automatically.
Developers and hosts can adjust this. The announcement lists filters that disable the user interface elements for plugin and theme auto-updates. It also stresses that hiding the UI does not itself switch auto-updates on or off.
The trade-off
| Choice | You gain | You risk |
|---|---|---|
| Auto-update on | Faster patching of known flaws | A bad release reaches production without a test |
| Auto-update off | You control timing | Known flaws stay open while updates wait for you |
| Scheduled updates via staging | Both speed and testing | Needs someone to own the routine |
Neither extreme is free. Leaving a known vulnerability open for weeks is a real exposure. A broken checkout caused by an untested update is a real cost too.
A decision guide by site type
Brochure site, few plugins, no transactions. Turn auto-updates on for well maintained plugins, keep backups, and check the site weekly.
Membership or content site with some custom code. Auto-update plugins that do not touch core features, such as small utilities. Update critical ones manually on a schedule after testing.
Store or site that takes payments. Keep auto-updates off for the plugins that handle orders, payments and login. Update through a staging copy within a fixed window, and shorten that window when a plugin has a known active vulnerability.
Agency managing many sites. Use a routine with staging, backups and a rollback step per site, and document it in your runbook.
A safe update routine
- Back up the files and database before any update.
- Update on a staging copy and test the main paths: login, forms, checkout and key pages.
- Apply to production in a quiet period.
- Check logs and error pages afterwards.
- Keep the previous version available for rollback. Our guide on updating store plugins with a rollback plan goes deeper.
Add a vendor trust check
An auto-update trusts the plugin author's next release. For plugins with a history of ownership changes, new network calls or reduced maintenance, switch to manual review. The article on guideline 18 explains why control of a plugin can change.
Set a patch window
Decide how long a known vulnerability in an installed plugin may wait. Many teams set a short window for anything actively exploited. Write the number down so the decision is not made under pressure.
Safeguard's vulnerability management and continuous monitoring help teams track known issues across the software they own, and the interactive demo below shows how monitoring surfaces new advisories.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the monitoring view and watch how a newly published advisory is matched to something you already run.
Quick check
Are WordPress plugin auto-updates on by default?
No. The WordPress 5.5 announcement says plugin and theme auto-updates are disabled by default and must be enabled by an administrator.
Does hiding the auto-update interface turn auto-updates off?
No. The filters described in the announcement control whether the interface is shown, not whether auto-updates are enabled.
Sources
Last reviewed: 19 October 2026.
