What I Include in My WordPress Maintenance Retainers (and What I Charge)

When someone asks me what I charge for WordPress maintenance, my honest answer is: it depends. Not because I am being evasive, but because the real answer requires a conversation about their server, their plugin stack, their traffic patterns, and how often their site actually breaks. Two sites can look identical on the surface and require completely different levels of ongoing work.

I have been running WordPress maintenance retainers for years. At some point we had over 30 active clients on monthly maintenance agreements. I have made every mistake possible in this space, underpriced retainers that turned into full-time support jobs, flat-rate agreements that collapsed under the weight of a single WooCommerce plugin update, security incidents that exposed gaps in what I thought was a comprehensive maintenance process.

What follows is how I actually think about this now, what I include, what I refuse to include, and how I arrive at a number that works for the client and does not destroy my team.

Developer working on a laptop reviewing WordPress maintenance tasks

The Myth of the Standard Maintenance Package

Most agencies sell maintenance in tiers. Basic, Standard, Premium. Each tier has a checklist: updates, backups, uptime monitoring, maybe a support hour or two. It looks clean. It is easy to sell. And it works, until it does not.

The problem is that a maintenance checklist assumes the site behaves predictably. In practice, the work is never the checklist. The work is everything that happens between the checklist items: a plugin update that breaks the checkout flow, a CDN configuration that conflicts with a caching plugin, a shared hosting environment that has PHP version restrictions that make half your intended maintenance tools unusable, a client who installed a form plugin themselves and created a security vulnerability three days after you signed the agreement.

I stopped selling tiered packages a few years ago. I stopped because they created the wrong conversation. The client is buying certainty, a fixed monthly amount for peace of mind. I am selling effort, which is inherently variable. Those two things are in tension from day one.

What I do now is scope each retainer individually based on a site assessment. The price reflects the actual risk profile of that specific site, not a generic tier that might underserve a complex site or overcharge a simple one.

The Three Variables That Actually Determine the Work

Before I quote a retainer, I need to understand three things. Everything else flows from these.

1. The Hosting and Server Environment

This is the variable most agencies ignore when scoping maintenance, and it is the one that matters most. A site on a managed WordPress host like Kinsta or WP Engine behaves fundamentally differently from the same site on a shared cPanel server or a self-managed VPS.

On managed hosts, a lot of what constitutes “maintenance” is handled for you. Server-level caching, PHP version management, automatic core updates, daily backups with point-in-time restore, these are included. You are not maintaining infrastructure, you are maintaining the application layer.

On shared hosting, you are often fighting the environment. PHP versions get stuck. Server-level caching tools are unavailable. Cron jobs do not fire reliably. Memory limits are arbitrary. A plugin that works perfectly on Kinsta will throw 500 errors on a shared host not because the plugin is broken but because the server constraints are incompatible with how that plugin is designed to run.

A self-managed VPS is a different situation again. There is full control, which means full responsibility. Server updates, security patches, nginx or Apache configuration, PHP-FPM settings, database optimization, none of that is handled automatically. If a client is on a self-managed VPS and they want true maintenance coverage, the scope includes server-level work that goes well beyond WordPress.

I price retainers for shared hosting and self-managed VPS clients higher than managed host clients, because the maintenance work is genuinely more complex and more time-consuming. I have been burned enough times by the “it is just a WordPress site” assumption on a shared server to know better.

2. The Plugin Stack

The number of plugins is less important than the relationship between them. A site with 8 well-maintained plugins from reputable developers is far easier to maintain than a site with 25 plugins where several of them have not been updated in 18 months and two of them are known to conflict with each other.

The plugin combinations that create the most maintenance headaches in my experience:

Page builders (Elementor, Divi, Beaver Builder) combined with aggressive caching plugins, cache invalidation issues, broken dynamic content, CSS conflicts after updates
WooCommerce plus multiple payment gateway plugins plus a custom checkout plugin, any one of these updating can break the checkout flow, and the fault attribution is a nightmare
Membership plugins combined with LMS plugins, these almost always have overlapping functionality that creates double-handling, data conflicts, and update incompatibilities
Multiple SEO plugins (yes, clients install two), the meta output conflicts are subtle and damage rankings before anyone notices
Security plugins with firewall rules that block legitimate WP-Cron requests, breaking scheduled tasks including backup jobs

When I assess a site for a retainer, I spend time understanding these relationships, not just listing what is installed. A plugin audit before signing the agreement has saved me from several retainer disasters.

3. Client Behavior

This one is uncomfortable to talk about because it sounds like blaming clients. It is not. It is risk assessment.

Some clients log into WordPress daily. They install plugins, try new themes, change settings without telling me, and then report a broken site as a maintenance failure. Others never log in and the site runs exactly as configured indefinitely.

I ask clients directly: how often do you log into the WordPress admin? Do you have other people with admin access? Have you installed or removed any plugins in the past six months without telling your developer? The answers tell me everything about the ongoing risk profile.

