Skip to content

Build / Maintenance and Support

Websites Do Not Hold Their Value on Their Own

Monitoring, security patching, tested backups, performance governance and content velocity, delivered as a retainer that protects the asset you have already paid to build.
Where this sits

Monitoring, patching, backups and performance governance for an asset you already paid to build.

In the system
  1. Brand
  2. Website
  3. SEO
  4. Traffic
  5. Conversion
  6. Leads
Start a project

A website is the only significant business asset routinely expected to hold its value with no upkeep. Buildings get maintained, vehicles get serviced, software gets patched, and websites get left alone until something visibly breaks. By then the failure is rarely a single event. It is the accumulation of six quiet ones that nobody was watching for.

Decay is gradual and mostly invisible from the inside. Dependencies fall behind their security releases. Images uploaded at full resolution slow pages down month by month. Tracking tags multiply. Broken links accumulate as other sites reorganize. Competitors publish while your content stays where it was at launch, and rankings drift without any single day where something went wrong.

Maintenance is not insurance against disaster. It is the operating cost of keeping a revenue-generating asset in the condition you paid for. The alternative is not saving money. It is deferring an unpredictable cost, usually into the month when a security incident, a broken checkout or a ranking collapse gives you no choice at all about the timing.

What You Are Actually Buying

The value of maintenance is measured in problems that never became incidents, which is why it is easy to undervalue and expensive to skip.

  • Continuity You Do Not Have to Think AboutThe site stays available, current and monitored, and someone other than you is accountable for it. The attention that used to go into chasing website problems goes back into running the business.
  • Risk Moved Off the TableKnown vulnerabilities get patched, backups are tested, and recovery expectations are documented. The scenarios that turn into expensive weeks are the ones nobody prepared for, and preparation is considerably cheaper than recovery.
  • Performance and Rankings That HoldSpeed and search health are governed continuously instead of rediscovered during the next redesign. The investment already made in the build keeps returning rather than eroding a little every quarter.
  • A Site That Keeps Pace With the BusinessNew pages, offers and content ship on a predictable cadence. The website reflects what you sell now, which is the difference between a live marketing asset and an expensive brochure.

The problem

What Happens to an Unmaintained Site

01

Security Debt Accumulates Silently

Every dependency, plugin and framework in your stack publishes security fixes. Skipping them does not preserve stability; it accumulates known, publicly documented vulnerabilities that automated scanners find faster than people do. The recovery cost of a compromised site includes cleanup, downtime, potential data notification obligations and the search suppression that follows a malware flag.

02

Performance Regresses After Launch

Sites are fastest on launch day. Then a marketing tag is added, a large hero image is uploaded uncompressed, an embedded widget pulls in third-party scripts, and a page that met Core Web Vitals thresholds no longer does. Nobody notices, because each change is incremental and nobody is measuring field data against a performance budget.

03

Content Stops Moving and Rankings Follow

Search results reward pages that stay accurate and useful. A site that has not published or updated anything in a year competes against businesses shipping content weekly. Stale service pages, outdated pricing, dead case studies and unanswered questions all reduce the reasons for a search engine, or an AI assistant, to keep citing you.

04

Nobody Knows Whether the Backups Work

Most sites have backups. Far fewer have backups that have ever been restored, stored somewhere separate from the server they protect, and retained long enough to recover from a problem discovered three weeks late. A backup nobody has tested is a belief rather than a control, and the test always happens at the worst possible moment.

Scope

What the Retainer Covers

Cover is scoped to the platform and the stakes, from a monitored brochure site to a store where an hour of downtime has a measurable price.

Uptime, Error and Certificate Monitoring

Continuous availability checks, error reporting and SSL certificate expiry alerts with a defined response path. You find out from us, not from a customer who could not reach the site or from a browser warning that appeared over a weekend.

Security Patching and Dependency Management

Scheduled review and application of framework, dependency, plugin and server updates, tested on a staging environment before they reach production. Vulnerability advisories relevant to your stack are triaged by severity, with urgent fixes handled outside the normal cycle.

