Category: Hosting

WordPress added automatic plugin updates in version 5.5, and the feature has quietly become one of the most misunderstood levers in the admin dashboard. Enable it everywhere and you risk pushing a breaking change to production at 3 a.m. Disable it completely and you’re one unpatched vulnerability away from a compromised site.

The decision isn’t binary. Most operators treat auto-updates as an all-or-nothing switch, but the smarter play is selective: some plugins earn the privilege, others don’t.

What actually happens when you enable auto-updates

When you toggle auto-updates for a plugin, WordPress adds it to a background job that runs twice daily. If a new version is available and passes a few basic checks—compatible WordPress version, no obvious conflicts—the update executes without asking.

The update happens during a cron event, not in real time. If your site has low traffic or your server’s cron is misconfigured, the update may delay by hours. That’s not a bug; it’s how WordPress schedules background tasks.

WordPress sends an email after each auto-update. If you’re not seeing those, check your transactional email setup—most hosts route wp_mail() through unreliable SMTP by default. If you’re using Postmark or another dedicated transactional service, the notifications land reliably.

One detail most guides skip: auto-updates do not create database backups before running. If a plugin update breaks your schema or corrupts data, you’re restoring from your last manual or scheduled backup. That’s why staging environments matter.

Which plugins to trust with auto-updates

Not all plugins carry the same risk profile. Small, single-purpose utilities—contact forms, social share buttons, analytics connectors—rarely introduce breaking changes. They touch a narrow slice of your site and update infrequently.

Security-focused plugins are the best candidates: Wordfence, Sucuri, iThemes Security. These update often, and delaying a security patch is riskier than the update itself. The vendors test obsessively because their reputation depends on it.

Plugins maintained by large platforms—Jetpack, WooCommerce, Yoast SEO—also qualify. They have QA teams, beta cycles, and rollback mechanisms. Auto-updating these is less risky than manually updating at random intervals.

Avoid auto-updates for plugins that:

• Modify your database schema (membership plugins, custom post-type builders)
• Interact with payment processors (WooCommerce extensions, Easy Digital Downloads add-ons)
• Control caching or performance (WP Rocket, LiteSpeed Cache—these can break rendering)
• Hook deeply into your theme (page builders, custom fields)

For these, the cost of an unexpected break in production outweighs the convenience of hands-off updates.

How to test updates before enabling auto-update

If you’re running a staging environment, clone production, enable auto-updates there first, and wait two weeks. If nothing breaks, enable it on the live site. Staging environments catch 80% of update conflicts before they hit real traffic.

If you don’t have staging, manual-update high-risk plugins during low-traffic windows. Check your analytics for the quietest two-hour block each week—usually early morning in your primary timezone—and batch updates then. Keep your browser open for ten minutes after updating and test key workflows: checkout, form submissions, member login.

For plugins that update frequently—weekly or more—auto-updates make sense even if they’re high-risk, because the manual burden becomes unsustainable. You’ll spend more time clicking “Update” than you’ll lose to occasional rollbacks.

The non-obvious tip: monitor update frequency before committing

Before enabling auto-updates, check the plugin’s update history on WordPress.org. Click “Development” in the plugin’s listing and scan the changelog. If the vendor ships five updates a month with vague notes like “bug fixes” or “performance improvements,” that’s a red flag. Frequent, low-detail updates suggest poor testing or reactive development.

Plugins that update every 60–90 days with detailed changelogs are safer bets. The vendor is batching changes, running QA, and treating releases as events rather than continuous patches.

One more filter: check the “Active Installations” count. Plugins with 100,000+ installs get battle-tested by a large user base. If a breaking change ships, it’s caught and patched within hours. Plugins with fewer than 10,000 installs don’t have that safety net.

Auto-updates work best when the plugin vendor has more to lose than you do. High-profile plugins with millions of users can’t afford to break sites at scale. Niche plugins with small audiences can.

Want more deployment and workflow tips? Subscribe to One Two Three Send—every issue covers one specific decision point for operators running content businesses.

You spin up a staging site, clone production, test a plugin update, see it works, push live. Two days later something breaks. The staging test missed it.

Staging environments promise safety. They deliver it only when you know what actually needs testing—and what’s theater.

