Short answer: turn auto-updates on for minor WordPress core releases (they are on by default and you should leave them that way), on for plugins you could survive losing for an afternoon, and off for major core releases and for the two or three plugins that carry your money, your members or your forms. The question "are WordPress auto updates good or bad" has no single answer because auto-updates do not change whether something breaks. They change who is watching when it does. That is the variable you are really setting.
Version context (as of 2026-07-21): current stable is WordPress 7.0.2, released 2026-07-17. WordPress 7.1 is scheduled for 2026-08-19 and is in beta. WordPress 7.0 raised the minimum PHP version to 7.4, and WordPress.org recommends PHP 8.3 or greater.
What is actually switched on right now, before you touch anything
Most people arguing about auto-updates are arguing about four separate switches. They behave differently.
| What | Default state | Who decides |
|---|---|---|
| Minor core releases (7.0.1, 7.0.2, security fixes) | On automatically, and has been since WordPress 3.7 | WordPress core, unless your host or a constant overrides it |
| Major core releases (7.0 to 7.1) | Off. It waits in Dashboard > Updates for a click | You |
| Plugins | Off, per plugin. Since WordPress 5.5 there is an "Enable auto-updates" link on each row of the Plugins screen | You, plugin by plugin |
| Themes | Off, per theme, same mechanism on Appearance > Themes | You, theme by theme |
Two things follow from that table. First, if you have never opened a settings screen, you already have auto-updates. Minor releases have been installing themselves on your site for years, and that is the category that carries most security patches. Second, the argument people are usually having ("updates break my site, so I disable auto-updates") is almost always about the switches that were already off.
Some managed hosts override the core defaults from their own control panel. If the WordPress setting and your host's setting disagree, the host usually wins. Check the host panel before you conclude a setting did not take.
The rule that decides it: only auto-update what you can detect breaking
Every guide on this topic sorts by risk. That is the wrong axis, because the risk of a given plugin update is roughly the same whether you click the button or a cron job does. What changes is the gap between the moment it breaks and the moment a human notices.
Click it yourself and the gap is about thirty seconds, because you are looking at the site. Let it happen at 03:00 and the gap is however long it takes for a customer to email you.
So the honest rule is this: auto-update anything whose failure you would detect within your acceptable outage window, and hand-update everything else. That reframes the decision as a question about your monitoring, not your nerve.
Detection, cheapest to most reliable:
- You open the site most days. Detection window: about a day. Adequate for a personal blog, not for a store.
- Free uptime monitoring pinging the homepage every few minutes. Catches a white screen or a fatal error. Does not catch a checkout form that silently stops sending email.
- A monitor on the page that matters, not the homepage. The cart, the booking form, the members-only page.
- A transaction that fails loudly. If your payment gateway emails you on every sale, an hour of silence is itself an alarm.
If your answer to all four is no, you do not have a risk-appetite problem, you have a detection problem, and every auto-update you enable is a bet that nothing will go wrong while nobody is looking.
By site type
The personal or hobby blog: turn nearly everything on
Content in the database, a handful of plugins, no transactions, no logins from anyone but you. If it breaks at 3am, the cost is a few hours of downtime for an audience that will return.
Enable plugin auto-updates across the board and theme auto-updates too. Leave major core off, purely so that you choose the hour. The exception: any plugin doing something structural, such as a caching or security plugin that writes to configuration files.
The business brochure site: on for plugins, with two carve-outs
Ten pages, a contact form, and the phone number that pays the bills. Enable plugin auto-updates for everything except the contact form plugin and anything touching your booking or quote flow. Those are the failures nobody reports, because a form that stops sending email looks exactly like a quiet week.
Send yourself a test enquiry once a week. That is the whole monitoring program, and it is worth more than any setting.
The store, membership site or LMS: hand-update the money path
WooCommerce, a payment gateway, a membership plugin and their extensions form a dependency chain where an extension can lag the core plugin by days. An auto-update that lands the new major version of the platform before its add-ons catch up is the standard way these sites break.
Keep auto-updates on for the peripheral plugins (SEO, image tools, admin utilities). Update the money path by hand, on a staging copy, at an hour when you can watch it. See how to test an update on a copy of your site first for the mechanics.
The site with custom code or a heavily customized theme
Custom code depends on behavior that core is free to change between versions. If a developer built you something and is no longer around, auto-updates are gambling with a system nobody can repair. Keep plugin auto-updates on for third-party plugins, keep them off for anything custom, and read what actually happens during a WordPress update so the eventual error message means something.
The site you inherited and do not fully understand
The hardest case, and common. Do not mass-enable anything until you know what is installed and what it is for. Start with minor core (already on), leave the rest manual, and work through the pre-update checklist once before deciding.
What auto-updates will not do for you
They will not patch a plugin whose author has stopped shipping updates. An abandoned plugin with a known vulnerability sits there permanently at version 2.1.4, and auto-updates report everything as current because there is nothing to install. This is the failure mode the setting cannot see, and it is more common than a bad update.
They will not update anything installed outside the plugin directory's update channel, including many premium plugins whose license key has lapsed. An expired license usually means updates stop silently.
They will not fix a PHP mismatch. If your host is running PHP below the current minimum, updates will be blocked or will install onto a stack that cannot run them.
And they do not remove the need for a backup you have actually restored. A backup nobody has tested is a belief about a file, not a safety net.
Turning them on and off, and the one change to make first
Plugins: Plugins > Installed Plugins, then the "Enable auto-updates" link in the Automatic Updates column, per plugin. Themes: Appearance > Themes, click a theme, then "Enable auto-updates" in the details panel. Both toggle back off the same way, and no file editing is involved.
Before you enable anything: confirm your backups run and confirm you know the restore procedure. If a 3am auto-update takes the site down, the restore is the whole plan. Rolling back a WordPress update covers the undo path, and the broader picture of what changed in this release line is in the WordPress 7.x guide for site owners.
The honest trade-off
An outdated site is a more reliable way to get hacked than an updated one is to break. That is why the default answer leans toward on. But "enable everything and hope" is not the same argument, and the people who had a bad experience with auto-updates usually had one specific thing auto-update that they could not afford to lose, with nothing watching it.
Enable broadly. Carve out the two or three components that carry the value. Attach one detection method to each carve-out. That is the whole policy.
FAQ
Are WordPress auto-updates safe?
Minor core auto-updates are the safest category, which is why WordPress has enabled them by default since version 3.7: they are small, security-focused, and heavily tested. Plugin auto-updates are the riskiest, because plugin quality varies enormously and plugins depend on one another.
Does WordPress auto-update major versions like 7.0 to 7.1?
No. Major releases are not automatic by default. WordPress 7.1, scheduled for 2026-08-19, will wait in Dashboard > Updates until you click.
Should I turn off auto-updates entirely to stop my site breaking?
Rarely worth it. Disabling minor core updates leaves known security holes open for weeks. If updates keep breaking your site, the cause is usually a specific incompatible component, not updating itself.
Will auto-updates overwrite my customizations?
Core auto-updates do not touch your content, settings, plugins or theme files. A theme auto-update will overwrite edits made directly to that theme's files, which is why customizations belong in a child theme.
How do I know an auto-update ran?
WordPress emails the site admin address after a core auto-update, including when one fails. If you never receive these, check that the admin email is one you read, because that email is often the only notice you get.
