What website maintenance actually includes, and why it matters

Website maintenance is the recurring work that keeps a live site secure, available, accurate and fast after launch: dependency and platform patching, verified backups, uptime and error monitoring, content and form checks, performance and accessibility regression testing, periodic security review, and a short report that says what actually changed. It is not an open-ended pot of hours for tweaks. It is the difference between a site that quietly keeps working and one that fails on a long weekend with nobody watching.

What ongoing maintenance actually covers

The fastest way to make maintenance real is to write down every task, its cadence and the failure it is meant to catch. Once it is on paper, two things become obvious: which tasks nobody currently owns, and which ones you have been paying for without receiving. Use the table below as a starting schedule and adjust the cadences to your risk. A brochure site for a professional practice needs less than a booking platform that takes payments.

Updates and patching, in an order that does not break the site

Updating is the task most often deferred and most often botched. Deferred because nothing visibly breaks when you skip it; botched because someone eventually clicks "update all" on a production site at 4pm. Both failure modes have the same fix: a repeatable sequence.

1. Take a fresh backup and confirm it completed, not just that the job ran.
2. Apply the updates on a staging copy that mirrors production, including PHP or Node version and server configuration.
3. Update in dependency order: platform core, then frameworks and libraries, then plugins or modules, then your own code that depends on them.
4. Walk the critical paths by hand: home, a key landing page, search, login, the main enquiry form, and checkout if you have one.
5. Re-run your automated tests and a performance check, and compare against the numbers from before the update.
6. Deploy to production in a low-traffic window, with the previous release ready to roll back.
7. Watch error rates and form submissions for the next twenty-four hours.

Critical security advisories break this rhythm and should. Patch the same day, but still on staging first, even if staging testing is only ten minutes on the paths that matter. Ten minutes of checking is cheaper than an unplanned outage.

Backups only count once you have restored one

Running the backup is the part that gets automated. Restoring it is the part that proves the automation works, and it is the part that gets skipped. Backup jobs fail quietly for mundane reasons: a database is excluded after a hosting migration, the uploads directory outgrew the archive limit, retention was set to seven days and the corruption started nine days ago, or the credentials expired and the failure email went to an inbox nobody reads.

Run a restore drill quarterly, and treat it as a timed exercise rather than a checkbox.

1. Pick a backup at random from the past month, not the newest one.
2. Restore it to a clean staging environment and start a stopwatch.
3. Confirm the database, files, uploads and configuration all arrived intact.
4. Log in, submit a test form, and load the five most important pages.
5. Record the elapsed time. That number is your real recovery time, and it belongs in your continuity plan.
6. Fix whatever was missing, then note the fix so the next drill starts from a better place.

Monitoring: uptime, errors, and the failures nobody reports

Uptime monitoring is the easy part and the least useful on its own. A site can return a perfect 200 on the home page while the contact form silently discards every submission because an SMTP credential rotated or a spam filter changed. Nobody complains, because the people affected simply assume you ignored them.

Monitor three layers. First, availability: is the site up, is the certificate valid, is DNS resolving. Second, errors: server errors, JavaScript exceptions in the browser, and failed background jobs. Third, business events: form submissions, bookings, sign-ups and payments, with an alert when the count for a period drops to zero. That third layer catches the expensive failures. If you are already tracking those events for measurement, the same instrumentation gives you the alarm for free, which is one reason analytics and conversion work and maintenance belong in the same conversation.

Alerts must reach a named person with the authority to act. An alert routed to a shared inbox is a log entry, not a warning.

Content, forms, performance and accessibility drift

Sites do not degrade all at once. They drift. A team adds a chat widget, a tag manager container, three tracking scripts and a hero video over eight months, and the page that shipped fast is now slow on a mobile connection in a rural area. Meanwhile a staff change leaves an old phone number on the contact page, a supplier retires a URL and three links go dead, and a new accordion added by a content editor cannot be operated by keyboard.

Build a monthly content pass into the schedule: crawl for broken links, check that contact details, hours and pricing pages are current, and submit a real test enquiry through every form to confirm it lands in the right inbox and CRM. Then, quarterly, run a performance and accessibility regression check against a fixed set of pages so you are comparing like with like. We hold client work to WCAG 2.2 AA, and the honest reason it needs re-checking is that accessibility is not a launch state. It is a property that new content erodes.

The most expensive website problems are not the ones that take the site down. They are the ones that leave it up and quietly stop it working.

Security review and a report you can actually read

Patching is not the whole of security. A quarterly review should ask who still has administrative access and whether they should, whether staging and development copies are password-protected and excluded from indexing, whether file permissions and API keys are scoped tightly, whether security headers and transport settings are still correct after the last hosting change, and whether any third-party integration has been abandoned but left connected. For sites handling personal information, payments or health data, add a check against the specific obligations you carry, which is where security and compliance work stops being generic advice.

Then report. A maintenance report does not need to be long, and it should not be a wall of server graphs. Four things: what was updated and why, what broke or nearly broke, what the restore drill showed, and what needs a decision from you. If a provider cannot produce that page each month, you have no evidence the work is being done.

What happens to sites that skip it

Neglect follows a predictable arc. In the first few months nothing visible happens, which is exactly why it continues. Then updates fall far enough behind that they can no longer be applied safely, because the dependencies underneath have shipped breaking changes in the meantime and there is no small step left to take. Contact forms fail and enquiries stop arriving without anyone noticing the gap. Page weight creeps up until mobile visitors leave before the page paints. Accessibility regressions accumulate into an exposure nobody planned for. Eventually something is compromised, or a hosting migration is forced, and the site cannot be moved because nobody knows what it depends on.

The recovery is almost always a rebuild, and a rebuild costs far more calendar time than the maintenance would have. The loss shows up in enquiries long before it shows up as an outage, because a page that is stale, slow or throwing errors is a weaker candidate for a search result or an AI answer than the one it is competing with.

How OlDevs helps

We have built and looked after sites and applications from Vancouver since 2014. We start by writing down the schedule for your site specifically, including what your platform and integrations actually require, then run it: patch cycles on staging, verified backups with timed restore drills, monitoring wired to a person, monthly content and form checks, quarterly performance, accessibility and security reviews, and a plain report each month. One accountable team, and you own all code, designs, accounts and IP throughout, so nothing here creates a dependency on us. If you are also planning changes, maintenance runs alongside web development work rather than competing with it, and you can see the wider set of engagements on our related services page.

If your site is running without a written maintenance schedule, or you are not sure whether your backups have ever been restored, that is the right place to start. Tell us the platform, the hosting and what the site needs to do, and we will scope the schedule for it. Request a quote, and we reply to every enquiry within one business day.