Hiring
Website maintenance: the routine that prevents silent failure
Website maintenance is the recurring work that keeps a site functioning after launch: applying updates on staging first, verifying backups actually restore, monitoring uptime and certificate expiry, confirming forms still deliver, and reviewing search errors. Most website failures are silent, which is why a routine beats reacting.
What breaks on a website that nobody touched?
Plenty. Dependencies get security advisories. Certificates expire. Payment gateways deprecate API versions. External links rot as other sites reorganise. Hosting configurations change under you. A PHP version reaches end of life and the host upgrades it.
None of these involve anyone editing your site, and none of them announce themselves. The characteristic failure is a contact form that quietly stopped delivering after a host change, discovered weeks later when someone mentions they never heard back.
What should a monthly routine cover?
- Apply updates on staging, test the critical paths, then deploy — never directly to production.
- Send a real message through the contact form and confirm it arrives, in the inbox rather than in spam.
- Check Search Console for new coverage errors, manual actions and 404s.
- Review uptime, certificate expiry date and Core Web Vitals movement.
- Scan for broken internal and external links.
- Check the checkout end to end if the site takes payments.
- Log what was done, with the date. This is what makes the next problem diagnosable.
What belongs in a quarterly check instead?
- Restore a backup somewhere and confirm it works — a backup never restored is a hypothesis
- Review the dependency list for anything abandoned upstream
- Confirm certificate auto-renewal actually renewed, rather than merely being configured
- Re-read the privacy policy against the tools currently installed
- Review analytics for pages that have stopped performing and content that has become inaccurate
Why is "we have backups" not enough?
Because most backups are untested, and a meaningful proportion of untested backups do not restore. A file backup without the database restores an empty site. A backup stored on the same server as the site disappears with the account that hosted both.
The requirements are specific: files, database and DNS zone; stored somewhere your host does not control; and restored to a test environment at least once so you know the process works before you need it under pressure.
How much maintenance does a static site need?
- Database
- None. There is nothing to back up, corrupt, or leave on an end-of-life engine.
- Plugins
- None. The largest source of both vulnerabilities and breaking updates is absent.
- Runtime version
- None on the server. Nothing executes to be out of date.
- Dependencies
- Build-time only. A vulnerable build dependency cannot be exploited by a visitor.
- Content and monitoring
- Unchanged. These remain real work whatever the architecture.
This is why the ongoing cost of a static site is usually a fraction of a comparable CMS build. The maintenance surface is genuinely smaller, not merely claimed to be.
What should a maintenance agreement specify?
Response times by severity, coverage hours and timezone, backup frequency and retention, what counts as included versus billable, and an escalation route when the normal one is not working.
Severity levels are the useful part. A site down and a typo on a page are not the same emergency, and treating them identically produces both panic and resentment. Two or three levels, each with its own response commitment, is enough.
How do I know whether maintenance is happening?
Ask for the log. A maintenance retainer should produce a dated record of what was checked and what was changed. If nobody can produce one, the retainer is buying availability rather than work — which may be what you want, but you should know which you are paying for.
Questions people ask about this
- How much should website maintenance cost?
- It scales with what is being maintained. A static brochure site needs monitoring and occasional content changes; a WooCommerce store with a dozen plugins and live payments needs genuine attention every month. Retainers here start from $50 a month, and the honest position is that a simple site may not need one at all — it needs monitoring and someone to call.
- Can I do maintenance myself?
- The monthly routine, largely yes — sending a test enquiry, checking Search Console, reviewing uptime alerts. The parts worth delegating are applying updates safely on staging and diagnosing what broke when something does. The failure mode of DIY maintenance is not incompetence; it is that it stops happening after month three.
- What happens if I skip maintenance entirely?
- For a while, nothing visible. Then a certificate expires and every visitor sees a browser warning, or a plugin vulnerability is exploited, or a form stops delivering and you lose enquiries you never knew about. The cost is not the incident itself but the weeks between the failure and noticing it.
- Does maintenance include content updates?
- It depends on the agreement and this is worth settling in advance. Many retainers include a fixed allowance of small changes per month with larger work quoted separately. Ambiguity here is the most common source of friction in an otherwise fine arrangement.
Who wrote this
Anas Bin Masud builds e-commerce sites and does technical SEO for businesses in the UK, Canada and Pakistan — fifteen live client sites, six of them stores taking real payments. The examples in these guides come from those builds and from the audit that rebuilt this site, not from a content brief. More about how I work, or read the case studies.