Website Maintenance: What Actually Needs Doing Every Month

Maintenance retainers are sold badly. The invoice says "monthly maintenance", the client has no idea what was done, so the first time cash is tight the line gets cut, and eight months later the site is running an outdated stack with no working backups. The fix is to say plainly what happens each month, what is automated, and what is only there for the day something goes wrong.

The parts that must be automatic

Anything that depends on someone remembering will eventually not happen. Backups should run on a schedule, to storage that is not the same server, with a retention window you have actually chosen. Certificates should renew themselves. Uptime checks should page a human rather than sit on a dashboard nobody opens. Dependency alerts should arrive as pull requests. None of this is billable work once it is set up, which is exactly why it belongs in the build rather than in the retainer.

• Off-server backups on a schedule, with retention stated in writing.
• One restore test per quarter. An untested backup is a hope, not a backup.
• Automatic certificate renewal, with an expiry alert as the safety net.
• Uptime and error alerting that reaches a person, not a dashboard.
• Domain auto-renewal, with the registrar contact address pointing at someone who still works there.

The domain point deserves its own line for Nepali businesses. A .com.np registration follows different rules and paperwork from a .com, and the person who originally handled it has often left the company. Write down who holds it and how it gets renewed, before the week it expires.

The monthly pass

Half an hour of deliberate looking, once a month, catches most of what matters. Apply security updates and note anything skipped and why. Read the error log rather than glancing at it, because the same exception repeating five hundred times is a bug someone stopped noticing. Check that forms still deliver mail, that payments still reconcile, and that the contact page shows the current phone number. Look at Core Web Vitals in Search Console, since performance decays quietly as content and third-party scripts accumulate; the field data in our note on Core Web Vitals is the part that reflects real users rather than a lab score.

• Security updates applied, with a written note on anything deliberately deferred.
• Error log read, not skimmed. Count the repeats.
• One live test of the contact form and one of the checkout, from a phone.
• Disk space, database size and any queue backlog, which fail slowly and then all at once.
• Search Console coverage, for pages that dropped out of the index without anyone noticing.

Send a client three lines saying what you updated, what you found and what you are watching. It is the cheapest retention work you will ever do.

Security is most of the value, and it is unglamorous

The realistic threats to a small business site are automated: bots probing for known vulnerabilities in old plugins, credential stuffing against the admin login, and form spam that turns into a mail reputation problem. None of them are targeted, all of them are constant, and almost all are stopped by keeping software current, enforcing two-factor authentication on every administrative account, rate limiting login attempts, and removing the accounts of people who left. Review the user list every quarter; it is the single fastest security audit available.

What decays without anyone touching the code

A site that has not been deployed in a year still gets worse. Third-party embeds change their scripts, images pile up on pages that were never optimised, plugin authors abandon their work, an API you depend on deprecates a version, and content goes out of date in ways that damage trust more than any bug does. Once a quarter, walk the site as a customer would: search for the business, click the first result, and try to make an enquiry on a phone using mobile data. That five-minute exercise finds more real problems than a monitoring dashboard.

• Prices, opening hours and staff pages that no longer match reality.
• Third-party scripts that have grown, slowing every page since the last check.
• An expired API key or a payment integration on a deprecated version.
• Blog posts referring to a service you stopped offering.
• Images uploaded at camera resolution by whoever last edited a page.

What is only worth doing when it breaks

Not everything belongs on the monthly list. Chasing every minor dependency bump, rewriting working code to a newer framework version, or performance tuning a page nobody visits are activities that fill a retainer without improving anything. Be honest about the difference between maintenance and optional work, quote the optional work separately, and let the client decide. A retainer that quietly absorbs discretionary work is a retainer the client will eventually resent.

Write down who has the keys

The worst maintenance emergencies are access problems, not technical ones. Keep a current record of the domain registrar, DNS, hosting, repository, mail provider, payment gateway, analytics and any third-party service with a login, along with who holds each account. Review it whenever someone leaves. A site that is down because nobody can log in to the registrar is down for days, not minutes, and no amount of technical skill shortens that.

This is also why we hand over ownership of code, domain and hosting on day one rather than holding accounts on a client's behalf. If a maintenance relationship ends, the client should be able to hire anyone else on Monday. That is a commercial position as much as a technical one, and it is described on our web development service.

What a fair retainer looks like

Price it as a small number of hours a month with a named scope, not as a percentage of the build. State what is included, state the response time you are actually committing to, and state what happens outside it. A retainer that promises unlimited changes will either be underused, in which case the client feels cheated, or overused, in which case you resent it. If the site is genuinely stable and the client is technical enough to run the monthly pass themselves, say so and sell them the setup instead. If the hosting side is the complicated part, the groundwork in DevOps on a budget for startups is what makes the retainer small, and it is the same work we do under cloud and DevOps.

The minimum, if you do nothing else

Automated off-server backups that someone has restored from at least once, automatic certificate renewal, uptime alerting to a phone, security updates applied monthly, and a written list of who holds which account. That is the floor. Everything above it is a judgement about how much the site is worth to the business, and that is a conversation to have once a year rather than an assumption baked into an invoice. If your site has accounts and passwords attached to it, the maintenance burden of those is worth reducing too, which is the argument in passkeys for small product teams.