A client came to me last year with a WooCommerce store that had been quietly serving malware for three weeks. Their hosting company had flagged it; Google had already blacklisted the domain. The site was running WordPress 5.8, WooCommerce 6.1, and a premium theme that hadn’t been updated in 14 months. They were paying $39/month to a maintenance service the whole time. When they reached out to that service, the response was: “We apply updates every Monday. Your next update window is in 5 days.”
That’s the maintenance industry in a sentence. A lot of services out there have automated update scripts, a dashboard that shows green checkmarks, and almost no human judgment involved. This post is about what maintenance actually requires — the technical work, the frequency, the things that can’t be automated away — and what questions to ask before you pay anyone to “maintain” your site.
What WordPress Maintenance Actually Involves
Updates are maybe 20% of the job. Here’s the rest.
Core, Plugin, and Theme Updates — Done Carefully
Running updates sounds simple. Click update, done. But anyone who has done this on a production site with real traffic knows it’s not that clean. Plugin conflicts are common. A WooCommerce major version bump can break checkout. A page builder update can corrupt saved layouts. An SEO plugin update can change how structured data is output.
The correct workflow isn’t “click update on production.” It’s:
- Pull a fresh copy of the live site to a staging environment
- Apply updates on staging
- Run through key site flows manually — homepage, primary conversion path, checkout or contact form, admin login
- Check the browser console for new JS errors
- If clean, deploy to production during a low-traffic window
- Monitor for 24 hours
Using WP-CLI on the server side, a responsible update routine looks something like this:
# Check what needs updating first
wp plugin list --update=available --format=table
# Update one plugin at a time on staging, not all at once
wp plugin update woocommerce
# Verify it's the expected version
wp plugin get woocommerce --field=version
# Check for PHP errors after update
wp --debug plugin update woocommerce 2>&1 | grep -i "fatal|error|warning"
Bulk-updating everything at once with wp plugin update --all on a live site without staging is exactly what the $29/month services are doing. It works until it doesn’t.
Security Monitoring and Hardening
Security on WordPress isn’t a one-time setup. It’s a continuous posture. The threat landscape changes — new vulnerabilities get disclosed in plugins, zero-days surface, brute force patterns shift. A site that was hardened properly 18 months ago may have gaps today.
A real security checklist that should be verified regularly:
- File integrity monitoring — core WordPress files should match known-good checksums.
wp core verify-checksumscatches tampering. - Plugin vulnerability scanning — cross-referencing installed plugin versions against the WPScan vulnerability database. Wordfence does this, but so does a manual check against wpscan.com.
- Login hardening — limiting login attempts, blocking xmlrpc.php if not needed, enforcing strong passwords on all admin accounts, disabling application passwords if unused.
- User audit — ghost admin accounts accumulate over time, especially on sites that have had multiple developers. Every account that shouldn’t exist is a potential attack surface.
- SSL certificate validity and configuration — a lapsed certificate kills trust and SEO simultaneously.
- Database prefix — still worth checking on older installs.
wp_prefix is the default that automated attacks target. - File permissions —
wp-config.phpshould be 400 or 440. The/uploads/directory should not be executable. - Security headers — Content-Security-Policy, X-Frame-Options, X-Content-Type-Options. Most cheap plans never touch these.
When a new critical vulnerability drops — say, a remote code execution flaw in a popular form plugin — the window between disclosure and active exploitation is often under 72 hours. A maintenance service that does weekly updates is not positioned to respond to that.
Backups — and Actually Verifying Them
Every maintenance plan claims to include backups. Very few test them.
A backup that has never been restored is a hypothesis, not a guarantee. Backup files can be corrupt. Database dumps can be incomplete. Some backup plugins exclude the /uploads/ folder by default. Some configurations back up to a location on the same server — which is useless if the server itself is compromised or the host goes down.
What a proper backup setup looks like:
- Daily automated backups of both the database and all files
- Offsite storage — a separate S3 bucket, Google Drive, or Dropbox that the server doesn’t have write-delete access to (so ransomware can’t delete your backups)
- Retention policy — at minimum 30 days of daily backups, with monthly snapshots going back further
- Monthly restore test — actually spin up the backup on a staging environment and verify the site loads correctly
- Pre-update snapshot — a fresh backup taken immediately before any significant update is applied, separate from the regular schedule
The restore test is the step that separates real maintenance from the appearance of maintenance. It takes about 20 minutes and most services skip it entirely.
Performance Monitoring
Performance degrades silently. A plugin gets added, a query gets slower, image uploads don’t go through the optimizer, a third-party script starts loading synchronously. Page load time creeps from 1.8 seconds to 3.4 seconds over six months and no one notices because it happened gradually.
Real performance monitoring means:
- Tracking Core Web Vitals monthly — LCP, CLS, INP — not just running a one-time PageSpeed audit
- Running Query Monitor periodically to catch slow or duplicate database queries that accumulate as the site grows
- Checking the autoloaded options table size — this bloats over time with certain plugins and can noticeably slow
wp_load_alloptions() - Reviewing PHP error logs for warnings that aren’t fatal but indicate something is wrong
- Watching cache hit rates if a caching layer is in place
In Query Monitor, a site with a problem often shows the same query running 40 or 50 times per page load — an N+1 query pattern from a poorly written plugin. That’s not going to show up in an uptime monitor. It shows up as a site that feels slow and has declining conversion rates.
Uptime Monitoring
This one is table stakes and most plans do include it, but there’s a difference between knowing the site is down and having someone who can fix it. A monitoring service pings your site every minute and sends an email when it’s unreachable. That’s useful. But if you’re then emailing a support ticket to your maintenance provider and waiting 4–8 business hours for a response, the monitoring isn’t solving the problem.
Uptime monitoring paired with a developer who can actually diagnose and fix the issue is what matters. Is the site down because of a PHP fatal from a botched update? A server memory limit hit? A DDoS? A corrupt database table? The fix is different in each case, and “we’ll look into it” is not the same as someone who knows what they’re doing getting into the server.
What the Cheap Plans Are Actually Selling You
The $29–$49/month plans that saturate the market are mostly selling peace of mind, not actual security. Here’s what they typically do:
- Run automated plugin and theme updates on a schedule (often weekly, often all at once)
- Run a malware scanner (not the same as active security monitoring)
- Set up a backup plugin and assume it’s working
- Send you a monthly report with green checkmarks
Here’s what they typically don’t do:
- Test updates on staging before touching production
- Respond to security vulnerabilities outside their scheduled update window
- Verify that backups are actually restorable
- Monitor or investigate performance issues
- Audit user accounts, file permissions, or security headers
- Have a developer available who understands your specific site
The business model works because most sites don’t have a crisis in any given month. The service collects fees, runs the automated tasks, and looks fine — right up until something goes wrong. Then the limitations become obvious fast.
I have a specific frustration with how these services market themselves: they use the word “monitoring” for things that are just automated checks. Monitoring implies someone is watching and will act. An automated scanner that runs once a day and emails a PDF report is not monitoring. It’s reporting after the fact.
What a Proper Maintenance Plan Includes
Frequency Breakdown
Daily:
- Uptime checks (automated, every 1–5 minutes)
- Backup execution (automated, offsite)
- Security log review (manual or via monitored alerts)
Weekly:
- Plugin/theme vulnerability check against current database
- PHP error log review
- Minor updates applied via staging workflow
- Spam comment and form submission audit
Monthly:
- Major version updates (WordPress core major releases, WooCommerce major bumps) — these need more testing time
- Core Web Vitals check and comparison against previous month
- Backup restore test
- User account audit
- Database optimization — clean post revisions, transients, orphaned metadata
- Security headers and SSL review
- File integrity check via
wp core verify-checksumsand manual spot-check of core files
Quarterly:
- Full security audit — penetration testing mindset, not just automated scans
- Hosting environment review — PHP version, server software, whether anything needs upgrading at the infrastructure level
- Performance audit using Query Monitor and profiling tools
- Plugin audit — are there plugins that are no longer maintained upstream? Abandoned plugins with known vulnerabilities that just haven’t been disclosed yet?
The Staging Environment Requirement
Any maintenance plan that doesn’t include a staging environment is not a serious plan for a serious site. Period.
A staging environment doesn’t have to be complex. It can be a subdomain on the same host, a Local by Flywheel environment, a WP Engine staging slot, or a separate cheap VPS that gets refreshed from production weekly. The point is that changes get tested somewhere before they go live.
The workflow for anything beyond a minor security patch:
- Sync staging from production (database + files)
- Apply changes on staging
- Test manually — don’t just look at the homepage, walk through the actual user flows that generate revenue
- Check admin functions — can you still create posts, process orders, submit forms?
- Deploy to production
- Verify on production immediately after
This takes longer than clicking “update all.” That’s the point.
When You Need a Developer, Not a Maintenance Service
There’s a real distinction between maintenance — keeping a working site working — and development, which is making changes to the site itself. But in practice, the line blurs constantly.
You need a developer (not just a maintenance plan) when:
- An update breaks something and the fix isn’t reverting — it requires debugging the conflict
- Your site’s performance is degrading and the cause isn’t obvious from surface-level tools
- A security incident has occurred and you need someone to find the vector, clean the infection, and close the hole — not just run a cleanup plugin
- You’re on a PHP version that’s end-of-life and upgrading requires checking plugin and theme compatibility, not just flipping a switch
- Your WooCommerce or custom plugin needs a code change that no off-the-shelf solution covers
- You want to add a feature, integrate a third-party service, or change how something works fundamentally
Maintenance services handle the routine. A developer handles what falls outside the routine — and more things fall outside the routine than most site owners expect.
A developer on retainer is a different model than a maintenance plan. You’re paying for available hours and expertise, not just a list of automated tasks. The value is that when something breaks or needs to change, the person who already knows your site is the one who fixes it.
Pricing Tiers: What You’re Actually Buying
Basic ($29–$79/month)
Automated updates, a backup plugin, an uptime monitor, and a monthly report. Fine for a personal blog or a static brochure site with no transactions, no sensitive user data, and no revenue attached. For anything else, you’re underprotected and you don’t know it yet.
Premium Maintenance ($150–$400/month)
This is where you start getting a human in the loop. Staged updates, security monitoring with actual response, verified backups, performance tracking, and a defined SLA for downtime response. There should be a named person or small team who knows your site. A monthly or quarterly call to discuss what was done and what’s coming.
At this tier, ask specifically: what is the response time if my site goes down at 9pm on a Friday? If the answer is “next business day,” that’s not premium maintenance.
Developer on Retainer ($500–$1500+/month)
Maintenance is included, but you’re also buying development hours. Changes get made, not just maintained. If your business depends on the site — ecommerce, lead generation, membership, SaaS — this is the correct model. You want someone who can fix problems and build improvements without going through a full project scoping process every time.
The math works out: a single incident that a cheap maintenance plan fails to prevent — a blacklisted domain, a data breach, a week of downtime — costs more than years of proper maintenance. The question isn’t whether you can afford real maintenance. It’s whether you can afford the alternative.
What to Ask Before Signing a Maintenance Contract
These questions will tell you quickly what you’re actually buying:
- Do you test updates on a staging environment before applying them to production?
- How do you handle a critical security vulnerability disclosure between your scheduled update windows?
- Where are backups stored? Are they on the same server? Have you restored from a backup in the last 30 days to verify it works?
- What is your response time if my site goes down outside business hours?
- Do you monitor PHP error logs? What happens when you find errors?
- Who specifically will be working on my site — a named person, or whoever is available?
If a service can’t answer these clearly, or if the answers rely heavily on “our system automatically handles that,” you know what you’re dealing with.
Working with Me
I maintain WordPress sites as part of my regular work — not as a side service, but as something I do alongside active development. I’ve worked on sites with over a million active users (SeedProd runs on more than a million WordPress installs), which means I’ve dealt with update complexity, security incidents, performance problems, and plugin conflicts at a scale where mistakes have real consequences.
My maintenance and retainer work is appropriate for business owners who have a site that does something meaningful — generates leads, sells products, runs a membership, supports a service business — and want someone who can both keep it running and improve it over time.
I work remotely with clients globally. If you want to talk about what your current maintenance situation looks like and whether it’s actually sufficient, get in touch. I’ll give you a straight answer about what I’m seeing, not a sales pitch.