Most solo operators and small teams treat staging as a checkbox: “I tested it.” But staging sites differ from production in ways that make certain tests useless and certain risks invisible. Here’s what to focus on when you’ve got limited time and a site that can’t afford downtime.

Test Database-Dependent Changes, Skip Static Ones

Plugin updates that touch the database—anything involving custom post types, user roles, or schema changes—need staging. A membership plugin, an SEO tool that rewrites permalinks, a form builder that stores submissions: these can corrupt data or break queries if they fail mid-migration.

Static changes—new CSS, a JavaScript library update, a theme tweak that doesn’t touch PHP logic—can often be tested locally or on a low-traffic page. Staging won’t tell you much more than your browser’s dev tools already do.

The dividing line: if the change writes to wp_options, wp_posts, wp_users, or custom tables, stage it. If it’s front-end only and reversible with FTP, you can skip the full staging ritual.

Replicate Traffic Patterns, Not Just Data

A cloned database and codebase won’t show you how a change performs under load. Staging sites run on lighter server specs, handle zero concurrent users, and skip most caching layers. That makes them poor predictors of performance.

If you’re testing a resource-heavy plugin—an analytics injector, a lazy-load script, a page builder—check server resource usage in staging, then simulate traffic with a tool like Query Monitor or a simple load test script. Watch for memory spikes, slow database queries, and HTTP request waterfalls.

Don’t bother testing page-load speed in isolation. Staging won’t have your CDN, your object cache, or your production traffic patterns. The metric that matters is relative performance: does the change make queries slower or add significant overhead?

Test Integration Points, Not Just Features

The plugin works in staging. But does it work with your email delivery, your payment processor, your analytics, your CDN purge rules?

Most staging environments disable or sandbox third-party API calls. That’s smart for safety, but it means your tests skip the failure modes that break production: a conflict between your caching plugin and your transactional email setup, a payment webhook that doesn’t fire after a checkout-flow redesign, a CDN that stops purging after you change permalink structure.

Before you push live, test one full user flow that touches external services. Sign up, receive an email, complete a purchase, check that analytics fire. Use staging API keys where possible. If your staging site can’t connect to real services, document which integration points weren’t tested—and monitor them closely post-deploy.

When Staging Wastes Time

Staging is overkill for editorial changes, minor copy edits, and media uploads. It’s also overkill for plugin updates from trusted sources that don’t touch your database schema—security patches, minor version bumps with no migration scripts.

If your staging workflow takes more than ten minutes to clone, test, and sync back, you’ll start skipping it. That’s worse than a streamlined process that tests only high-risk changes.

For low-stakes updates, use a checklist instead: back up the database, update, check two representative pages, verify one user flow. If it breaks, restore. If your host offers one-click staging, use it. If you’re manually cloning databases and running search-replace scripts, reserve staging for changes that justify the time cost.

What to Do After You Push

Staging can’t catch everything. Production has real traffic, real user behavior, real edge cases. After you deploy, monitor actively for 24 hours.

Check server error logs, watch for broken form submissions, scan your checkout flow if you touched payments, verify email delivery if you updated SMTP routing. Use a simple uptime monitor—Uptime Robot’s free tier works—and set an alert for HTTP 500 errors.

If something breaks, your staging tests didn’t predict it. Add that failure mode to your next staging checklist. Over time, you’ll build a list of tests that actually matter for your site, not just the generic advice.

What’s your staging workflow? Reply and tell us what you test before you push live—or what broke in production despite passing staging. We read every reply.

If you’re running a content business on WordPress—memberships, course sales, paywalled newsletters—you’ve probably installed WP Mail SMTP, Easy WP SMTP, or Post SMTP to fix the “WordPress emails not sending” problem. These plugins work. But most solo operators configure them once and never check which emails are actually routing through which server.

The result: transactional emails like password resets, purchase confirmations, and login codes get sent through the same SMTP connection as your marketing broadcasts. That’s a deliverability risk, a compliance headache, and in some cases a direct violation of your ESP’s terms of service.

Why WordPress doesn’t care which emails are transactional

WordPress core uses a single function—wp_mail()—to send every outbound email. Plugin update notifications, comment moderation alerts, WooCommerce order confirmations, and member login links all call the same function. There’s no built-in distinction between transactional and promotional.

