Site Care and Maintenance Plans

A site care plan covers the ongoing work a website needs after launch: updates, uptime monitoring, backups, security checks, broken link cleanup, and the small fixes that accumulate quietly across a year until somebody notices the site has degraded.

Websites are frequently treated as a project with an end date. They are closer to a vehicle. Left alone they do not stay in the state you left them, because everything around them keeps moving: browsers update, plugins change, integrations break, and certificates expire.

Websites decay quietly

Nothing about the decay announces itself. A plugin stops being maintained by its developer and quietly becomes a liability. A contact form stops delivering because a mail setting changed at the host. A certificate lapses. An embedded map stops loading after an API change nobody told you about.

Most owners find out from a customer, and often weeks later. By then the inquiries that never arrived are simply gone, and there is no report anywhere showing what they would have been worth. That is the expensive part: the failure is invisible in exactly the way that matters.

The failure that costs the most

Contact form failure is the most damaging and the least detected problem in this category. A form that has stopped sending looks completely normal to a visitor. They fill it in, see a thank you message, and wait for a reply that will never come. Meanwhile your analytics record a conversion.

Most maintenance plans do not test forms. It is the first thing we check, because a site can be perfectly updated, fast, and secure while silently discarding every inquiry it receives.

What a care plan should include

  • Core, plugin, and theme updates applied on a schedule with verification afterwards rather than blindly
  • Uptime monitoring that alerts us rather than waiting for you to notice
  • Contact forms tested on a schedule, since silent failure is the most expensive kind
  • Off server backups verified as genuinely restorable
  • Broken link and error monitoring, since these accumulate invisibly after content changes
  • A plain monthly summary of what was done, including the months when little was needed

Verification after updates is the part that separates a real plan from an automated one. Applying updates is trivial and can be automated by anyone. Checking that the site still works afterwards, particularly the pages that generate inquiries, is the part that requires a person.

What you receive

  • Scheduled updates with post update checks on the pages that matter
  • Monitoring for uptime, forms, and errors
  • Verified backups with sensible retention
  • A monthly summary written in plain language
  • A named person who knows your site rather than a ticket queue

Questions we get asked

Can I just do this myself?

Yes, and some owners do it well. The honest question is whether you will still be doing it in eight months, because maintenance fails through drift rather than through inability. It gets postponed during a busy period and never resumes. If the answer is probably not, a plan costs less than the eventual cleanup.

What if nothing needs doing this month?

Then the report says exactly that. You are paying for the site being watched and for problems being caught early, not for invented work to justify an invoice. A maintenance report that always contains a satisfying list of activity is worth being suspicious of.

Does this include design changes?

Small text and image updates usually yes. Larger changes are quoted separately so you are not paying a retainer that quietly covers very little, or receiving a bill that expands without warning. The boundary should be written down rather than negotiated after the fact.

How is this different from what my host provides?

Hosts maintain the server. Care plans maintain the site on it. A host will keep the machine running and patched while your plugins go three versions out of date and your contact form quietly fails. The two are complementary rather than interchangeable.

What happens if something breaks?

We fix it, and if an update caused it we roll back to the previous state and investigate before trying again. That is the reason updates get tested rather than applied automatically, and the reason backups need to be restorable rather than merely present.

Do I need this if my site rarely changes?

Arguably more, not less. A site nobody logs into is a site nobody notices problems on. Low change sites are exactly where a form failure or an expired certificate can persist for months without anyone realising.

We will run a health check on your current site first, so you can see what state it is actually in before deciding whether an ongoing plan is worth it.

What a monthly report should tell you

Maintenance reporting has a tendency to become a list of tasks that means nothing to the person reading it. Nineteen plugin updates applied tells you activity happened. It does not tell you whether the site is in better shape than last month.

More useful is what changed, what was found, and what needs a decision. If a plugin has been abandoned by its developer, that is worth raising. If a form failed and was fixed, that matters. If the month was genuinely quiet, saying so plainly is more honest than filling a page.

What is not included in a care plan?

New features, design changes, and content work are normally quoted separately. The boundary should be written down at the start. Plans that quietly absorb small requests tend to either erode for us or expand into an unexpected invoice for you, and neither is a good outcome.

What if I already have a developer?

Then a care plan may be unnecessary and we will say so. Where it still helps is monitoring and the scheduled checks that busy developers deprioritise. There is no point paying two parties to do the same work.

How quickly do you respond when something breaks?

Site down is treated as urgent and handled the same day wherever possible. Smaller issues get picked up in the normal maintenance cycle. What matters more than a stated response time is that monitoring means we usually know before you do, which removes the delay between something breaking and someone noticing.