A high-touch client who actively manages their own WordPress installation requires a retainer that includes a clearly defined change management process, anything they want to install or change gets routed through me first. Without that process in place, I am maintaining a site that is simultaneously being modified by someone else, and the maintenance retainer becomes an endless support contract. This is one of the harder management challenges in running a WordPress agency, establishing ownership and process clarity before the agreement starts.

What I Actually Include

With those three variables understood, here is what goes into a standard retainer for me. This is not a tier, it is a baseline that gets adjusted up or down based on the assessment.

Core Updates, With Staging

WordPress core updates go to staging first. Always. Even minor versions. I have seen a .0.1 patch break a custom plugin that used a deprecated function that was finally removed. It is rare but it happens, and a client whose site is down because of an update I pushed is not a client who trusts the maintenance process.

If the client does not have a staging environment, I set one up. That is not optional. I will not push core or plugin updates directly to production on a site that does not have a tested rollback path.

Plugin Updates, Grouped and Tested

I do not update plugins individually as they release. I batch updates, test on staging, and push as a group once per month for most sites (weekly for WooCommerce stores where revenue impact of a broken site is immediate). This approach catches cross-plugin conflicts before they hit production and reduces the number of individual deployments.

For critical plugins, WooCommerce, payment gateways, membership plugins, anything directly in the purchase or authentication flow, I read the changelog before updating. Major version bumps get individual testing with checkout flow verification, not just a visual check.

Security Monitoring, Not Just a Plugin

Installing Wordfence or Solid Security does not constitute a security maintenance process. It is a starting point. I have written before about how enforcing consistent coding standards prevents security vulnerabilities at the code level, the same principle applies here: you need a systematic process, not just a tool. What I include in security maintenance:

Weekly review of security plugin alerts and firewall logs, not just the email notifications, which are often noisy and miss context
Monthly file integrity check against a known clean state
User account audit every 90 days, old admin accounts from previous developers or employees are one of the most common attack vectors
Monitoring for the Wordfence vulnerability disclosures relevant to installed plugins, when a CVE drops for a plugin the client is running, that update goes out the same day, not on the monthly schedule
SSL certificate expiry monitoring, sounds basic, but expired SSL certificates cause immediate revenue loss for commerce sites and I have seen it happen to sites where someone assumed auto-renewal was working

What I do not include under security: incident response and cleanup if a site gets compromised. That is a separate engagement. The retainer covers prevention and monitoring. Active malware cleanup requires a forensic process that is scoped separately. Clients need to understand this distinction before they sign, the retainer reduces risk, it does not guarantee zero incidents.

Performance Monitoring, Baseline and Drift

I run a Lighthouse and Core Web Vitals baseline when a retainer starts. Every month I run it again. The value is not the absolute score, it is the delta. A 20-point drop in LCP between months tells me something changed: a plugin added an unoptimized image, a new font was loaded, a third-party script was added without performance consideration.

Speed optimization is a different engagement from performance monitoring. I am not undertaking a full performance audit every month, I am watching for significant regressions and flagging them. If a client’s site consistently performs well, there is nothing to do that month. If something changed, I investigate and fix it.

One thing I have learned the hard way: you cannot apply the same performance rules to every server. WP Rocket with full page caching works perfectly on managed hosting. On shared hosting with aggressive server-side caching already enabled, enabling WP Rocket page caching creates double-caching that serves stale content for days and breaks AJAX-dependent features. Caching configuration is always server-specific.

Backups, Verified, Not Just Scheduled

A backup that has never been tested is not a backup, it is a file that might be a backup. Monthly I do a spot restore of the previous backup to a staging environment to verify it is complete and restorable. This takes 20 minutes and has caught corrupted backup files twice in the past two years.

Backup frequency depends on site activity. A brochure site that changes once a quarter: weekly backups are fine. A WooCommerce store processing daily orders: daily backups minimum, with transaction-level backup of the orders database.

Third-Party Conflicts: The Invisible Time Sink

The work that is hardest to price into a retainer is third-party conflict resolution. This is also the work that most commonly blows up a retainer that seemed straightforward.

Here is a real example. A client’s WooCommerce checkout started throwing a JavaScript error after a routine plugin update. The error was in the payment gateway’s JS file. But the payment gateway had not been updated. The culprit was a caching plugin that had cached a minified version of a script from a third plugin, and when that third plugin updated its script, the cached version no longer matched the expected function signatures. Nobody owned this bug. The payment gateway developer was not going to fix a caching conflict. The caching plugin developer was not going to fix a checkout conflict. The third plugin developer had no idea their update had cascading effects downstream.

This is the reality of complex WordPress maintenance. Bugs that live in the space between plugins, between plugins and server configurations, between plugins and CDN rules. Diagnosing them requires understanding all the layers simultaneously.