When you install WP Mail SMTP and point it at your marketing ESP—say, MailerLite or Brevo—you’ve just told WordPress to route everything through that SMTP endpoint. MailerLite’s terms explicitly prohibit sending transactional email through their marketing SMTP relay. Brevo allows it, but only if you’ve configured a dedicated transactional sender and separated your IP reputation.

Most operators skip that step. They plug in their SMTP credentials, see the test email arrive, and move on. Six months later, a member complains they’re not getting password reset emails. You check spam folders, then logs, then realize your marketing ESP flagged the reset email as suspicious because it came from a domain with no SPF record for transactional sending.

What actually breaks

The failure modes vary by ESP and plugin, but the common ones are:

• Rate limits. Marketing ESPs throttle SMTP connections differently than transactional providers. MailerLite’s SMTP relay allows 200 emails per hour on the free tier. If your site sends 50 comment notifications in an hour, you’ve used a quarter of your sending quota before your next broadcast even starts.
• IP reputation bleed. When you send password resets through the same IP pool as your newsletter, a spam complaint on one affects the other. Transactional emails have higher open rates and lower complaint rates—mixing them with promotional content drags both down.
• Logging and compliance gaps. Marketing platforms log email for segmentation and engagement tracking. Transactional platforms log for delivery confirmation and audit trails. Sending a purchase receipt through a marketing ESP means that email gets added to a subscriber’s engagement history, skewing your open-rate metrics and potentially violating GDPR’s purpose-limitation principle.

Postmark, which specializes in transactional email, charges $10 per 10,000 emails with no monthly fee. Their SMTP relay is configured specifically for password resets, receipts, and system notifications—high deliverability, minimal tracking, and logs built for compliance. If you’re sending fewer than 10,000 transactional emails a month, the cost is a rounding error compared to the risk of your members not receiving login codes.

How to split your sending in WP Mail SMTP

WP Mail SMTP Pro (the paid tier, starts at $49/year) includes a feature called “Email Log” and “Email Controls” that let you route specific email types through different SMTP configurations. The free version doesn’t support multiple SMTP accounts, so you’ll need either the Pro version or a separate plugin like Post SMTP (free, supports multiple mailers).

Here’s the setup for Post SMTP:

• Install Post SMTP from the WordPress plugin repository.
• Add your transactional SMTP credentials first—Postmark, Amazon SES, or Brevo’s transactional API. Set this as the default mailer.
• Under “Message” settings, enable “Additional SMTP Settings” and add your marketing SMTP credentials as a secondary mailer.
• In the “Email Log” settings, create a rule: if the email subject contains “password” or “reset” or “order,” route through the transactional mailer. Everything else goes through marketing.

Post SMTP’s rules engine uses regex, so you can get granular. If you’re running WooCommerce, you can route all emails where the sender address matches [email protected] through transactional, and leave everything from [email protected] on the marketing relay.

One overlooked detail: SPF and DKIM per sender

Even if you route emails correctly, your DNS records need to authorize both SMTP servers. If your transactional emails come from [email protected] and your newsletters come from [email protected], both domains need SPF records that include both Postmark’s and MailerLite’s sending IPs.

Most operators add one SPF record and assume it covers everything. It doesn’t. Each sending domain needs its own record, and if you’re using subdomains (mail.yourdomain.com vs. yourdomain.com), each subdomain needs separate DNS entries. Postmark’s onboarding checklist walks you through this. MailerLite’s does not—you have to dig into their documentation.

The fastest way to verify: send a test email from each SMTP connection, then check the raw email headers. Look for spf=pass and dkim=pass in the Authentication-Results field. If either shows softfail or none, your DNS isn’t configured correctly.

Want more tooling breakdowns like this? Subscribe to One Two Three Send—one article every morning, no fluff, no affiliate pressure.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

Installing a WordPress performance plugin feels like the responsible thing to do. Your PageSpeed score is stuck in the 60s, your hosting dashboard shows CPU spikes, and every SEO guide tells you to optimize. So you install WP Rocket, W3 Total Cache, or Autoptimize, flip a few switches, and assume the problem is solved.

Then your server load doubles.

