Someone should be watching your site.

Four things, and you should expect all four rather than the first two. Security: patching on a defined clock, hardening, malware scanning and a written response plan. Reliability: off-site backups with rehearsed restores, plus monitoring of uptime, certificates, DNS and the business journeys that earn money. Technical health: a monthly crawl for broken links, redirect chains, indexation drift, schema and vitals per template. And improvement: included development hours spent on making the site better. If a plan offers only updates and a backup, it is a hosting add-on rather than maintenance.

Automatic updates are useful and they are not a plan. They apply changes without checking that your particular combination of theme, plugins and custom code still works afterwards, which is how a Saturday outage happens. They also do nothing about abandoned components, and that gap is the real exposure: Patchstack reported 91% of 2025's WordPress ecosystem vulnerabilities in plugins and 46% of them still without a vendor fix at disclosure. Someone has to decide what to replace, test what to ship, and own the outcome. That decision is the service.

On a clock that matches severity. Anything actively exploited or rated critical is treated as an incident and shipped the same day, with a staging check where the code allows and a virtual patch at the firewall where it does not. Routine security releases go through the normal weekly cycle: staging copy, visual and functional checks on the pages that matter, then production with a rollback ready. Feature updates that carry no security weight can wait for the monthly window, because an unnecessary change on a Friday is its own risk.

You reach a named engineer who already has your runbook, and the plan is written before the day it is needed. For an outage: confirm the fault, get the site serving again from cache or a restore, then diagnose properly rather than in a panic. For a compromise: isolate, take a forensic copy, clean or rebuild from a known-good backup, rotate every credential, patch the entry point, then request review where search or browser warnings are involved. Afterwards you get a written account of what happened and what we changed so it cannot repeat.

Yes, and we separate the two honestly. Onboarding always includes remediation: outstanding patches, abandoned components, broken forms, redirect chains, missing monitoring. That is part of taking a site over properly rather than an upsell. Where the underlying build is the problem — a page builder emitting megabytes of markup, a theme with a decade of layers, an integration held together by hand — we scope it as a project with a price, whether that is a redesign, speed engineering or a custom build, and keep maintaining the current site meanwhile.

They are used, which is the important part. Each month we agree what the hours go on: a clearer enquiry form, a faster template, a campaign landing page, accessibility fixes, a content type your team keeps requesting. If a month is quiet we propose something measurable instead of leaving the time idle. Unused hours roll for one month so a bigger job can be planned across two, and we tell you plainly when a request needs more time than the plan holds, with an estimate, before we start rather than after.

Indirectly and reliably. Search does not reward maintenance as such, but it punishes what happens without it: pages that disappear behind a stray noindex, redirect chains left from an old campaign, sitemaps that stop regenerating, templates that slow down until they fail their vitals. Google's own guidance on why site traffic drops is largely a list of maintenance events. Keeping those clean protects the rankings you already earned; growing them is a different job, which is what our SEO team does.

It depends on two things: how complex the build is and how much included development time you want. A brochure website with a handful of components and no integrations is a modest monthly fee covering patching, backups, monitoring and a health pass. A store or a website with CRM, payment and feed integrations costs more because more can break and the checks are daily. Plans with meaningful improvement hours cost more again and usually return the most. We quote a fixed monthly figure after the audit, with response times written into it — never an hourly rate you find out about after an incident.

Yes, and it is a common split. Your developer keeps the product work and the roadmap; we take the parts that are easy to postpone and expensive to postpone — patch cycles, backups and restore drills, monitoring, the monthly health pass, out-of-hours cover. Everything we do lands in your repository through your review process and is written into the shared runbook, so nothing depends on us being available. Where a website is complex we hold a short monthly session with your developer so priorities do not collide.

Ask what the plan measures, not what it lists. Four questions sort the market fast. How quickly are critical security releases applied, and is that written into the agreement? When was the last restore rehearsed, and how long did it take? What exactly is monitored — uptime only, or the forms and checkout that earn the money? And how many development hours are included, with who deciding what they go on? Cheap plans usually mean automatic updates and a backup nobody has tested, which is hosting with a nicer name. Whichever agency you choose, insist that hosting and every account stay in your business's name.

You can, and it should be uneventful. Plans run monthly after the first term, the hosting and every account stay in your name throughout, and the runbook — credentials, component inventory, monitoring configuration, restore procedure, change log — is maintained as a deliverable rather than as our private notes. On the way out we hold a handover call with whoever takes over and answer their questions afterwards. We would rather be kept because the reports are useful than because leaving is difficult.