Most website maintenance contracts sold to small and mid-sized businesses buy exactly one thing: someone clicking an update button, roughly monthly, usually without checking whether the site still works afterwards. That is not maintenance. That is a subscription to a button.
Real maintenance is a defined set of recurring engineering tasks, each with evidence attached, each auditable by you. Below is the scope you should be buying, the scope you are probably getting, and a checklist you can send to your current provider today.
What Website Maintenance Actually Means
Website maintenance is the recurring work that keeps a site secure, available, restorable, and fast while everything around it changes. A complete scope covers seven things: dependency updates, security patching, tested backups, uptime and certificate monitoring, log review, performance budget checks, and a contractual response time. Anything less is hosting with extra steps.
The reason is simple: a website is a software product, and software decays even when nobody touches it. Dependencies accumulate publicly disclosed vulnerabilities. Certificates expire. Hosts move you onto a new PHP or Node runtime. Third-party scripts change behaviour without asking. Browsers deprecate features.
- ▸Nothing is static, so "we did not change anything" is never a reason a site cannot break.
- ▸The failure mode is silent, because most decay produces no error page until the day it produces a very large one.
What Most Maintenance Retainers Really Cover
Most retainers cover three activities: plugin and core updates, an uptime ping on the homepage, and a small allowance of content edits. They typically exclude the expensive, valuable parts: restore testing, log review, performance verification, and a written response-time commitment. Nearly every serious incident I have seen at SME scale lives in that excluded gap.
You are probably buying the thin version if any of the following is true.
- ▸The monthly report is a list of plugin version numbers with no note about what changed or why it mattered.
- ▸Backups exist, but nobody has ever restored one into a clean environment.
- ▸Uptime monitoring checks the homepage only, so a broken checkout or a failing contact form goes unnoticed until a customer emails.
- ▸There is no named response time. "We will get to it" is the service level.
- ▸Nobody can produce an inventory of what the site actually runs.
- ▸Updates are fully automatic with no staging and no rollback path, which is not safer, just a different way to break.
Dependency Updates and Security Patching Are Two Different Jobs
Updating dependencies keeps you current. Security patching responds to a specific known vulnerability in something you actually run, on a clock. Same tools, different questions. A vendor who only does the first will apply your critical patch during the next scheduled window, which can be three weeks after public exploitation began.
A defensible patching practice has four parts.
- ▸An inventory. CMS core version, every plugin, theme and package with its version, the server runtime, and every third-party script loaded on the page. Without this list, patching is guesswork.
- ▸Advisory monitoring for the components on that list, not a generic newsletter.
- ▸Patch classes with deadlines. Critical and actively exploited: hours. High severity: days. Routine: the monthly batch. Write the numbers into the contract.
- ▸Staging and rollback for anything touching a database migration, a payment path, or a login flow.
On the WordPress and plugin ecosystem specifically, understand the mechanism rather than memorising numbers. Third-party extensions add REST routes, admin endpoints, shortcodes, and file upload handlers, and they inherit the full privileges of the site. The recurring risk classes are unauthenticated privilege escalation, arbitrary file upload, stored cross-site scripting, and injection through unsanitised parameters. The dangerous part is abandonment: a plugin whose author stopped shipping fixes keeps working perfectly while quietly going unpatched, so nothing looks broken. Verify any version-specific claim against the vendor advisory before acting. This is the same dynamic covered in Supply Chain Attacks: Why Your Dependencies Are Your Biggest Risk, scaled down to a marketing site.
Backups Are Worthless Until You Restore One
A backup you have never restored is a hypothesis. Maintenance should include scheduled restore drills into a clean environment, with a recorded restore time and a written result. You need three numbers you can say out loud: how far back you can go, how much data a restore loses, and how long a full restore takes.
- ▸Store at least one copy outside the hosting account. A compromised hosting login and a ransomware event both destroy backups that sit next to the site.
- ▸Prefer immutable or write-once storage where your provider offers it.
- ▸Back up everything, not just the database. Uploads, configuration, cron definitions, and a copy of DNS and TLS settings. A database-only backup restores a site with no images.
- ▸Keep retention long enough to predate a slow compromise. Attackers often sit quietly for weeks, so a seven-day retention window can mean every backup you hold already contains the backdoor.
- ▸Drill quarterly at minimum, and after any platform or host change.
For the wider version of this discipline, see The Restore You Rehearse: Business Continuity and DR for SMEs in 2026.
Monitoring That Catches the Failures You Actually Have
A homepage ping every five minutes tells you almost nothing. Real monitoring covers transaction checks on the paths that make money, certificate expiry alerts well ahead of the deadline, domain and DNS change alerts, and error-rate alerting. Most outages that hurt an SME are partial, not total, and partial outages are invisible to a ping.
- ▸Synthetic checks on real journeys: homepage, a key service or product page, contact form submission, checkout or booking, and the login path.
- ▸Certificate alerts at 30, 14, and 7 days, including the certificates people forget: mail subdomains, staging, and any API hostname.
- ▸Domain renewal and DNS change alerts, with registrar lock enabled.
- ▸Error-rate and conversion alerting. A sudden drop in successful form submissions is how you catch a form that silently stopped delivering.
- ▸A named destination for alerts and a named human who is accountable when one fires at 02:00.
Log Review, Performance Budgets, and the Slow Rot
Two recurring reviews separate maintenance from babysitting: a monthly pass over access, error, and authentication logs, and a performance budget check against real field data. Both catch problems weeks before customers do, and both produce a short written record you can keep in a folder and show an auditor or an insurer.
What a useful log review looks for:
- ▸Failed admin logins, their volume, and their source.
- ▸New administrator accounts or role changes nobody requested.
- ▸Unexpected POST requests to admin or REST endpoints.
- ▸New or modified files in upload directories.
- ▸Outbound connections from the web host to places it should never call.
On performance, set a budget rather than chasing a score. Agree target numbers for page weight, largest contentful paint, and interaction latency, then check them monthly against field data from real visitors instead of a one-off lab run. Regressions almost always arrive with a new plugin, a new tracking tag, or an unoptimised hero image, and they are trivially cheap to fix in the week they appear. Performance Budgets: Treat Speed as a Requirement, Not a Wish covers how to set the numbers.
Response Time, Escalation, and What Support Means in Writing
Support is only real when it has four properties: a severity scale, a named response time per severity, a monitored channel, and an accountable person including out of hours if you need that. Without all four you have a hope, not a contract. Response time means a human assessment, not a resolution.
- ▸Severity definitions. S1: site down, compromised, or leaking data. S2: a revenue path broken. S3: degraded. S4: cosmetic.
- ▸Coverage hours, escalation path, and out-of-hours cost, agreed before the incident, not during it.
- ▸Credential handling. Individual named accounts, no shared logins, and an access list you can review. The findings in What Security Auditors Find in Almost Every Admin Panel are mostly access-control debt of exactly this kind.
- ▸Offboarding terms. You own the code, the backups, the DNS, the registrar, and the analytics. Confirm it in writing while the relationship is good.
The Checklist You Can Hold a Vendor To
Send these questions to your current provider and ask for a yes or no with evidence. A competent vendor answers within a day. Silence, or a reply that redefines the question, tells you what you are actually paying for. Print it, and use the same list when you compare quotes.
- ▸Do you keep a written inventory of every component this site runs, with versions?
- ▸What is your patch deadline for a critical, actively exploited vulnerability?
- ▸Do you test updates on staging before production, and can you roll back?
- ▸Where are backups stored, and are they outside the hosting account?
- ▸When did you last perform a full restore, and how long did it take?
- ▸Exactly what do you monitor, and which user journeys are covered?
- ▸Do you review logs, and may I see last month's review?
- ▸What is the agreed performance budget, and what were last month's numbers?
- ▸What is your response time for a site-down event, and what does out-of-hours cost?
- ▸Who has administrator access today, and when was that list last reviewed?
- ▸What happens to my access, code, backups, and DNS if we part ways?
- ▸Which of these tasks are explicitly excluded from my current plan?
If most answers come back as "that is not included", you now have a precise, priced conversation instead of a vague sense that you are overpaying.
How TuniCyberLabs helps
We run maintenance as an engineering practice, not a checklist theatre: component inventory, patch deadlines by severity, restore drills with recorded times, journey-level monitoring, monthly log and performance reviews, and a written response-time commitment. We are equally happy auditing an existing retainer and telling you it is fine.
Want a straight answer on what your current plan actually covers? Talk to our team and we will review your scope with you.