This isn’t a edge case. Performance plugins introduce their own overhead—database writes for cache keys, background processes to minify assets, recurring tasks to preload pages—and many operators never realize the plugin meant to speed things up is now the bottleneck.

What performance plugins actually do

Most WordPress performance plugins tackle three jobs: page caching, asset minification, and delivery optimization (lazy loading, CDN integration, font preloading). Each of these requires the plugin to intercept requests, rewrite HTML on the fly, or generate new files.

Page caching works by saving a static HTML version of each page to disk or object cache, then serving that cached copy instead of rebuilding the page from the database every time. Asset minification combines and compresses CSS and JavaScript files. Delivery optimization defers or delays non-critical resources.

The problem: all of these tasks add new processes. A caching plugin has to check whether a cached version exists, determine if it’s stale, regenerate it if needed, and manage cache invalidation when you publish new content. Minification plugins parse your CSS and JS on every change, write new files to disk, and track dependencies. Lazy-loading scripts inject JavaScript that monitors scroll position and loads images dynamically.

If your site was already near its resource limit, these new tasks push you over. You’re now running two systems: WordPress and the performance layer, each competing for CPU and memory.

Where the overhead hides

The most common culprit is automatic cache preloading. Many caching plugins offer a “preload” option that crawls your entire site in the background, generating cached versions of every page. Sounds efficient—until you realize it’s firing dozens or hundreds of requests against your own server, often during peak traffic hours.

On a site with 200 pages, preloading can mean 200 simultaneous PHP processes trying to render pages. If your host limits you to 20 concurrent PHP workers, you’ve just locked out real visitors while the plugin talks to itself.

Database writes are another hidden cost. Some caching plugins write cache metadata to the WordPress database: expiration timestamps, cache keys, file paths. If you’re generating thousands of cached variations (different pages, mobile vs. desktop, logged-in vs. logged-out), you’re writing thousands of database rows. Those writes slow down every other query on your site.

Asset minification can backfire if it runs on every page load instead of only when files change. Plugins that regenerate minified CSS and JS on the fly—rather than saving the output and reusing it—burn CPU on repetitive work. If your theme or page builder outputs inline styles, the plugin may re-minify the same code hundreds of times per day.

How to audit the damage

Start with your hosting dashboard. Most managed WordPress hosts (BigScoots, Kinsta, WP Engine) show CPU and memory graphs. Look for spikes that align with plugin activation or cache preload schedules.

Next, check database query counts. Install the Query Monitor plugin, load a few pages, and compare query volume before and after activating your performance plugin. If queries increase by 20 or more, the plugin is reading or writing cache metadata on every request.

Check background processes with a cron monitor. WP Crontrol is a free plugin that lists all scheduled tasks. Look for jobs labeled “cache preload,” “minify regenerate,” or “optimize images.” If they run every hour and your site has 500+ pages, you’re hammering your server for minimal gain.

Finally, test actual page speed with and without the plugin. Use WebPageTest or GTmetrix to measure Time to First Byte (TTFB) and Largest Contentful Paint (LCP) with the plugin active, then deactivate it and test again. If TTFB increases with the plugin enabled, it’s doing more harm than good.

What to do instead

Start by offloading work your server shouldn’t be doing. Use a CDN (Cloudflare, BunnyCDN) to serve static assets—images, CSS, JS—without touching your origin server. Enable Cloudflare’s automatic minification and Brotli compression so you’re not running those tasks in PHP.

If you need page caching, choose a plugin that writes to disk (not the database) and doesn’t preload unless you explicitly trigger it. WP Super Cache and Cache Enabler both write flat HTML files and stay out of the database. Disable mobile-specific caching unless you’re serving completely different markup to mobile users—responsive design means one cached version works for everyone.

Skip asset minification unless you’re loading 15+ CSS or JS files per page. Modern HTTP/2 hosting handles multiple small files efficiently, and the CPU cost of minification often outweighs the bandwidth savings. If you do minify, use a build tool (Webpack, Vite) during development so the minified files are static—never generated at runtime.

For image optimization, use a service like ShortPixel or Imagify that processes images once and stores the result, rather than a plugin that optimizes on every request. Set it to manual mode and run it after uploading new images, not automatically.

