Most websites follow the same four stages: build, launch, ignore, panic.
The panic arrives somewhere around year three, usually triggered by a complaint about speed, a failed security scan or a competitor’s redesign. By then the site has accumulated enough plugins, tags and half-finished campaigns that fixing it feels harder than starting again, so somebody commissions a rebuild and the cycle repeats.
The website lifecycle is the alternative: treating the site as something that is run rather than something that is delivered. It is less exciting and considerably cheaper.
Website Lifecycle: Plan, Build, Maintain and Retire Well
Planning: decide the constraints while they are free
Two decisions belong here and almost nowhere else.
Set a page weight budget before design begins. Agreed at this point, it is a constraint that shapes what gets designed. Introduced later, it becomes a negotiation, and the answer is always that this particular element is the exception.
Make accessibility a requirement in the brief rather than a review at the end. Building to WCAG 2.1 Level AA from the start costs a fraction of retrofitting it, because retrofitting touches markup, components and content simultaneously.
Also decide what the site does not need to do. The clearest saving available is a feature nobody builds.
Building: ship what the pages use
Efficient delivery is mostly restraint rather than technique. Images at display dimensions in modern formats. Fonts subset and limited. Code that ships what the page needs rather than what the framework includes.
Prefer the platform where it will do the job. Semantic HTML gives assistive technology what it needs by default and removes the need for scripts rebuilding behaviour browsers already provide.
Take a baseline before launch: page weight, request count and Core Web Vitals under stated conditions. Everything afterwards is measured against it, and a site launched without a baseline can never demonstrate that it has stayed lean.
Running: this is where sites are lost
Digital Drift is the gradual divergence between what a site was built to be and what it has become. Nobody decides it. It accrues.
An image uploaded straight from a phone camera. A tag added for a campaign that ended in March. A plugin installed to solve a problem that has since gone away. A landing page for an offer nobody withdrew.
Three controls hold it back. Give editors guidance on image sizes and embeds, since most regression arrives through the CMS rather than the codebase. Require new third-party tools to state a purpose, an owner and a review date. And measure quarterly against your baseline, because drift is invisible until you compare.
Where performance and environmental impact both apply, treat them as the same lever: reducing unnecessary data transfer and processing supports a faster experience while lowering estimated digital carbon, though those environmental figures remain modelled rather than directly measured.
Reviewing: prune rather than rebuild
An annual content review is cheaper than a rebuild and usually more effective.
Archive expired campaigns. Consolidate pages that say the same thing three ways. Remove features nobody uses, checking accessibility and record-keeping needs before you do. Check the third-party list against the owners you assigned.
Hosting belongs in the review too. Renewable-powered hosting changes the emissions profile of the server portion, which is genuine and partial, since network transfer and the visitor’s device are governed by what your pages send. Verify what a provider’s claim actually covers rather than accepting a badge.
Retiring: the stage nobody plans
Sites and sections do reach the end of their usefulness, and handling that badly costs more than handling it well.
Preserve useful URLs with redirects so accumulated links and search visibility are not discarded. Communicate material changes rather than letting people discover them. Remove the dependencies, credentials, scheduled jobs and supplier access that sat behind the retired feature, and confirm retention obligations with a qualified adviser where they are unclear.
The W3C Web Sustainability Guidelines cover practices across the full span rather than the build alone.
What this changes commercially
A site that is maintained tends to last longer before a rebuild is genuinely necessary, and rebuilds are the largest cost in the cycle. It also stays faster and more accessible in the meantime, rather than degrading quietly until somebody notices.
Our sustainable web development work is structured around the whole website lifecycle rather than the launch.