I handle this in retainers in one of two ways depending on the client. High-complexity sites get a monthly hours allocation specifically for conflict resolution, typically 2 to 4 hours that rolls over if unused but caps at 8 hours banked. Lower-complexity sites get a defined response time and a separate billing rate if a conflict investigation exceeds 1 hour in a given month.

What I will not do is offer unlimited conflict resolution in a flat retainer. That is a path to an unprofitable engagement. The retainer covers maintenance. Conflict investigation is labor that has to be compensated.

How I Price It

After the site assessment, I arrive at a monthly number using a simple mental model: what is the expected monthly effort, and what is the risk premium for this particular site?

Factor	Price Impact
Managed hosting (Kinsta, WP Engine, Cloudways)	Lower, infrastructure is handled
Shared hosting or self-managed VPS	Higher, server-level work included
WooCommerce with active transactions	Higher, revenue impact of downtime, more frequent update cycles
Membership or LMS with paying subscribers	Higher, access control failures have direct churn impact
High plugin count (20+) or complex plugin relationships	Higher, conflict surface area increases non-linearly
Client with admin access and history of self-modifications	Higher, change management overhead, incident likelihood
Static brochure site, low plugin count, managed hosting	Lower, minimal ongoing complexity
No staging environment	Higher, setup and ongoing maintenance included

In real numbers: a simple brochure site on managed hosting where the client never logs in might be $150 to $200 per month. A WooCommerce store on shared hosting with 30 plugins, an active client who manages their own content, and no existing staging environment might be $600 to $800 per month. The difference is not arbitrary, it reflects the actual difference in expected monthly effort.

I also have a minimum retainer threshold. Below a certain monthly amount, the administrative overhead of managing the client relationship eats the margin. My current minimum is $150/month. Anything below that is not worth the account management overhead for either party.

What I Refuse to Include

Being explicit about exclusions in the retainer agreement is as important as defining inclusions. The clients who become problems are almost always the clients where the scope was ambiguous.

Things I explicitly exclude from every retainer:

New feature development. Adding a contact form, creating a new page template, integrating a new third-party service, these are development projects, not maintenance. Retainer clients sometimes assume unlimited small development requests are covered. They are not.
Malware cleanup and incident response. Prevention is in scope. Active remediation of a compromised site is a separate engagement with a different billing structure.
Content updates. Unless specifically included and priced in, changing text, swapping images, updating product prices, this is content management, not maintenance.
Custom development debugging. If the site has custom code that breaks, that is a development issue, not a maintenance issue. Maintaining custom code requires access to the original developer’s context and is a different kind of engagement.
Hosting migration. Moving the site to a different server is a project. It is not part of maintaining it where it lives.

Every one of these exclusions has been tested in a real client conversation. At some point a client has assumed that each of these things was included in “WordPress maintenance.” Having them explicitly excluded in writing means those conversations are short and clear rather than long and contentious.

The Conversation That Saves the Retainer

There is one conversation I have with every prospective maintenance client before signing anything, and it has prevented more retainer disasters than any contract clause.

I ask: what does a bad month look like for this site? What is the worst-case scenario you are trying to prevent?

The answers reveal what the client actually values. A WooCommerce store owner might say: the site going down during a promotion. A membership site owner might say: members being locked out of content they paid for. A brochure site owner might say: honestly, nothing urgent, I just do not want to think about it.

Those are three completely different risk profiles with three completely different maintenance priorities. The WooCommerce owner needs uptime monitoring with immediate alerting and a rapid response SLA. The membership site owner needs authentication and access control tested after every relevant update. The brochure site owner needs a basic monthly maintenance pass and the peace of mind that someone is watching.

If I skip this conversation and offer the same package to all three, I will inevitably either over-deliver for the brochure site (losing margin) or under-deliver for the WooCommerce store (losing the client after the first incident).

The maintenance retainer business only works long-term if the service delivered matches the risk that actually concerns the client. Getting that alignment at the start is the most important part of the process, more important than the contract, more important than the checklist, more important than the tools you use.

What I Would Tell Someone Starting Their First Retainer

Start with a site assessment, not a pricing page. Build the scope from the assessment, not from a tier list. Price the complexity honestly, underpricing to win the client is a trap that leads to resentment and churn.

Put the exclusions in writing. Not in small print, in plain language that the client reads and confirms before signing.

Have the “what does a bad month look like” conversation. It takes 10 minutes and tells you more about what the retainer needs to cover than any checklist.

And accept that the work is variable. The goal of good maintenance is not to have something to do every month, it is to have nothing to do most months and to be ready when something breaks. Clients who understand that are the clients worth keeping.

WordPress maintenance retainer pricing is not a commodity. You cannot look at what someone else charges and copy it without understanding the risk profile behind their number. What I have shared here is the framework I use, the variables, the inclusions, the exclusions, and the conversation that makes it work. Your retainer prices will reflect your own assessment of the same factors. The framework is the part worth borrowing.