The Website Maintenance Nobody Quotes You For

The most expensive website failures leave the front page looking completely normal. A form that quietly stops delivering, a backup nobody has ever restored, a tracking tag dropped in a redesign. What belongs in a maintenance plan, and what to automate.

Most website projects treat launch day as the finish line. The invoice clears, the team moves on, and the site then runs unattended for the next eighteen months. What happens in those eighteen months is rarely dramatic. It is slow, quiet degradation, and the most expensive failures are the ones that leave the front page looking completely normal.

This is the part of owning a website that almost nobody quotes for properly, and it is worth understanding in detail before you buy a maintenance plan, because the plans on the market vary enormously in what they actually cover.

The silent failures are the ones that cost money

The single most common serious problem we find on an inherited site is a contact form that stopped delivering. There are many ways it happens. An email credential gets rotated. A DNS record changes when someone moves the domain. A receiving mailbox starts filing the notifications as spam. A plugin update quietly breaks the handler. A sending service suspends an account for a billing failure.

In every one of those cases the visitor still sees the confirmation message. The form still submits. Nothing on the site looks wrong. The only symptom is an absence, and an absence is almost impossible to notice. Businesses typically discover it weeks later when a customer mentions in passing that they filled out the form and never heard back, and by then every inquiry in that window is gone permanently.

The important thing about this failure is that conventional monitoring does not catch it. An uptime check that pings the homepage will report a flawless month throughout the entire outage, because the homepage was never down. Catching it requires submitting a real test entry on a schedule and then asserting that it arrived where it was supposed to arrive, in the inbox and in the CRM. That is a different kind of check, and it is the one most plans omit.

Things expire whether or not you are looking

A modern site depends on a surprising number of items that have expiry dates attached. The TLS certificate, which usually renews automatically right up until a validation path changes and it silently stops. The domain registration itself. API keys and tokens for payments, maps, email delivery, calendars and analytics, some of which expire on a fixed date rather than when they are revoked. Access tokens for any social or advertising integration. Free tiers of third party scripts that convert to paid or simply stop serving.

The control here is almost embarrassingly cheap: a dated inventory of every credential, integration and registration, with an expiry date and a named owner, reviewed on a schedule. Most organizations do not have one, which is why these outages feel like surprises when they are in fact calendar events that nobody put on a calendar.

Updates, and the two opposite ways to get them wrong

Whether you are on a content management system with plugins or a custom build with a package tree, the underlying software keeps moving. There are two failure modes and they pull in opposite directions.

The first is never updating anything, on the reasonable theory that a working site should not be disturbed. The result is an accumulation of publicly documented vulnerabilities in components that anyone can identify from the outside, plus an eventual upgrade that is so far behind it has to be done all at once and breaks everything.

The second is updating everything automatically in production, on the equally reasonable theory that staying current is safer. The result is that a minor release changes some markup and breaks your layout at ten on a Saturday morning, with nobody watching.

The workable middle is boring and effective. Security patches go on promptly. Feature updates go on a schedule. Both get applied to a staging copy first, where someone looks at the pages that matter. And there is a rollback path that has actually been exercised at least once, rather than one that exists in principle.

A backup you have never restored is not a backup

Nightly backups that have run faithfully for two years and have never once been restored are a common finding, and they fail in predictable ways when they are finally needed. The database dump turns out to be partial. The uploads directory was excluded from the job because it was large. The backup is stored on the same server that just failed. Nobody has credentials to the backup service because the person who set it up has left.

Restore testing is the fix, and it means restoring into a scratch environment, confirming the site comes up with real content, and timing how long it took. The number you measure is your actual recovery time. The number in the proposal is a hope. Quarterly is a reasonable cadence for most small businesses.

One related hazard worth naming, because it catches people repeatedly: a deployment process that synchronizes a build directory with deletion enabled will cheerfully remove user uploaded files that only ever existed on the server and were never in the repository. The deployment reports success. The images are gone. If your site accepts uploads of any kind, that exclusion needs to be explicit in the deploy configuration.

Performance and content both drift downward

Sites get slower by accretion rather than by any single event. Someone uploads a photograph straight from a camera at full resolution. A new tracking script is added for a campaign and never removed. A font is added, then a chat widget, then a review badge. Each addition is defensible and small. The sum is a page that takes noticeably longer to become usable than it did at launch, measured on the device that matters, which is a mid range phone on a cellular connection rather than the fast desktop in your office.

Content drifts in the same quiet way. Year references go stale. Services you no longer offer are still listed. Staff who left are still on the team page. A holiday hours banner is still up in March. Internal links point at URLs that stopped existing during a redesign, which frustrates buyers and wastes crawl budget at the same time.

The measurement layer deserves its own mention, because it fails invisibly and corrupts decisions. A redesign drops the analytics tag from a template, or installs it twice, and conversions either stop being recorded or start being double counted. Budget decisions then get made on a broken number for months. Verifying that analytics and conversion tracking still fire correctly belongs in maintenance, not only in the launch checklist.

Automating the watch

Every check described above is small, boring and perfectly suited to software. No human being is going to submit a test lead every morning for eighteen months. An agent will, without complaint, and that is precisely the kind of work we deploy agent teams to carry.

In practice that means scheduled synthetic transactions that complete a real business outcome, submitting the form, running through a booking, starting a checkout, and verifying the result arrived rather than only confirming the server returned a success code. Expiry monitors on certificates, domains and credentials with enough lead time to act. A weekly crawl that compares titles, canonical tags, indexable status and internal links against the previous week and reports only what changed, so the signal is a short list rather than a report nobody opens. Dependency monitoring that raises a task when an advisory affects something you genuinely run. Performance budgets that flag a regression when it appears, while it is still one script rather than six.

There is an honest limit to all of this. Alerting that nobody reads is functionally identical to no alerting at all. The routing matters as much as the detection: alerts need to reach a person with the authority to act, and they need to say what broke and what to do about it. We build that part deliberately, and it is usually the difference between monitoring that works and monitoring that becomes background noise within a month.

What a maintenance plan should actually specify

When you are comparing proposals, look for specifics rather than categories. What exactly is monitored, and at what frequency. Whether monitoring covers business outcomes such as form delivery and booking completion, or only server uptime. The patch policy, including who decides and what the window is. Backup frequency, retention period, and how often restores are tested. Different response commitments for a site that is down versus a cosmetic issue. How many content change hours are included and what counts against them. Who owns the domain, the DNS and the hosting account, which should always be you. And, importantly, what is explicitly excluded.

A plan that lists only updates and backups, with no outcome monitoring and no restore testing, is covering the two cheapest items and leaving the expensive failure modes entirely uncovered. That is the plan most small businesses are sold.

We handle this work for businesses across New Jersey and New York as part of how we run sites after launch, alongside the hosting and ongoing site maintenance itself and whatever the original website design and development work was. If you are not certain your forms are still delivering, send us the address of your contact page and we will run a live submission test and tell you what arrives and what does not. It is a short answer, and for a surprising number of sites it is not the answer the owner expects.