Category: Hosting

WordPress has offered automatic updates since 2013, but most operators still treat the feature like a binary choice: all on or all off. That’s a mistake. The auto-update system has four distinct layers, and each one carries different risk and reward.

Here’s how to configure them without waking up to a broken site.

Core updates: three tiers, three strategies

WordPress core has three update types, and the defaults are smarter than most people realize.

Minor releases (e.g., 6.4.1 to 6.4.2) auto-update by default. These are security and critical bug fixes. Leave this enabled. The risk of a minor version breaking your site is vanishingly small compared to the risk of running unpatched software. In eight years of managing client sites, I’ve seen exactly one minor update cause a conflict—and it was with a plugin that was already deprecated.

Major releases (e.g., 6.4 to 6.5) are disabled by default, and you should keep them that way unless you’re running a very simple site with minimal plugins. Major versions introduce new features and can break theme or plugin compatibility. Schedule these manually, ideally in a staging environment first.

Development and beta builds are off by default. Never enable these on a production site. They’re for testing only.

You can control core auto-updates in Dashboard → Updates → Advanced Options, or via the WP_AUTO_UPDATE_CORE constant in wp-config.php.

Plugin auto-updates: the risk matrix

Since WordPress 5.5, you can toggle auto-updates per plugin. This is where most operators get it wrong—they either enable everything or nothing.

The correct approach is risk-based. Enable auto-updates for:

• Security plugins (Wordfence, Solid Security, etc.). Delaying a security patch is worse than the small chance of a bad update.
• Actively maintained utilities with narrow scope—contact forms, analytics snippets, small performance helpers. If a plugin does one thing and is updated frequently, auto-update is usually safe.
• Plugins from established vendors with good release practices. WooCommerce, Yoast, Jetpack, and similar have staged rollouts and rarely ship breaking changes in patches.

Disable auto-updates for:

• Page builders and theme frameworks. Elementor, Divi, Advanced Custom Fields, WPBakery—anything that touches your front-end rendering or content structure. Updates here can cascade across hundreds of pages.
• Plugins you’ve customized via hooks or filters. Auto-updates will overwrite nothing, but new versions may deprecate the functions you’re relying on.
• Anything that hasn’t been updated in over a year. If the developer isn’t actively maintaining it, the next update could be panicked, untested, or abandoned entirely.

On a typical content site, I’ll have auto-updates enabled for about 60% of installed plugins. On a membership site with custom checkout flows, closer to 30%.

Theme auto-updates: almost never

Themes control your entire front-end. A bad update can break layouts, remove custom CSS, or interfere with child theme overrides.

Disable auto-updates for your active theme. Period. The only exception: you’re using a bare-bones starter theme (like GeneratePress or Astra) with zero customizations, and all your design work lives in a child theme or site-specific plugin.

You can leave auto-updates enabled for inactive themes if you want to keep them patched for security, but the smarter move is just to delete any theme you’re not using. An inactive theme is still executable code that can be exploited.

Translation auto-updates: safe to enable

Translation files auto-update by default, and there’s no reason to turn this off. They’re low-risk, non-executable, and keeping them current improves localization accuracy. Leave it alone.

What happens when an auto-update fails

WordPress has a rollback mechanism. If a plugin or theme update triggers a fatal error during activation, the system will attempt to restore the previous version and send you an email with the error log.

This works—most of the time. But it’s not a substitute for backups. If you’re enabling auto-updates for anything beyond minor core releases, you need automated daily backups with off-site storage. Most managed WordPress hosts (including BigScoots) include this. If you’re on unmanaged hosting, use UpdraftPlus, BlogVault, or a server-level solution.

The notification problem

Auto-updates are only useful if you know they happened. WordPress sends email notifications for core updates and failed plugin updates, but successful plugin updates are silent by default unless you enable the auto_plugin_update_send_email filter.

Add this to your theme’s functions.php or a site-specific plugin:

add_filter( 'auto_plugin_update_send_email', '__return_true' );

Now you’ll get an email every time a plugin auto-updates. If you’re running multiple sites, route these to a dedicated email address or a Slack channel via Zapier.

One non-obvious tip: staging auto-updates

If you’re using a host with staging environments, configure your staging site to auto-update everything—core, plugins, themes. Then schedule a weekly automated check (via uptime monitor or a simple cron job) to verify the staging site still loads.

