How Do You Build a Website That Still Works in Ten Years?

How Do You Build a Website That Still Works in Ten Years?

You put as little as possible between your content and the browser. The web platform itself is extraordinarily stable. Almost everything that rots on a website is something a team added on top of it: a build pipeline, a framework major version, a service that got acquired, a runtime that went end of life.

This is an opinion piece, and it is one we hold strongly after too many rescue projects. Sites do not decay because HTML changed. They decay because the scaffolding around the HTML needed constant attention that nobody budgeted for.

Here is what we actually believe about longevity, including the part where it is sometimes the wrong goal.

Why Do Websites Rot When Nobody Touches Them?

Because "nobody touches them" is false. Something touches them constantly. Browsers update, certificates expire, a package publishes a security advisory, a hosting provider deprecates a runtime, an API you call changes its response shape. Standing still is not an available option.

The useful way to think about it is maintenance surface. Every dependency, integration and build step is a surface that someone else can change under you. A site with three surfaces needs attention three times. A site with sixty needs attention sixty times.

Most teams never count theirs. They inherit a stack, ship the site, and discover the surface area the first time a build fails for reasons nobody can explain. Our piece on dependency updates on a marketing site covers the ongoing cost of that surface.

Does the Web Platform Itself Break?

Almost never, and that is by design rather than luck. The W3C's HTML Design Principles document, a Working Draft dated 26 November 2007, opens its compatibility section with Support Existing Content: processing requirements should be specified to ensure that user agents implementing the specification will be able to handle most existing content.

The principle next to it is Degrade Gracefully, which says conformance requirements should be designed so that web content can degrade gracefully in older or less capable user agents. Alongside those sit Do Not Reinvent the Wheel, Pave the Cowpaths and Evolution Not Revolution.

Read that list and the conclusion is hard to avoid. The people who design the web have spent decades prioritising not breaking what already exists. A plain HTML page written in 2007 still renders today, and there is no serious reason to expect that to change.

So when a site built five years ago no longer works, the platform is rarely the culprit. Something above it is.

How Long Does a Dependency Actually Last?

Less time than a website. Node.js publishes its own schedule, and it is a useful reference point because so many build pipelines sit on it. A major version is Current for six months, and the project's guarantee is that critical bugs will be fixed for a total of about 30 months across the LTS phases.

Node's own guidance is that production applications should only use Active LTS or Maintenance LTS releases. Two and a half years is a responsible, well-run support window. It is also a quarter of the decade we are talking about.

That arithmetic is the whole argument. If your site cannot render without a build step, you have signed up to migrate that build step roughly four times over ten years, and each migration is an opportunity for something to break that nobody notices for weeks.

None of this is a criticism of Node. It is a criticism of assuming the tooling lifecycle and the website lifecycle are the same length. They are not, and nobody plans for the gap.

When Is a Feature Safe to Rely On?

Baseline gives you a defensible answer, which is a genuine improvement on arguing about it. MDN documents that a feature is Widely available when it has a consistent history of support in each of the Baseline browsers for at least 2.5 years.

Newly available means something narrower: the feature works in at least the latest stable version of each Baseline browser, but may not work with older browsers and devices. The Baseline browsers are Safari on iOS and macOS, Chrome on Android and desktop, Edge on desktop, and Firefox on Android and desktop.

Our rule for a site we expect to leave alone is to build the structure on Widely available features and treat Newly available ones as enhancements that can fail silently. That is not conservatism for its own sake. It is matching the risk to how often anyone will be watching.

We go into the mechanics of this in our guide to Baseline web features. The short version is that Baseline turns a judgement call into a date.

What Does a Ten Year Site Look Like?

Boring, in the specific way that good infrastructure is boring. Semantic HTML carrying the content and the structure. CSS doing the layout with widely supported features. JavaScript for enhancements that the page survives without. Assets on your own domain. No build step required to serve a page.

That last point is the one people argue with, so let us be precise. You can absolutely use a build step to produce the site. What matters is whether the output can be served without one. A folder of HTML, CSS and images is a format that will still be servable in 2036. A running application is not the same promise.

This is the same argument as progressive enhancement, just extended along the time axis instead of the capability axis.

Is a Framework a Liability?

Not inherently, and we use them. A framework is a liability when its major version upgrades are the only reason your site needs engineering attention. That is a real pattern and it is worth naming rather than pretending otherwise.

The honest trade is this. A framework buys you speed of development and a shared vocabulary for the team. It costs you a dependency on someone else's upgrade cadence for as long as the site lives. If the site will be rebuilt in three years anyway, that is a fine trade. If the site is meant to outlast the team, it is a worse one.

What we would avoid in a site meant to last is a framework doing work that the platform already does. Client-side routing on a marketing site is the clearest example: it replaces something browsers have done reliably for thirty years with something you now own.

The related failure is scope. Our piece on over-engineering marketing sites covers how ambition at build time becomes maintenance later.

What About the Content Management System?

This is the dependency people forget, and it is usually the largest. A CMS holds your content in its own shape, behind its own API, on its own pricing model. Ten years is long enough for any of those three to change in ways you would not choose.

The protection is not avoiding a CMS. It is being able to leave one. Can you export every field of every entry in a format you can read without the vendor? If the answer requires a support ticket, you do not have an exit, you have an intention.

We would test that export on day one rather than assuming it. An export that exists in the documentation and an export that produces usable content are different things, and the gap is only visible when you actually run it.

The same applies to images and files. Assets living only inside a vendor's media library are content you do not fully control.

What Keeps Breaking That Nobody Plans For?

Four things, in our experience, and none of them are code. Domain and certificate renewals attached to a personal account. Third-party embeds whose provider changed or disappeared. Forms routing to an address nobody reads any more. And analytics or tag managers configured by someone who left.

What these have in common is ownership, not technology. They break because the human attached to them moved on, and no system noticed. That is why we treat an ownership register as part of a build rather than as paperwork.

The cheapest durability measure available to most teams is not architectural. It is putting every account in a shared organisation, with billing on a company card, and a calendar reminder to check it once a year.

Is Any of This Worth It?

Sometimes not, and we should say so plainly. A startup that expects to reposition twice in three years should not optimise for a decade. Their site is a hypothesis, and hypotheses should be cheap to replace. Building for longevity there is a way of spending money on the wrong axis.

Longevity earns its cost when the content has lasting value, when the audience arrives through search rather than campaigns, or when the organisation genuinely cannot fund continuous maintenance. Documentation, reference material, institutional sites and long-lived marketing content all qualify.

Most redesigns are not triggered by technology anyway. They are triggered by a change in strategy, and no amount of architectural discipline prevents that. Our piece on why website redesigns fail covers the difference.

Where Would We Start?

Count your maintenance surface before you change anything. List every dependency, integration, third-party script and account the site relies on, and write a name next to each. Most teams have never seen that list, and half the durability problem is visible the moment it exists.

Then ask one question of each item: what happens to the site if this stops being maintained. The ones with no good answer are where the next five years of unplanned work will come from.

If you want help auditing a site's real dependencies, or building one designed to survive a decade of light attention, we are happy to walk through it. You can find us at phoenix.studio.