A website maintenance plan should include, in writing: software updates with security patching, off-site backups with tested restores, security scanning, uptime monitoring with a named responder, a defined content-edit allowance, performance and form checks, and a monthly report. If your plan just says "maintenance and support," you have a promise you cannot audit, not a scope.
The short answer: the included list, in one table
Sort any plan into three groups: core cover that should be included, work fairly billed separately, and padding to challenge.
| Should be included | Fairly billed separately | Challenge before signing |
|---|---|---|
| Core, theme and plugin updates | New pages or features | "SEO included" with no named tasks |
| Security patching and scanning | Redesigns and template changes | "Performance optimisation" with no check or report |
| Off-site backups, kept for a stated period | Malware cleanup after a serious compromise, if stated upfront | "24/7 support" with no response time |
| Restore tests on a schedule | Emergency out-of-hours work at a stated rate | "Unlimited edits" limited by an undefined "small changes" rule |
| Uptime monitoring with a named responder | Copywriting and photography | Duplicate lines restating updates twice |
| A stated edit allowance and turnaround | Hosting, domain and licence fees, itemised | "Priority care" with no deliverable |
Test each row using the sections below.
The problem: paying a retainer you cannot audit
Most owners sign a plan because the alternative — nobody watching the site — feels riskier. The plan then renews monthly while the work stays invisible, until an update breaks the site or a form stops delivering.
The fix is not a bigger plan. It is a checkable one: every line should name a task, a frequency, and the evidence you will see. Choosing who does the work is a separate question, covered in our guide on maintenance by an agency, freelancer or in-house.
Core technical cover: updates, security patching and scanning
The technical core is keeping software current and watching for compromise: updates to the CMS core, theme and plugins on a stated schedule, with security patches applied promptly. WordPress's own documentation treats updating as a core security practice, and OWASP guidance makes the same point — known vulnerabilities in old versions are the easiest route in.
Two details separate a real plan from an update subscription. First, staging tests before updates, so a plugin conflict is caught by your provider, not a customer. Second, scanning should be named: what is scanned, how often, and what happens when a scan finds something. A scan that only produces an email nobody acts on is monitoring, not cover.
Backups that are proven, not promised: frequency, retention and restore tests
A backup line should answer four questions: how often backups run, where they are stored, how long they are kept, and when a restore was last tested. Storage matters: a backup on the same server fails in exactly the incident you most need it for, so backups belong off-site. Frequency should match how fast your site changes, but must be stated, not implied.
The restore test is the line most plans omit, and the one that decides whether the others matter. A backup job reporting success only proves a file was written; a restore test proves the site can be rebuilt from it. If the answer to "when was the last test?" is "never," the backup line is a promise, not cover.
Monitoring and incident response: who knows first, and how fast?
Uptime monitoring should check the site at stated intervals and alert a person who can act — not an inbox nobody watches overnight.
Response times belong in the plan, in at least two classes — emergency (site down, booking broken, security incident) and routine — each with a stated response time and working hours. "Emergency cover" without hours is meaningless for a UAE business whose customers browse in the evening: check whether cover matches your trading hours, and what out-of-hours work costs. Check too whether fixing is included or billed separately — fair only if stated beforehand.
Content edits: what the allowance really covers (minutes, tasks, turnaround)
Content edits are where owners most often feel misled, because "content updates included" can mean almost anything. A checkable plan states the allowance as time (for example, 30 minutes of minor changes a month) or as tasks (a stated number of small requests).
Ask what counts as one edit. Swapping a photo or changing a phone number is a minor change; building a new landing page is project work, and a plan that pretends otherwise will disappoint both sides. Also ask the turnaround, whether unused allowance rolls over, and what happens when a request exceeds it.
Performance, forms and the monthly report you should actually receive
A plan should protect the paths that make the site earn: periodic performance checks against published criteria such as Google's Core Web Vitals thresholds, broken-link checks, and — most neglected — testing the enquiry paths. Submit the contact form, tap the WhatsApp and call links, and confirm the message arrives. Forms break silently after updates, and no uptime monitor will notice.
All of this becomes real only in the monthly report: updates applied, backup dates and the last restore test, scan results, uptime or incidents, performance outcome, form tests, and edits completed against your allowance. If your provider cannot produce that list, you have no evidence the work is happening. Our website handover and ownership checklist covers what you should hold yourself.
Legitimately excluded: the lines that are fairly billed separately
Not every extra charge is padding. Honest plans exclude real project work: new pages and features, redesigns, integrations, copywriting and photography, and major migrations. Emergency work outside agreed hours at a stated rate is also fair, as are pass-through costs such as hosting, domain renewal and premium licences — provided they are itemised, not buried.
The test is whether the exclusion is named before you sign, so you can budget for project work separately — as you would compare scoped work against published pricing or a fixed-price web design structure.
Invented lines: padding to challenge before you sign
Some lines exist to make a plan look longer. Challenge any line that names an outcome instead of a task: "SEO included" with no tasks listed, or "Google ranking maintenance," which no provider can honestly promise. Challenge duplicates too — three names for one job.
Also challenge undefined premium language: "priority support" with no response time, "proactive care" with no named checks, "unlimited" allowances limited by an undefined fair-use rule. The remedy is one question: what will you do, how often, and what will I see as evidence? For Arabic sites, the same audit applies to the costs in our guide to Arabic website running costs after launch.
A defined scope, as a worked example: what "3 months free maintenance" specifies
Compare that vagueness with a scope written to be checked. WebStackRank's starter packages include 3 months free maintenance, stated in four items: a health check, updates, defect fixes, and 30 minutes of minor changes. Each can be verified — a defect is either fixed or it is not, and 30 minutes is a measure both sides can count.
Note what it does not claim: no unlimited edits, no new features, no round-the-clock cover. It is a starter scope for the first 3 months, not a retainer in disguise. A short, defined list you can audit beats a long, vague one — which is why WebStackRank's web development in the UAE model has no retainer required.
Common mistakes
The most common mistake is comparing plans by price or list length, instead of by whether each line is checkable. Other errors: assuming backups are tested because they are scheduled; assuming "content updates" covers new pages; never asking who receives the downtime alert; and only auditing the plan after an incident.
FAQ
What is not included in a typical website maintenance plan?
New pages and features, redesigns, copywriting and photography, major migrations, and third-party costs such as hosting, domains and premium licences are normally excluded and billed separately. That is fair when named in writing before you sign — a problem when discovered on an invoice.
How often should backups be taken, and should restores be tested?
Frequency should match how often your site changes and takes enquiries or orders, and the plan should state it, plus storage location and retention. Yes — restores should be tested on a schedule: a backup job reporting success only proves a file was written, not that your site can be rebuilt from it.
What should a monthly maintenance report show?
Updates applied, backup dates and the last restore test, scan results, uptime and incidents, a performance check, form and contact-link tests, and edits completed against your allowance. If a report cannot list those items, there is no evidence the work is happening.
Is a maintenance plan better than paying for fixes as they arise?
For a site that generates enquiries or sales, a defined plan usually wins, because updates, backups and monitoring happen continuously rather than after a failure. For a rarely changed brochure site, ad hoc fixes can be enough.
What does "no retainer required" actually mean?
It means work is sold as a defined scope for a stated price, not as an open-ended monthly commitment. Maintenance can still be bought when needed — as specified tasks you can check.
Get a maintenance scope written down, line by line (CTA)
Take your current plan and mark every line included, excluded or invented using the table above. Query any line you cannot classify.
If you are starting a new site, begin with a scope defined from day one. WebStackRank's web development in the UAE packages state what is included, including the 3 months free maintenance scope above, with an itemised proposal within 24 business hours and no retainer required.