If staging breaks, you’ll know before the same update hits production. If it doesn’t, you can manually push the updates live with confidence. This is the closest you’ll get to zero-touch maintenance without the risk.

Got a WordPress setup question we should cover? Reply to this email—we read every one.

Some links in this post are affiliate links — we earn a small commission if you sign up through them, at no cost to you. We only recommend tools we actually use.

Most WordPress sites hit the database dozens of times per page load. Every menu, every widget, every post query — they all fire separate requests. For a low-traffic blog, that’s fine. For a content business serving thousands of readers a day, it becomes a bottleneck.

Object caching stores the results of those database queries in memory so WordPress can reuse them instead of re-running the same query ten times per page. It’s not page caching (which saves entire HTML pages). It’s not browser caching (which stores assets locally). It’s an in-between layer that speeds up the dynamic parts of your site — the bits that change based on who’s logged in, what’s in the cart, or which posts are being displayed.

If you’re running a membership site, a high-traffic blog, or a WooCommerce store, object caching can cut server load by 40–60%. But it adds complexity, and it doesn’t help every site equally.

How object caching works in WordPress

WordPress has a built-in object cache — but by default, it only lasts for a single page load. Every time someone visits a page, the cache resets.

Persistent object caching extends that lifespan. Instead of storing query results in PHP memory (which disappears after each request), it stores them in Redis or Memcached — key-value stores that sit in RAM and persist across requests.

When a query runs, WordPress checks the object cache first. If the result is there, it skips the database entirely. If not, it runs the query, stores the result, and serves it from cache next time.

Common queries that benefit: navigation menus, widget output, post metadata, taxonomy terms, user data, WooCommerce product attributes. Anything that gets called repeatedly and doesn’t change on every page load.

When to turn it on

Not every site needs object caching. A static blog with 500 visitors a month won’t see a meaningful difference. But you’ll notice a real impact if:

• You’re serving more than 10,000 page views per month
• Your site uses complex queries (custom post types, taxonomies, meta queries)
• You’re running WooCommerce, BuddyPress, or another plugin-heavy setup
• Your database queries are taking longer than 50ms (check this in Query Monitor)
• You’re hitting CPU or memory limits during traffic spikes

The easiest way to tell: install Query Monitor, load a few pages, and look at the query count and total query time. If you’re running 100+ queries per page or spending more than 200ms on database calls, object caching will help.

Most managed WordPress hosts (Kinsta, WP Engine, Cloudways) offer Redis as a one-click add-on. If you’re on a VPS with BigScoots or similar, you’ll need to install Redis yourself (or ask support to do it) and add a plugin like Redis Object Cache or Object Cache Pro.

The non-obvious gotcha

Object caching breaks badly written plugins.

If a plugin assumes every query hits the database — or if it doesn’t properly invalidate (clear) cached data when something changes — you’ll see stale content. A post updates, but the old version keeps showing. A product goes out of stock, but the cache still says it’s available.

Good plugins handle this automatically by calling wp_cache_delete() or wp_cache_flush() when data changes. Bad plugins don’t.

Before you enable object caching site-wide, test it on a staging environment. Update a post, change a menu, edit a product. If those changes appear immediately on the front end, you’re fine. If they don’t, you’ve got a plugin conflict.

One more thing: object caching doesn’t replace page caching. It speeds up dynamic queries, but you still want a layer (like WP Rocket, Cloudflare, or your host’s built-in cache) saving full HTML pages for logged-out users. The two work together — page caching handles static content, object caching handles the bits that can’t be fully static.

What to do next

If you’re not sure whether your site needs object caching, start here: install Query Monitor (it’s free), load your most-trafficked pages, and check the database panel. If you’re seeing 80+ queries or 150ms+ query time, object caching will make a measurable difference.

If you’re already on a managed host, check whether Redis is included or available as an add-on. If you’re on a VPS, ask your host whether they support Redis, or spin up a staging site and test it yourself.

And if you do turn it on: keep Query Monitor installed for a week and watch for stale content. Most modern plugins handle caching well, but the ones that don’t will show themselves quickly.

Got a question about WordPress performance, caching, or infrastructure? Hit reply — this is the sort of thing we dig into every week.

Some links in this post are affiliate links — we earn a small commission if you sign up through them, at no cost to you. We only recommend tools we actually use.