Yes, enable auto-updates for WordPress core minor and security releases. Be far more careful with plugins, themes, and major core versions, because that is where sites break: page builder conflicts, ACF field groups going blank, checkout fatals, PHP incompatibility. The fix is not switching updates off. It is running them on staging with a rollback waiting.
Should you enable WordPress auto-updates?
Split the decision by update type instead of flipping one switch. Core minor releases (6.8.1 to 6.8.2) are security and bug fixes with a strong backward compatibility record, and they have shipped automatically since WordPress 3.7. Plugin, theme, and major core updates are where risk lives, and those deserve a staging pass before production.
The question owners type into Google is binary because the WordPress dashboard presents it that way: a toggle per plugin, a toggle for core. Real sites do not work like that. A WooCommerce store with Elementor, ACF Pro, a payment gateway add-on, and 400 lines of custom functionality in a child theme has a different risk profile from a five-page brochure site running a default theme.
Most agencies land on this split after they get burned once.
| Update type | Auto-update? | Why |
|---|---|---|
| Core minor and security releases | Yes | Narrow changes, heavily tested, patch active exploits |
| Core major releases (7.0, 7.1) | No, stage first | Editor and API changes break page builders and custom blocks |
| Security patches for a plugin under active attack | Yes, immediately | Exploit window beats the layout risk |
| Page builders, ACF, WooCommerce, gateways | No, stage first | Highest breakage rate, highest revenue exposure |
| Small utility plugins (SMTP, redirects) | Yes | Low surface area, low blast radius |
| Themes with child-theme overrides | No, stage first | Parent theme changes orphan your overrides without warning |
What breaks when WordPress auto-updates run
Four patterns account for most of the damage we see in support tickets. None of them are exotic. They are the same conflicts repeating across thousands of sites because the same five or six plugin families sit on top of nearly every build.
- Page builders and ACF lose their editing interface. When WordPress 7.1 shipped, ACF blocks lost their edit pencil and clients could no longer edit their own content, which we wrote up in detail in ACF Blocks Lost Their Edit Pencil in WordPress 7.1. The front end looked fine. The admin was unusable, and nobody noticed for three days.
- WooCommerce checkout throws a fatal. A gateway add-on updates, the main WooCommerce version does not, and the two disagree about a hook signature. Products browse fine, cart works, and the order fails at payment. This is the expensive one because uptime monitors report the site as up.
- PHP incompatibility turns into a white screen. A plugin drops support for PHP 7.4, your host is still on 7.4, and the update lands anyway. See our best PHP version for WordPress breakdown for which versions are still receiving security support.
- Custom code calls a function that got deprecated. The child theme or a snippet plugin references something core removed. The error only fires on one template, usually a product archive or a form confirmation page.
The pattern underneath all four is that breakage almost never lands on the homepage. It lands on the page that makes money, or the screen the client uses, which is why "I checked the site and it looked fine" is not a test. We covered the detection gap in what uptime monitors miss on a WordPress site.
What a bad update costs a real business
Price out one broken checkout on a Friday evening and the decision stops being philosophical. A store doing $60,000 a month averages roughly $2,000 a day in revenue. An update that kills checkout at 6pm and gets noticed at 9am the next morning sits across about 15 hours of traffic.
| Line item | Typical cost |
|---|---|
| Lost orders, 15 hours at $83/hr average revenue | $1,245 |
| Emergency developer, 3 hours at $150/hr | $450 |
| Refunds and goodwill on failed orders | $200-$400 |
| Ad spend that landed on a broken checkout | $150-$600 |
| Staff time reconciling and re-contacting buyers | $200 |
That is roughly $2,200-$2,900 for one bad Tuesday, and it does not count the customer who bought from a competitor instead. Our breakdown of what website downtime costs a business puts the range at $137 to $427 per minute for mid-size operations, which makes the overnight scenario look conservative.
Compare that to the cost of running the update properly: 10-15 minutes of staging time per site, per update cycle. If a developer bills $150/hour, that is about $35 in labor. Across 12 monthly cycles, $420 a year to avoid a single incident that costs five times that much.
Why turning auto-updates off is the worse bet
Disabling updates converts a visible, fixable risk into one that compounds out of sight. Unpatched plugins are the single largest entry point into WordPress sites, and the exploit window after a public disclosure is now measured in hours rather than weeks.
According to Patchstack's State of WordPress Security report, 7,966 new vulnerabilities were added to its database in 2024, with plugins accounting for roughly 96% of them (2025). Sucuri's hacked website report found that about 39% of infected sites were running out-of-date core software at the point of infection (2023). The attack side is faster than ever: when WP2Shell hit sites through CVE-2026-63030, mass scanning started within a day of disclosure.
A hacked site costs more than a broken layout by an order of magnitude. Cleanup, blacklist removal, SEO spam recovery, and the customer trust hit stack up fast, which we priced out in what a WordPress security breach actually costs. The $2,900 bad-update Tuesday above is a rounding error next to a site that spent six weeks serving pharma redirects to Google.
So the owner who disables everything after one Elementor conflict has not reduced risk. They have moved it somewhere they cannot see it, and they have removed the only safety net that was still working automatically.
How managed hosting runs updates without the babysitting
The workflow that removes the tradeoff is boring and mechanical: clone to staging, update, run checks, promote, keep a restore point. It is not complicated, just tedious enough that almost nobody does it manually for 20 client sites every week.
A managed workflow looks like this:
- A staging clone is created from the live site before anything is touched. If you run your own, our guide to WordPress staging environments covers the setup.
- Updates are applied on staging in a known order: core, then plugins, then theme.
- Automated checks hit the pages that matter. Homepage, a product page, add-to-cart, checkout, the login screen, one admin edit screen, and any custom post type archive. Visual diffs flag layout shifts.
- If the checks pass, the update is promoted to production during a low-traffic window.
- If anything fails, the update is rolled back to the pre-update restore point and a human looks at it. No client phone call at 9pm.
Step 5 is the part owners underrate. Automatic rollback only works if restore points are taken immediately before the update, stored offsite, and tested. A backup you have never restored is a hypothesis, which is why a backup strategy has to cover RTO, RPO, and restore testing, not just a nightly cron job.
Security patches get handled differently. When a plugin under active attack ships a fix, waiting 24 hours for the next staging cycle is the wrong call. Network-level rules buy the time instead. We explained how that layer works in how managed hosts handle WordPress zero-days, and TopSyde Sentinel watches for the file changes that follow a successful exploit while the patch is being staged.
Auto-updates on, off, or managed
| Everything auto, unattended | Everything off | Staged with rollback | |
|---|---|---|---|
| Security patch lag | Hours | Weeks to never | Hours for critical, days for routine |
| Breakage reaches customers | Often | Rarely from updates | Rarely |
| Who notices a broken checkout | A customer | A customer | Automated checks, before promotion |
| Your time per site, per month | 0 minutes until it breaks | 45-90 minutes if done properly | 0 minutes |
| Cost of a bad month | $2,000+ incident | $5,000+ cleanup | Included in hosting |
| Works at 20 client sites | No | No | Yes |
The middle column is where most freelancers and small agencies sit, and it is the worst of the three. They disabled auto-updates after one bad experience, promised themselves they would do manual updates monthly, and are now 14 months behind on a client site they inherited in 2024.
For agencies specifically, the economics change again. Forty client sites at 60 minutes of manual update work per month is 40 hours, or a full week of someone's time that bills at nothing. That math is the whole argument behind white-label WordPress hosting for agencies, and we broke the numbers down in what DIY WordPress hosting costs an agency every month.
What to do this week
Start with the inventory, not the toggle. Log into each site and write down two things: the WordPress core version and the number of pending plugin updates. Anything more than 10 versions behind on core, or carrying a plugin that has not been updated by its developer in two years, needs a plan before it needs a button pressed.
Then turn on auto-updates for core minor releases everywhere. That one change closes the most common infection path and almost never breaks anything. Leave page builders, ACF, WooCommerce, and payment gateways on manual until you have a staging process that catches failures before customers do. Our plugin update testing workflow for agencies walks through what to check on each pass.
If that list reads like three hours of work you will not get to, that is the case for handing it off. TopSyde runs the staging-and-rollback cycle on every site we host, starting at $89/mo per site, with support answering in under 2 hours during business hours and a 30-day money-back guarantee. See what the plan includes or read the infrastructure spec sheet if you want the technical detail before you move anything. Migrations are handled by our team, and what to expect when you migrate from GoDaddy covers the process end to end.
Frequently Asked Questions
Should I enable auto-updates for WordPress plugins?
Only for low-risk utility plugins like SMTP, redirect managers, and simple form handlers. Keep page builders, ACF, WooCommerce, and payment gateways on manual until you have a staging environment with rollback, because those are the plugins that break revenue pages when a version mismatch lands.
Will enabling auto-updates break my site?
Core minor releases rarely cause problems and have been shipping automatically since WordPress 3.7. Plugin and theme auto-updates carry real risk, most often showing up as a broken editing interface, a checkout fatal error, or a PHP incompatibility on an older server. The front end usually looks fine, which is why these go unnoticed.
How do I know if an auto-update broke something?
Uptime monitors will not catch it, because the site still returns a 200 response. You need checks that exercise the functional paths: add to cart, complete checkout with a test card, submit a contact form, and open an admin edit screen. Run those after every update cycle, or use a host that runs them for you.
Is it safe to leave WordPress updates turned off?
No. Patchstack recorded 7,966 new vulnerabilities in the WordPress ecosystem in 2024, with roughly 96% coming from plugins, and public disclosures are being mass-scanned within hours. An unpatched site is a cleanup bill waiting to happen, and cleanup costs far more than a layout bug you can roll back in two minutes.
DevOps & Security Lead
12+ years DevOps, Linux & cloud infrastructure certified
Marcus leads infrastructure and security at TopSyde, managing the server fleet and AI monitoring systems that keep client sites fast and protected. Former sysadmin turned WordPress hosting specialist.
