How long should a website last? Planning for five years
Why a business website should be built to last five years or more, what makes one age well or badly, and how to plan for the changes that will come.
The short answer
A business website should last five years or more, not as a monument that stays the same but as a system that evolves continuously with the business. Sites do not, and are rebuilt every two or three years, not because the business wanted a new site but because the old one could no longer be changed: a theme nobody dares update, content locked in page-builder layouts, a platform whose maintenance lapsed, no repository, a design that was never a system. What makes a site age well is the opposite of each: owned code on standard foundations, structured content separate from its presentation, a design system that can be refreshed with tokens, a pipeline with previews, dependencies kept current and a monthly routine with an owner. Plan for the changes you can foresee, new services, markets, languages and integrations, by choosing a structure that absorbs them, and the site becomes an asset that improves for five years instead of a project repeated every two.
What ages well and what ages badly
| Factor | Ages well | Ages badly |
|---|---|---|
| Code | Owned, in your repository, on standard web foundations | A theme, a builder, or a framework fork nobody understands |
| Content | Structured, separate from design, exportable | Poured into layouts; only exists as pages |
| Design | A system of tokens and components; refreshable in place | Page-by-page styling on a launch-year trend |
| Changes | Through a pipeline with previews and tests | Live edits, file transfers, or nobody dares |
| Dependencies | Updated continuously | Frozen at launch until they break |
| Ownership | Business owns accounts, code and content | Supplier owns some or all |
| Maintenance | Monthly routine with a named owner | When something breaks |
| Structure | Anticipates new services, markets, languages | Hard-coded for the launch state |
| Performance and accessibility | Guarded in the pipeline | Degrading with every addition |
Planning for five years
- Write the five-year description: services, markets, languages, integrations, audiences the site will need to serve.
- Choose the structure that absorbs those: content model, page types, language support, integration approach.
- Build on owned foundations with a design system and a pipeline.
- Set the monthly routine and name the owner on both sides.
- Schedule small improvements continuously from real data rather than saving them up.
- Plan a design refresh around year two or three.
- Review yearly against the five-year description and adjust.
What continuity looks like
The same domain, the same addresses where they still make sense, the same repository with five years of history, content that has been updated rather than rewritten, a design that was refreshed once, rankings that have compounded rather than reset, and a business that knows its site because it has been changing it all along. That is the difference between owning a website and repeatedly buying one.
What this means for you
Build a website to last five years by making it changeable: owned code on standard foundations, structured content, a design system, a pipeline, current dependencies and a monthly routine with an owner, structured for the services, markets and languages you can foresee. Refresh the design once in the middle, improve continuously, and the site compounds instead of being replaced.
Frequently asked questions
Why do so many sites get rebuilt after two or three years?
Because they were built in ways that cannot be changed: a theme nobody dares update, content poured into page-builder layouts, a platform whose maintenance lapsed, no repository, and a design that was never a system. When the business needs something new, the cost of changing exceeds the cost of starting over. A site built to be changed does not reach that point; it is updated, extended and refreshed in place.
Will the design not look dated in five years?
A design built as a system can be refreshed without a rebuild: tokens change colours and type across the site, components are restyled once, and the content and structure stay. Fashions in web design move, but a clear, fast, accessible site with good typography dates far more slowly than one built on the trend of its launch year, and what does date can be adjusted in a design refresh rather than a new project.
What should we budget for over five years?
A maintenance routine every month, small improvements continuously, a design refresh around the midpoint, and additions as the business changes: a new service line, a market, a language, an integration. That total is usually well below two rebuilds, and the site is better throughout because it never falls behind.