A WordPress maintenance plan should include five things at minimum: monitored updates applied on a staging copy, off-site backups that are tested by restoring them, uptime and error monitoring with someone who responds, security hardening with malware scanning, and a monthly performance check with a report you can actually read. Anything that covers less than that is a plugin-updating service, not site care.
Below is the full line-by-line standard, plus the gaps that show up most often in a quote. Use it to compare providers, or to build your own internal routine.
Why the list matters more than the price
Two plans at the same monthly price can differ enormously in what they actually do. One runs updates automatically with no testing and no backup beforehand. The other tests on staging, keeps thirty days of restorable backups, and has a human looking at the monitoring alerts.
You will not know which you bought until something breaks. That is the wrong moment to find out. So read the deliverables rather than the price, and ask what happens on the bad day.
What a WordPress maintenance plan should include, line by line
1. Updates, applied safely
Not “we update your plugins”. The specifics that matter:
- WordPress core, theme, and plugin updates on a stated cadence — weekly is the sensible floor.
- A backup taken immediately before any update runs.
- Updates applied to a staging copy first, with key pages checked, then pushed live.
- Visual or functional checks after the update, not just a green checkmark that the update installed.
- A documented rollback path if something breaks, and who executes it.
- Premium plugin licence tracking, so updates do not silently stop when a licence lapses.
Updates applied blind to a live site are the single most common cause of an unexpected white screen. The testing step is most of the value.
2. Backups you can actually restore
A backup that has never been restored is an assumption, not a safeguard. The standard:
- Both files and database, on a stated schedule matched to how often your site changes.
- Stored off-site, somewhere separate from the hosting account. A backup on the same server dies with the server.
- A stated retention window, so you can go back past the point where a problem started.
- A periodic restore test. Quarterly is reasonable. Someone restores to a staging site and confirms it works.
- A stated recovery time, so you know whether you are down for an hour or a day.
3. Uptime and error monitoring with a response
Monitoring is cheap. Response is the service. Look for:
- Uptime checks at a short interval, not hourly.
- SSL certificate expiry monitoring, which quietly takes sites offline more often than people expect.
- Broken link and 404 checks.
- PHP error and fatal error monitoring, so the half-broken states get caught too.
- A named response window. “We are alerted” is not the same as “we respond within X hours”.
4. Security hardening and scanning
Security is a configuration, not a plugin. The components:
- Malware scanning on a schedule, with a stated process if something is found.
- A firewall layer — WAF and DDoS protection at the edge, filtering bad traffic before it reaches your server.
- Login protection: rate limiting, two-factor for admin accounts, no default admin usernames.
- File permission and configuration hardening, including disabling file editing from the dashboard.
- User account review, so the developer who left two years ago no longer has administrator access.
- Clear scope on cleanup: whether malware removal is included or billed separately. Ask directly.
5. Performance monitoring and maintenance
- A monthly speed check on your most important pages, with the numbers recorded over time.
- Core Web Vitals tracked, not just a single overall score.
- Database optimization on a cadence: revisions, transients, orphaned metadata.
- Image optimization applied to new uploads, not just a one-time pass at setup.
- Caching verified as working, not merely installed.
6. Reporting that tells you something
A report should answer three questions in under a minute: what was done, what changed, what needs a decision from you. Monthly is standard. If you cannot tell from the report whether the month was good or bad, the report is decoration.
7. Small content and fix time
Most plans include some amount of hands-on time each month for text edits, image swaps, a new page, or a small fix. Ask how much, what counts, and whether unused time rolls over. This is the line item people use most and read least.
Three tiers, and what actually separates them
| Basic | Standard | Concierge | |
|---|---|---|---|
| Updates | Monthly, applied live | Weekly, staged and tested | Weekly, staged and tested |
| Backups | Weekly, host-level | Daily, off-site, 30-day retention | Daily, off-site, tested restores |
| Monitoring | Uptime only | Uptime, SSL, errors | Full, with named response window |
| Security | Scanning | Scanning plus hardening | Scanning, hardening, edge WAF and DDoS protection |
| Performance | None | Monthly check | Monthly check plus remediation |
| Content time | None | A small monthly allowance | A larger allowance plus priority queue |
| Reporting | None or automated | Monthly summary | Monthly summary plus a review call |
The real difference between tiers is rarely the task list. It is whether a human tested the work, how fast someone responds when the site goes down, and whether fixing what the monitoring found is included or quoted separately.
Questions to ask before you sign
Ask these five in writing. The answers separate a real plan from a dashboard subscription.
- Do you test updates on a staging copy before they go live? If no, you are paying for a cron job.
- Where are backups stored, how long are they kept, and when did you last restore one? The third part is the one that matters.
- What is your response time when the site goes down, and does that cover evenings and weekends? Get a number and a window.
- If the site is hacked, is cleanup included or billed separately? This is the most common surprise invoice in the category.
- Who owns the hosting, domain and licences? You should. Always. Confirm it in writing.
What a maintenance plan does not cover
Being clear on this prevents most disputes later. A care plan is upkeep, not a development retainer. Normally outside scope:
- New page or site builds, redesigns, and new features.
- SEO campaigns, content writing, and link building.
- Custom plugin or theme development.
- Fixing problems caused by someone else making changes outside the plan.
- Major platform migrations.
Those are projects. They get scoped and quoted separately, which is correct for both sides. What a plan should cover is everything that keeps what you already have working, secure and fast.
If you are doing it yourself
Run this cadence and you will cover most of it: weekly updates on a staging copy with a backup first, monthly database cleanup and speed check, quarterly backup restore test and PHP version check, and a twice-yearly review of users, licences and permissions.
Put it on a calendar with a specific day and owner. The reason internal maintenance fails is almost never that it was too technical. It is that it was nobody’s named job, and a good week produces no visible result, so it slips.
The practical starting point is finding out what shape your site is in right now: how far behind the updates are, whether the backups restore, what your key pages actually score. Request that assessment on the Free Website Audit page, and you will at least know which of the seven lines above is currently costing you.