Website maintenance is the most opaque line item most businesses pay for. Money leaves every month, a report arrives, and nothing visibly changes, which is either exactly right or a complete waste and the client usually cannot tell which.
It is often exactly right. Good maintenance is invisible by design: the site did not break, was not compromised, and did not get slower. Absence of incident is the product.
But it is also frequently a waste, and the difference is whether specific tasks are being done on a schedule or whether someone is logging in occasionally to confirm the homepage loads. This article sets out what should be happening so you can ask.
When to stop maintaining and rebuild
Maintenance has a point past which it stops being economical, and recognising it saves money that would otherwise go into keeping a declining asset alive.
The signals are recognisable. Updates have become risky enough that they are deferred, which means the gap grows and each one becomes riskier still. The platform or framework is past its supported life, so security patches are no longer issued. Every change requires a developer because the CMS was never usable by your team. And the accumulated performance debt cannot be fixed without touching the theme, which nobody wants to touch.
Two or three of those is manageable. All of them together usually means you are paying maintenance on something that should be replaced, and the monthly cost over two more years will approach the rebuild.
The calculation worth doing is the three-year total: maintenance plus the developer time for changes plus the cost of the performance and conversion you are not getting, against a rebuild plus lower ongoing maintenance. For sites more than five or six years old on an unsupported stack, the rebuild frequently wins.
What maintenance actually covers
Four distinct things get bundled under one word, and conflating them is how expectations break.
Keeping it working: updates, backups, monitoring, fixing what breaks. This is the core and the part that is genuinely non-optional.
Keeping it secure: patching known vulnerabilities, credential hygiene, firewall rules, and responding if something happens. Overlaps heavily with the first.
Keeping it fast: performance does not stay where you left it. A new tag, an unoptimised image in a blog post, a plugin update that added weight. Without periodic attention a site gets slower every quarter.
And changes: new pages, content updates, small feature additions. This is the one most often disputed, because clients assume it is included and suppliers assume it is billable. Settle it in writing at the start, with a monthly allowance of hours if that suits both sides.
In practice
The actual schedule
Frequency matters more than effort. These are the intervals that prevent most problems.
| Task | Frequency | Why |
|---|---|---|
| Core, theme and plugin updates | Monthly, tested on staging | The main compromise route |
| Backup verification by restoring | Twice yearly | An untested backup is a hope |
| Uptime and error monitoring | Continuous, alerting | You should know before customers do |
| Core Web Vitals field data review | Monthly | Performance regresses quietly |
| Broken link and 404 check | Quarterly | Accumulates after every content change |
| Search Console coverage review | Monthly | Catches indexing problems early |
| Form and checkout testing | Monthly | Abandoned forms are invisible until someone complains |
| SSL and domain renewal check | Quarterly | Expiry takes the site down entirely |
| Unused plugin and account removal | Quarterly | Deactivated is not removed |
| Dependency vulnerability scan | Monthly | Known issues published constantly |
What it should cost
Indicative monthly figures in India for genuine maintenance rather than a nominal retainer.
A small brochure site, statically built or lightly dynamic, needs relatively little: ₹2,000 to ₹8,000 a month covers updates, monitoring, backups and occasional small changes.
A business site on WordPress with a CMS and a plugin set needs more attention, because the update surface is larger and each update carries risk: ₹5,000 to ₹20,000 a month.
eCommerce is higher again, because downtime and checkout failures cost money directly and the testing burden after each update is real: ₹15,000 to ₹60,000 a month.
A custom application with a backend, integrations and its own dependency tree sits above that and should be scoped rather than quoted from a table.
Be sceptical of very low figures. Below a few thousand rupees a month nobody is testing updates on staging, which means they are either applying them blindly or not applying them.
How to tell if you are paying for nothing
Ask for evidence rather than a report, and four questions establish it quickly.
What was updated last month, specifically, and was it tested before going live. A supplier doing the work can list versions. One who cannot is not doing it.
When did you last restore a backup to verify it works, and how long did it take. If the answer is never, you do not have backups, you have files you hope are backups.
What are the current Core Web Vitals field figures and how have they moved over six months. This is visible to them in Search Console and it shows whether anyone is watching performance.
And what did you find and fix that I did not report to you. Good maintenance catches things before the client notices. If every item on the report originated from you reporting a problem, then you are the monitoring system and you are paying someone to respond to it.
The most common gap
Ask when someone last submitted your contact form and confirmed the enquiry arrived in a monitored inbox. Silently broken forms are astonishingly common, frequently after an unrelated plugin update, and they can run for months before anyone realises enquiries stopped. It takes two minutes to check and almost nobody does it.
Key takeaways
- Good maintenance is invisible; absence of incident is the product. That is also why waste is hard to spot.
- Four different things get bundled as maintenance. Settle in writing whether changes are included.
- Updates monthly on staging, backups verified twice yearly by actually restoring them.
- Genuine maintenance for a business WordPress site runs ₹5,000 to ₹20,000 a month.
- Ask what was found and fixed that you did not report. If nothing, you are the monitoring.
- Test your contact form monthly. Silently broken forms run for months before anyone notices.
Frequently asked
A small brochure site runs ₹2,000 to ₹8,000 a month, a business WordPress site ₹5,000 to ₹20,000, and eCommerce ₹15,000 to ₹60,000 because downtime costs money directly and update testing is heavier. Below a few thousand rupees nobody is testing updates on staging, which means they are applying them blindly or not at all.
Initially nothing, which is why it gets deferred. Over six to eighteen months: known vulnerabilities go unpatched until a scanner finds you, performance degrades with every unoptimised addition, forms break silently after unrelated updates, and eventually an update becomes impossible to apply safely because too many versions have passed.
That depends entirely on the agreement and it is the most commonly disputed item. Clients usually assume included, suppliers usually assume billable. Settle it in writing at the start, ideally as a monthly allowance of hours with anything beyond it quoted separately. A contract silent on this produces an uncomfortable conversation in month three.
Ask four questions: what was updated last month and was it tested on staging, when did you last verify a backup by restoring it, what are the current Core Web Vitals field figures and how have they moved, and what did you find and fix that I did not report. The last one is the most revealing.