Most importantly: only add a performance plugin if you’ve measured the problem first. If your TTFB is already under 600ms and LCP is under 2 seconds, you don’t need caching. If your total page weight is under 1MB, you don’t need aggressive minification. Add complexity only when the data proves you need it.

Reply with the hosting setup or performance plugin you’re running—I’ll feature operator setups and server configs in a future issue.

Object caching is one of those WordPress optimizations everyone talks about but few operators actually understand. The idea is simple: instead of hitting the database every time someone loads a page, WordPress stores frequently accessed data—posts, user info, theme settings—in memory. When the same data is requested again, it’s served from RAM instead of MySQL.

That sounds like a win. And for many sites, it is. But object caching introduces moving parts—another service to monitor, another thing that can fail—and if your traffic or query load doesn’t justify it, you’re adding complexity for marginal gain.

What object caching actually does

Out of the box, WordPress uses a non-persistent object cache. That means data is stored in PHP memory for the duration of a single page load, then discarded. If the next visitor requests the same page, WordPress queries the database all over again.

A persistent object cache—typically Redis or Memcached—stores that data in memory across page loads. When WordPress asks for a post’s metadata or a list of recent comments, the cache serves it instantly. No database round trip.

This makes the biggest difference on sites with:

• High concurrent traffic (50+ visitors at once)
• Complex database queries (custom post types, meta fields, WooCommerce)
• Plugins that query the database on every page load (membership tools, dynamic content widgets)

If your site doesn’t fit those profiles, object caching won’t do much. A static homepage with 20 posts and light traffic won’t see a speed boost—you’re already fast enough.

When to skip it

Object caching adds a dependency. If Redis goes down, your site slows to a crawl—or breaks entirely, depending on how your host configured the fallback. Managed WordPress hosts like BigScoots typically handle this gracefully, but if you’re self-managing a VPS, you need monitoring in place.

You also need to flush the cache deliberately when you update content. Most caching plugins handle this automatically, but edge cases exist: custom fields updated via WP-CLI, direct database edits, or theme changes can leave stale data in Redis for hours.

Skip object caching if:

• Your traffic is under 10,000 page views per month
• Your average page load is already under 1 second (check your server response time in Google Search Console or Pingdom)
• You’re running a static site generator or headless setup (the database isn’t the bottleneck)

In those scenarios, you’ll get more value from a CDN, image optimization, or trimming down plugins. Object caching is overkill.

How to set it up (if you need it)

Most managed WordPress hosts offer Redis or Memcached as a one-click add-on. If you’re on a VPS, you’ll need to install Redis via SSH, then add a PHP extension and a WordPress plugin to connect the two.

The most common plugin is Redis Object Cache by Till Krüss. It’s free, actively maintained, and shows you cache hits versus misses in the WordPress admin. If your hit rate is below 80%, something’s misconfigured—either the cache isn’t being populated correctly, or your queries aren’t cacheable.

After enabling object caching, test these scenarios:

• Load your homepage twice in quick succession. The second load should be faster.
• Publish a new post and confirm it appears immediately (not after a manual cache flush).
• Check your server’s memory usage. Redis should sit around 50–100 MB for a typical site. If it’s ballooning past 500 MB, your cache isn’t expiring old data.

One non-obvious tip

Not all database queries should be cached. User-specific data—cart contents, login states, personalized recommendations—needs to stay dynamic. If you cache those, you’ll serve the wrong content to the wrong people.

Most caching plugins exclude these by default, but custom plugins don’t always play nice. If you’re seeing logged-in users get logged-out views, or vice versa, check your cache exclusions. You may need to add specific query keys or user roles to a denylist.

The other gotcha: WordPress transients. These are temporary database entries that plugins use to store short-lived data—API responses, rate-limit counters, import progress. If your object cache is working, transients get stored in Redis instead of MySQL. That’s faster, but it also means transients disappear when you flush the cache. If a plugin relies on a transient sticking around, flushing can break it mid-operation.

Check your transient usage with a plugin like Transients Manager. If you see hundreds of expired transients piling up, something’s writing to the cache inefficiently.

Want more infrastructure breakdowns like this? Reply and tell us what hosting or performance topic to tackle next—or subscribe to catch every Tuesday tutorial.