Website maintenance and management

What does continuous monitoring mean?

A monitoring system I built myself. An external monitor checks availability every five minutes; everything else is checked by the system every morning, on every site I look after. What it looks at, in plain terms:

• Is the site up. If it goes down, I get an alert within minutes.
• Is anything about to expire. It warns before the certificate or the domain expires, while there is still time to renew.
• Is the system up to date. On a WordPress site: the core, the theme and the plugin versions — and whether a plugin has been pulled from the WordPress directory or abandoned by its developer.
• Is anyone there who should not be. A new admin account, the most common trace of a break-in; unknown code; a secret key left in the page source.
• Does it look the way it did yesterday. The appearance is measured against a recorded state, so if an element slips out of place or disappears, it shows before a visitor mentions it.
• Can search engines find it. An accidental “do not index” flag, a dead link, an image that does not load.
• Is the backup sound. It is made daily, a copy goes to a separate place, and the system also checks that it contains data — by its size, an empty backup looks just like a good one.
• Does your email arrive. The email authentication of the site's domain, so your messages do not land in spam and nobody else can send in your name.

I handle alerts on working days; I do not offer on-call support. The monitoring is there so that a fault does not come to light through your visitors, or weeks later. A hacked site can hide from its owner, of all people.

Why can't updates wait?

In 2025, 11,334 new vulnerabilities were found around WordPress, and nine in ten of them were in plugins. Half of the mass-exploited flaws came under attack within five hours of being disclosed — as measured by Patchstack's annual report.

In April 2026 CERT-EU, the cybersecurity service of the EU institutions, wrote that an AI model had found thousands of serious vulnerabilities on its own, and in a number of cases wrote a working exploit as well. Finding flaws has become cheaper — including for those who do not intend to fix them. I have written separately about what this changes for a small business website, and what it does not.

That is why I update on a schedule, and why every new site I build runs on its own theme with as few plugins as possible. Where no plugin goes in, nine in ten flaws never reach.

Why does a website break when nobody touches it?

A website does not stand on its own. It runs on a server that the hosting provider migrates to new software from time to time, it appears in browsers that update several times a year, and it is usually built from components that their makers keep developing. What works flawlessly today does not keep working on its own — the ground moves underneath it.

In this article I describe what breaks on a site left to itself, what the work I do under the name maintenance looks like, and when each arrangement is worth it.

What breaks on its own?

The most common faults do not start inside the site — they come from the environment changing. A few typical cases, the way the owner runs into them:

• The hosting switches to a new PHP version, and what remains in place of the site is a white screen — or an error message, in front of visitors.
• Two plugins clash after an update, and the contact form stops delivering messages. Visitors do not report this, they simply look elsewhere.
• The security certificate expires, and the browser shows a red warning instead of the page.
• The site gets hacked through a long-known security hole, and then sends spam or redirects to another site.
• Bots find the contact form, and machine-sent messages flood the inbox.

These are not rare, dramatic outages — they are slow wear. Most of it happens quietly, the owner notices weeks later, or not at all: the enquiries just dry up.

What does running a website mean in practice?

Running a website is four things for me: updates, backups, fixes and small changes. Updates keep the system and the plugins current before the gap turns into a fault. Backups exist so there is something to fall back on when a change does break something — without a backup, a fault can be final. Fixes and small changes are the everyday reality: a stuck form, a new price list, a photo to replace.

This does not mean daily attention. The owner writes when something is needed, and the background work runs on a schedule — in most months, unnoticed. Upkeep at its best is boring: it is the state where there is nothing to talk about.

When is a retainer worth it, and when is ad hoc enough?

The monthly arrangement is worth it where the site changes regularly, or where downtime is directly lost revenue — booking, payment or orders run on it. In that case maintenance is not an occasional repair but continuous oversight, and the monthly fee covers that readiness.

For a small, rarely changing brochure site, ad hoc work is defensible too: once or twice a year, an assessment, updates, a backup. The difference is that between those visits nobody is watching the site — that trade-off is worth making knowingly, not by accident.

Can a site built by someone else be taken over?

It can, and a large share of maintenance enquiries are exactly that: the site was built at some point, and its maker has since become unreachable, or the relationship ended. A takeover needs two things — access to the hosting and to the admin interface.

With me, a takeover starts with an assessment: I look at what runs under the site, what state its components are in, and I write down what I found. That is also where it turns out how much has been missed and what is urgent. After the assessment, the owner decides — and the write-up stays with them even if there is no follow-up.

How I do it in practice

For me, updating is not the “update all” button. A backup comes first, and after the update I walk through the site's key points — form, payment, booking, whatever matters on that particular site. If an update looks risky, I try it on a copy first. That order comes from experience: on a live site, even the smallest change can have consequences — one of my case studies describes what happened when that safety net was missing.

With backups, what counts is restorability, not the fact of the backup. It goes to a separate location, not onto the hosting it is meant to protect, and from time to time I test it — a backup is only worth anything if it can actually be restored.

What does this look like live? Among my projects, the case study about a holiday rental's website is the closest to this page: it is about what happened to a site in the years after handover.

Questions on this topic

← Back to the home page