Tested Backups and a Documented Recovery Path

Automated backups of files and database on a retention schedule matched to your risk, stored off the production server, with periodic restore tests. Recovery time and recovery point expectations are written down before the day you need them.

Performance Governance

Regular Core Web Vitals field data review, image and asset auditing, third-party script review and regression checks after content changes. Performance budgets are enforced continuously, so the site does not gradually return to where it was before the rebuild.

Content Updates and Publishing Support

A defined allocation for content changes, new pages, campaign landing pages and seasonal updates, handled by people who already know the design system. Requests are turned around in a predictable window rather than queued behind unrelated project work.

Technical SEO Health Checks

Crawl and index coverage monitoring, broken link and redirect auditing, structured data validation, sitemap accuracy and Search Console error triage. Technical problems get caught in the reporting cycle rather than after the traffic has already gone.

Reporting and a Roadmap, Not Just a Log

A monthly summary of what changed, what was found, what it means and what we recommend next, written in business terms. Maintenance should surface opportunities to improve the asset, not only evidence that nothing broke this month.

How we work

How the Retainer Works

  1. 01

    Baseline Audit

    We document what exists: stack, dependencies, hosting, integrations, current performance field data, indexation health, backup configuration and known risks. This establishes the reference point everything is measured against, and it usually surfaces two or three issues worth fixing immediately. The audit stands on its own, even if the retainer never starts.

  2. 02

    Stabilise

    Before ongoing cover begins we clear the backlog that would otherwise distort the service: outstanding critical updates, failing backups, broken redirects, missing monitoring and the performance regressions already present. Starting from a known-good state is what makes everything after it predictable.

  3. 03

    Operate on a Cycle

    Monitoring runs continuously. Patching, backup verification, performance review, link checks and index checks follow a defined schedule with staging tests before any production change. Emergencies have a separate response path, so routine work is never the reason an urgent fix waits.

  4. 04

    Report in Business Terms

    Each cycle produces a plain summary: what was updated, what was found, which risk was removed and what changed in performance and search health. No screenshots of dashboards without interpretation, because a report nobody can act on is a cost with no return attached.

  5. 05

    Improve, Not Just Preserve

    Maintenance identifies what the site should do next: pages attracting traffic but no enquiries, content that has aged out of accuracy, templates worth extending, integrations worth adding. The retainer becomes a continuous improvement loop rather than a standing charge for keeping the lights on.

Security Patching, Dependency Risk and the Cost of Doing Nothing

Modern websites are assembled from dozens of third-party components, each maintained by someone else on their own release schedule. When a vulnerability is disclosed the details become public, which means the window between a fix being published and automated exploitation attempts beginning is short. Not applying the patch is a decision to stay exposed for as long as the site is live, and it is a decision most businesses make by default rather than deliberately.

The recovery cost is what makes this a financial question rather than a technical one. A compromised site can mean downtime during trading hours, cleanup and forensic work, a search engine malware flag that removes you from results until review, notification obligations if customer data was involved, and the reputational damage of a browser warning shown to anyone who tries to visit. Scheduled patching against a staging environment costs a fraction of any one of those.

Discipline matters more than frequency. Updates are reviewed for severity, tested before production, and applied in batches small enough to identify the cause when something breaks. Dependencies abandoned upstream get replaced rather than pinned indefinitely, which is also why our web development practice keeps the dependency count deliberately low. Fewer moving parts remains the cheapest security control available to any business. Nothing you never installed can be exploited, and nothing removed needs patching.

Why Set-and-Forget Websites Lose Rankings

Search rankings are relative. A page does not need to get worse to fall; the pages around it only need to get better. A competitor who publishes, updates and expands their coverage while your site stays static will eventually pass you, and the decline is gradual enough that it is usually noticed a year after it started, when someone finally asks why enquiries are down. By that point the recovery costs considerably more than the upkeep would have.

