Keep your website updated, backed up and working

What care covers, and what it does not

Routine care keeps a working website working: platform and plugin updates, backups, hosting, SSL, domain renewals, monitoring of the parts your business depends on, and fixes to what we maintain. It is priced by what the site depends on rather than by a bank of hours, because a brochure site and a site that takes bookings carry very different work.

Just as important is what care is not. Redesigns, search programmes, new features and large content projects are separate pieces of work with their own scope and price. An arrangement that quietly absorbs them ends up rationing them later, so we keep the line clear from the start.

The table below shows how three common care tasks run, using an invented example rather than a client: a service business with an enquiry form whose messages go out through an external email service. The site owner approves content and holds the renewal access; the support lead does the checks.

What we monitor, and why

First, a list of what the site depends on

Monitoring is only as good as the list underneath it. Before a care plan starts, we write down the platform and its version, the hosting, the domain and DNS, how enquiry messages are delivered, every integration, who holds each renewal and where access is missing. For backups we confirm three things: what is actually backed up, where the evidence is kept and how a restore would be tested rather than assumed.

Signals matched to what could go wrong

We group monitoring by the decision each signal supports. Availability tells you the site is reachable. Performance tells you it is usable. An enquiry-path check tells you the form is still delivering. Security events tell you something unusual happened. Backup status tells you whether recovery is possible at all. A brochure page and a live enquiry form do not need the same set, so we size it to your site.

OWASP's logging guidance supports this approach, with the caveat that it is general application-security advice rather than a design for any one site. It says monitoring and alerting should be decided early and be proportionate to the risks, and warns that a blind checklist produces so many alarms that real problems go unnoticed.

When you compare care proposals, keep four things apart: a signal being detected, an alert reaching a named person, someone investigating it, and a promise about uptime or recovery. The first three can be scoped. The fourth is a commitment, and it belongs in writing only if someone has actually agreed to it.

How we test an update before it goes live

The routine is deliberately ordinary. We review the change, check it against the plugins, themes, integrations and custom code in use, apply it somewhere other than the live site, confirm a backup exists first, check the pages your business depends on afterwards and record what we saw. Two things pause the whole release: a backup we cannot confirm, and a failed check on a page the business relies on.

What the WordPress documentation says about updates

WordPress is still the most common platform behind the sites we are asked to take over, and its own documentation is clear. It recommends backing up the website first, so that if there are any issues you can restore it. It describes a one-click update that works for most people and a manual process for when that fails. It warns that an upgrade replaces the files in the main installation, so changes made directly to those files are lost, and that whether a one-click update can write files depends on the server's file permissions.

That is how the platform behaves, not a description of anyone's support scope. Which of those steps your provider performs, and what they are responsible for if one goes wrong, belongs in the agreement.

What happens when something breaks

The order we work in

An ordinary outage and a suspected hack start the same way, then go different directions. We identify what is affected, confirm who has authority to act, preserve anything useful as evidence and check what access and recovery evidence exists. Only then can we agree a correction, an investigation or a tested restore. If access has been lost or the backups are uncertain, the honest next step is escalation, not a promise to restore.

Why logs matter, and why they need care

How much can be learned after an incident depends on the logs. OWASP, again as general advice, says a log entry should record when, where, who and what for each event, with the action attempted and its result. It also treats logs as sensitive: passwords, keys, card data and session identifiers should be removed or masked, and access to the logs should itself be recorded. So we check what is logged, and who can read it, before anyone needs to know. Logs record what the system saw; they do not prove the cause on their own.

Which changes care includes

Sorting a request before anyone prices it

Most disagreements about support are really disagreements about what kind of request something is. So we agree the categories in advance: routine care, content changes, new features, redesign work, search work and incident response. Anything that touches an integration, permissions, a renewal or a page the business depends on gets a quick impact review and your approval, however small the technical change.

A record for every request

Each request gets a short record: what it affects, the risk, who owns it, who approved it, what evidence was asked for, whether it has been released and what happens next. Routine approvals and urgent escalations are kept apart, so you can see at a glance what care has actually done.

Before you agree a support scope, with us or anyone

Having these ready makes the first conversation short:

• The website address and the problem you want to stop having
• Who is affected when it happens
• The platform and any outside services you know it uses
• Who holds access, and who holds each renewal
• What the site has to keep doing reliably
• Any constraint, such as a budget cycle or a regulated requirement

Then ask for the scope in writing: monitoring, backup and restore, who applies updates, which changes are included, how you are kept informed, escalation and account ownership. Check ownership first. If nobody can say who controls the domain, the hosting and the email, settle that before signing with anyone, including us.