What you are actually paying for when you buy WordPress maintenance

Most WordPress maintenance plans read like the same product. Updates, backups, security, uptime monitoring, a number of support hours. The pricing varies by a factor of ten but the bullet list looks roughly the same. That gap is not random. The cheap end and the senior end are doing genuinely different work, and you only find out which one you bought when something breaks.

I run maintenance for a mix of clients, some directly and some white-label for agencies. What follows is the honest version of what each price tier actually covers, where the corners get cut and what to ask before you sign.

The starter tier

A starter plan is usually a few tens of pounds a month. It is sold to small business owners who want to tick the maintenance box without thinking about it too hard. There is nothing wrong with that as a goal. You just need to know what you are getting.

Monitoring at this tier is a script. An automated tool pings the homepage every few minutes and sends an email if the response code is wrong. If your homepage loads but a key form is broken, or a third of your pages are returning errors, nobody notices until you do. The alerts go to a shared inbox that may or may not be read on a Sunday.

Updates happen on a schedule, often weekly or monthly. WordPress core, plugins and themes get auto-updated by a management dashboard like ManageWP or MainWP. The tool runs the updates, takes a screenshot of the homepage before and after, and reports success or failure. If a plugin update breaks a checkout page two clicks deep, the screenshot does not catch it.

Backups exist, usually nightly, often stored in the same place as the site or on a cheap object storage bucket. Restoration is a button click in theory. In practice, restorations at this tier come with a queue, an email exchange and a few hours of waiting. If the site is down, it stays down while you wait.

Security is signature based. A plugin like Wordfence or Sucuri runs scans and blocks known bad traffic. No human reviews logs unless an incident is loud enough to trip an alert. If a stealthy compromise sits quietly for a few weeks scraping data or seeding spam pages, nobody catches it until search results start complaining.

Strategic input is not part of the deal. You will not get a quarterly call about what your site needs next year. The plan is reactive, and the reaction is mostly automated.

A starter plan is fine for a low-traffic brochure site that does not generate revenue. It is dangerous for anything where a few hours of downtime costs real money.

The mid tier

A mid-tier plan sits in the low hundreds per month. It is sold to businesses that have outgrown the starter bracket and noticed the gaps. The product is different in kind here, not a bigger version of the same thing.

Monitoring includes synthetic checks on the parts of the site that matter. The contact form, the checkout, the booking flow, the login page. A real script runs them every few minutes and alerts a real person when they fail. The alerts go to someone who is on call, not a generic inbox.

Updates still use management tools, but a developer reviews changes before pushing them. Major plugin updates get tested on a staging copy first. Minor updates often go through automatically with a rollback plan if things break. When something does break, a human notices within minutes and fixes it within hours.

Backups are offsite, versioned and tested. Tested means somebody has actually restored a copy to a staging environment in the last quarter to confirm the backup is usable. Untested backups are theoretical backups. A surprising number of starter plans only discover their backups do not restore the day they need them to.

Security extends to file integrity monitoring, login anomaly detection and a reviewed firewall ruleset. There is still no full security operations centre, but there is a person who reads the logs once a week and responds to anything suspicious.

You usually get a small block of included development time each month. Maybe a couple of hours. Enough for small content changes, a new contact form field, a tweak to a template. Anything bigger is quoted on top.

There is a strategic component, but it is light. A short check-in once a quarter to flag the obvious things. A plugin going unmaintained. A PHP version about to drop out of support. A performance regression creeping in.

The senior tier

At the senior end you are paying somewhere in the mid to high hundreds per month, sometimes more. The plan is sold to businesses where the site is a real piece of operational infrastructure, where an outage has a number attached to it.

Monitoring is layered. Synthetic checks, real user monitoring, error tracking, application performance monitoring, log aggregation. Alerts route through an on-call rotation with response SLAs. If the site goes down at 02:00 on a Sunday, a developer is responding within thirty minutes.

Updates run through a real release process. Staging, regression checks, a documented rollback. Major plugin updates and core upgrades are scheduled, reviewed and rehearsed. The developer doing the update has actually used the site. They know that the checkout has a custom shipping module that breaks if WooCommerce core jumps a major version, and they handle it accordingly.

Restoration is measured in minutes, not hours. Hot standby environments, point-in-time database recovery, scripted infrastructure that can be rebuilt on demand. The first time you restore a senior-tier site is usually a fire drill, not a real incident, because somebody scheduled a fire drill.

Security response includes a defined SLA. A critical vulnerability in a plugin you use gets a patch on the same day, often within hours. The team has subscribed to the Wordfence intelligence feed, the WPScan database and any vendor advisories that touch your stack. They know about the issue before it appears in your inbox.

Strategic conversation is built into the price. Quarterly reviews of performance, security posture, technical debt and what should be in the roadmap for the next year. The work plan looks ahead and prevents problems instead of reacting to whatever breaks next.

This is the bracket where you stop thinking about WordPress maintenance as a line item and start treating it as part of how the site runs as a business asset. I cover the principles of locking that down in the WordPress security hardening checklist.

White-label versus direct-to-business

If you bought your website through a design agency, your maintenance is probably white-label. The agency sells you a plan, then pays a developer or a specialist support shop to do the actual work in the background. There is nothing wrong with that model. Plenty of agencies do it well, and the developer behind the scenes is often more experienced than anyone the agency could hire full time.

The catch is that you are one step removed from the person doing the work. Requests go through an account manager. Urgent requests sometimes wait until the agency forwards them. If the agency closes for two weeks at Christmas, your support might too, even though the developer behind the scenes is at their desk.

Direct-to-business arrangements skip the middle layer. You talk to the developer. The response is faster and the cost is often lower for the same actual work. The trade-off is that you do not get the wrapper. No account management, no design capacity sitting alongside the maintenance, no separate person to escalate to if something goes wrong with the developer.

Neither model is right by default. Pick the one that matches how you want to operate.

What to ask before you sign

Ask who actually reads the monitoring alerts. If the answer is "the system sends them", you have a starter plan dressed up. If the answer is a named role with a rota, you are in different territory.

Ask how updates are tested. Listen for staging environments, regression checks and rollback plans. A confident answer mentions the specific kind of breakage that has happened on previous sites and how the team caught it.

Ask when the last full restoration test was. A team that can name a date in the last three months is taking backups seriously. A team that says "we restore when we need to" is hoping.

Ask about response time for a high-severity issue. Not just business hours, but the actual SLA in the contract. If there is no SLA, you are buying a best-efforts arrangement.

Ask what the developer behind the plan would do first if your site was hacked tonight. Specific answers are good. Vague answers about "running scans" are not.

Finally, ask whether the plan is a one-way relationship or a conversation. The plans that actually keep sites healthy include a quarterly call. The plans that do not, do not.

Where to go from here

If your current maintenance plan fits the starter description and your site is doing real work, you are exposed. Move up a bracket, or change provider. If you are not sure what you currently have, ask the questions above and listen for the gaps.

I cover the senior end of this work, both directly and as white-label support for agencies. If that is what you need, see how I structure support and maintenance, or look at the broader WordPress development service if you are weighing up a rebuild alongside the support question.