Technical drift contributes as much as content stagnation. Redirect chains build up as pages move. External links rot as other sites reorganize. Structured data breaks when a template changes. Uploaded images bloat page weight until Core Web Vitals thresholds are missed on mobile. Individually none of these is urgent. Together they signal a site that is not being looked after, and they make crawling and indexing less efficient than they should be.

This is why maintenance and SEO overlap more than most retainers admit. Crawl coverage monitoring, structured data validation, redirect hygiene and page speed governance are maintenance tasks with direct search consequences. Keeping content current is an editorial task with the same effect. A retainer covering both keeps the asset in the condition the original investment assumed, and gives the local SEO and content work something stable to build on. Otherwise the growth budget pays to repair what upkeep should have prevented.

Retainer Economics: Predictable Cost Against Unpredictable Failure

The argument against a retainer is that nothing appears to happen. That is precisely what is being purchased. Maintenance converts an unpredictable and occasionally severe cost into a small, budgeted, predictable one, in the same way any other operational control does. The businesses that resist it are usually the ones that have not yet had the incident that reframes the calculation permanently. A premium always looks expensive right up until the claim.

There is also a compounding argument. A maintained site accumulates value: content builds authority, performance stays within budget, the web design system gets extended, conversion optimization has a stable base to test against, integrations get added, and the technical foundation stays current enough that the next significant change is an enhancement rather than a rebuild. An unmaintained site accumulates the opposite, and the eventual rebuild gets priced accordingly by whoever inherits it. Two sites of identical age can differ by an entire project in replacement cost.

The most useful framing we have found with finance teams is replacement cost. Take what the site cost to build, add what it currently generates in enquiries or orders, and compare that against an annual maintenance figure. The ratio usually makes the decision obvious, and it tends to reveal that the website is the least protected significant asset the business owns. Most companies insure vehicles worth a fraction of what the site produces.

FAQ

Website Maintenance & Support questions, answered

The questions we get asked before every engagement of this type.

What is included in a website maintenance retainer?

Monitoring, security patching, backups with restore testing, performance governance, technical SEO health checks, content updates and monthly reporting. The specific allocation depends on the platform and how much the site matters commercially. A store processing orders needs faster response commitments and tighter change control than a brochure site, so the retainer is scoped against that rather than sold as a single fixed package.

Do we need maintenance if our site is brand new?

Yes, and a new site is the cheapest possible point to start. Dependencies begin aging the day the site launches, and performance regression usually starts within the first few months as tags, images and content are added. Beginning maintenance at launch means the site is preserved from a known-good state, which is far less work than restoring one after two years of unmanaged change.

Can you maintain a site your team did not build?

Yes, starting with a baseline audit of the stack, dependencies, hosting, backups, integrations and current performance and indexation health. That audit tells us what needs stabilising before ongoing cover makes sense, and it is honest about anything we consider unmaintainable. Occasionally the responsible recommendation is a rebuild, and we would rather say so at the audit stage than bill monthly to hold something together.

How quickly do you respond when something breaks?

Urgent issues follow a separate response path from routine work, with response times agreed in the retainer rather than left implied. Site-down and checkout-failure scenarios are treated as immediate. Because monitoring runs continuously, we typically detect availability and certificate problems before anyone reports them. Non-urgent requests are turned around within a defined window so your team can plan around it.

Who owns the backups and the hosting?

You do. Backups are stored on infrastructure you control or in an account in your name, separate from the production server, and hosting remains under your ownership throughout. We document credentials, retention schedules and the recovery procedure so the arrangement never depends on us being available. Maintenance should reduce your dependency risk, not concentrate it in a single supplier.

Does maintenance include new features or new pages?

Content updates and new pages built from the existing design system are typically included within an agreed allocation. Substantial new functionality, integrations or template work is scoped separately, because that is development rather than upkeep. We keep the boundary explicit so the retainer does not quietly become an under-resourced development contract, which is how maintenance quality degrades in most agency relationships.

Protect What You Already Paid For

Give us access and we will run a baseline audit: what is out of date, what is exposed, what has regressed since launch, and what it costs to keep the site in the condition you bought.

No obligation · We will tell you if we are not the right fit