There's no such thing as "the site is done." Delivery isn't an ending, it's a starting point — and projects that don't discuss this upfront end up arguing "is this covered under warranty?" the moment something breaks. This post covers what maintenance should actually include, and how long an unmaintained site survives.
How long does an unmaintained site last?
Roughly, here's what I've observed:
- 0-3 months: Nothing happens. Everyone gets convinced maintenance was unnecessary.
- 3-6 months: If the SSL certificate isn't renewed, the site starts showing a "not secure" warning. That alone tanks conversion significantly.
- 6-12 months: Known vulnerabilities pile up in unpatched components. Automated scanning bots look for exactly this — you don't need to be targeted, your turn just comes.
- 12+ months: The host upgrades the PHP version, the site shows a white screen. This usually happens on a Friday evening.
So maintenance isn't paying for "things get a little better" — it's paying for the site continuing to exist.
What should be in a maintenance plan
Backups — and more importantly, restoring them
Every maintenance offer says "daily backups." That's not the right question to ask. Ask these instead:
- Where is the backup stored? If it's on the same server, it disappears when the server does.
- How many versions are kept? If only the latest backup exists and the problem started three days ago, it's useless.
- Has a restore ever actually been tested? An untested backup isn't a backup. Restore it to a blank environment once a year and confirm it works.
Updates
Server software, PHP version, libraries, and plugins if any. The critical rule: test updates in a staging environment first. A maintenance service that updates production directly isn't doing maintenance — it's gambling.
Security monitoring
- Automatic SSL renewal, with an alert if it doesn't renew
- File-change monitoring — a heads-up if an unexpected file appears
- Tracking failed login attempts against the admin panel
- Regular scanning of the libraries in use for known vulnerabilities
Uptime monitoring
Finding out the site is down from your client is the most expensive way to find out. Set up a monitoring tool that checks every five minutes. Don't just monitor the homepage — monitor a critical flow like the contact form too. The homepage can load fine while the form is broken.
A regular health report
Monthly, one page, no jargon:
- Uptime percentage
- Core Web Vitals values — change from last month
- New crawl/indexing errors in Search Console
- Broken links
- Updates applied and any incidents handled
What shouldn't be in maintenance
This part matters just as much. A maintenance fee isn't unlimited development hours. The following should be quoted separately and written into the contract:
- New pages or new modules
- Design changes
- Copywriting and ongoing content entry
- New integrations
- SEO consulting and content strategy
On the other hand, these should be included: small text and image fixes (with a reasonable monthly time cap), bug fixes, and keeping delivered features working.
A minimum program if you're managing your own site
The least you can do without hiring anyone:
- Weekly: open the site on your phone and click around. Send yourself a test message through the contact form.
- Monthly: open Search Console, check for new errors. Confirm the backup actually ran.
- Every quarter: apply updates. Review passwords. Take a performance measurement.
- Yearly: restore the backup to a blank environment and test it. Check domain and hosting renewal dates.
That last item is the most commonly skipped, and more sites get lost to an expired domain than to an actual attack. Put domain renewal on autopay, and make sure the billing email still goes somewhere you actually read.