Launching a site is a project. Keeping it working is a service, and services need different terms. After launch, the questions change: how quickly will you respond if the site goes down on a Sunday, how often are plugins updated, where are the backups, and does "maintenance" include adding a new team member's bio. A website maintenance Statement of Work answers each one in a way you can actually staff.
This template is for web designers and developers who offer monthly care plans for WordPress, Webflow, Shopify and custom sites.
TL;DR
The website maintenance SOW template lists covered tasks with their schedule, backup and restore rules, monitoring, incident severity levels with placeholder response times, a monthly hours bank for small edits, exclusions, reporting, account ownership and term. Send it when the build fix window ends. The key practice is promising response times per severity within stated hours, rather than an uptime percentage you do not control.
What's inside
- Plan summary — the site, platform, plan tier, monthly fee and governing agreement.
- Covered tasks and schedule — updates, backups, monitoring, security and performance checks, with frequency.
- Backups and restore — where backups live, retention and how often restores are tested.
- Incident severity and response times — critical to low, with placeholders for response and update targets.
- Monthly hours bank — small content and design edits, with rollover and overage terms.
- Exclusions — what is quoted separately.
- Accounts and access — hosting, domain, licenses and who owns them.
- Reporting — the monthly care report.
- Fees, term and ending — billing, minimum term, notice and handover.
When to use it
Use this SOW once a site is live and the post-launch fix window from your web development SOW has closed. It also works for sites you did not build, after an onboarding audit. Sign it under a retainer agreement or your general service contract.
It differs from the consulting Statement of Work, which runs a time-bound advisory project rather than ongoing technical care with incident response. It is also more specific than a general retainer SOW: it adds backups, monitoring and severity levels that a design or marketing retainer would not need. If a client wants a redesign or major new feature, quote it as a separate project instead of stretching the hours bank.
Setting response times you can keep
Separate response, update and resolution. Response time is when you acknowledge and start investigating. Update frequency is how often you report progress. Resolution depends on the cause and may involve the host. Commit to the first two, estimate the third.
Tie times to working hours. If you work alone, a four-hour critical response 24/7 is a promise you cannot keep while asleep. State your support hours and what, if anything, you offer outside them. Out-of-hours coverage is a premium tier, not a default.
Define severity by impact, not by tone. Site down or checkout broken is critical. A broken contact form is high. A layout glitch on one page is medium. Typos are low. The client picks the issue; the definition picks the severity.
Test restores. A backup that has never been restored is a hope. Many care plans include a quarterly restore test to a staging copy.
Updates on staging first. For sites with e-commerce or many plugins, test updates on staging and apply to production in a set window. Include rollback.
Customize it in your COLO workspace
Create each care plan as a project in COLO and add recurring checks and client requests as tasks with priorities that match your severity levels. The client can follow the tasks you make visible and send new requests through the client portal and project chat.
Log time against the hours bank with the timer, marking routine checks as non-billable if they are covered by the base fee. A project budget set to the monthly bank warns you at 80% and stops billable timers at 100%, so overage becomes a decision rather than a surprise. Bill the monthly fee and any approved overage on an invoice the client can pay by card or PayPal.
Common mistakes
- Promising uptime. Unless you run the servers, you cannot guarantee uptime. Promise monitoring and response.
- Unlimited "small changes". Without an hours bank, every request is small until it is a redesign.
- Backups on the same server. If the host fails, so do the backups. Store copies off-site.
- No exclusions for hacked sites. Clean-up after a compromise can take days. State whether it is included or billed.
- Hosting in your name. If the plan ends, migrating the site out of your account becomes a project.
FAQ
Q: What does a website maintenance plan usually include?
Core, theme and plugin updates, scheduled backups with restore tests, uptime and security monitoring, a small monthly bank of content edits, and a monthly report. New features and redesigns are usually excluded and quoted separately.
Q: Should I promise response times in a maintenance SOW?
Yes, but promise what you can actually staff. Tie each response time to a severity level and to your working hours, and separate response time from fix time, because you cannot always guarantee how long a fix will take.
Q: What if a plugin update breaks the site?
Test updates on staging first where possible, keep a recent backup, and include rollback in the covered tasks. The SOW should say whether repairing a third-party plugin conflict is covered or billed from the hours bank.
Q: Who should pay for hosting and plugin licenses?
Most freelancers keep hosting and licenses in the client's name and billing, with admin access granted to them. If you resell hosting, list it as a separate line and say what happens to it if the plan ends.
Q: Is uptime monitoring the same as an uptime guarantee?
No. Monitoring means you are alerted and respond. Uptime itself depends on the host. Unless you control the infrastructure, avoid promising an uptime percentage.