Every agency selling redesigns has a number: three years, or two, or five. None of them come from research — they come from the length of a typical agency sales cycle. A website does not degrade with age the way a roof does. It degrades when the world around it moves and it stays still, and the things that move do so on published, checkable dates: a PHP branch loses security support, an accessibility directive becomes enforceable, a ranking metric gets replaced, a browser feature becomes safe to rely on. That is what makes “is it time?” answerable instead of a matter of taste. Click through each phase below for what genuinely ages in it, what to measure, and the milestones that mark the point where repairing stops being the cheaper option.
← All resources
— Timeline
When it’s time to redesign your website, and when it really isn’t.
Nothing about a website expires after three years. Specific things age on dates you can look up — a runtime, an accessibility law, a ranking metric, a design system — and each one has a different answer. Here is what ages when, and which signals actually justify a rebuild.
What actually ages, year by year
Year 0 is launch day — or the day of your last redesign, whichever came later. Select a phase to see what ages in it, what to measure, and the milestones that fall inside it.
Years 0–1
Year one: measure, don’t touch
A site under a year old almost never needs a redesign, and the pressure to change it usually comes from inside the building rather than from the data. The only work that pays here is instrumentation: you cannot argue for or against a redesign in year three without a year-one baseline to compare against.
What actually ages
- Nothing has aged yet. The stack is current, the design is the one everyone signed off on, and the content is as fresh as it will ever be.
- What does change is your own opinion of it. Teams get bored of a design roughly eighteen months before their customers notice it exists — familiarity is not obsolescence.
- Real usage arrives and contradicts assumptions: pages nobody predicted become the most visited, and pages the team argued about for weeks get almost no traffic.
- Small structural mistakes surface — a form field that loses people, a navigation label nobody understands. These are fixes, not a redesign.
What to measure
- Capture a baseline in the first month: Core Web Vitals from field data, conversion rate by template, organic entry pages, and the share of traffic on mobile. Everything later in this timeline is measured against these four numbers.
- Track which pages actually earn traffic. A redesign argued from a page inventory beats one argued from a mood board.
- Log every “we should change this” request rather than acting on each one. A year of that list is the most honest redesign brief you will ever get.
Milestones
- Y0Launch baseline captured — vitals, conversion, entry pages, device split
- Y1First full year reviewed against that baseline
The years are a realistic band, not a rule — a well-maintained site can pass year six with nothing structural to do, and a badly-scoped one can hit rebuild territory in eighteen months. The dated items are checkable: PHP support windows, the INP transition on 12 March 2024, the European Accessibility Act from 28 June 2025 and the 30-month Baseline rule all come from the sources listed below. The phase structure and thresholds are ours, from client projects.
The signal, what it actually means, and what it costs to fix
| What you are seeing | What it usually indicates | Repair or rebuild |
|---|---|---|
| Traffic is flat, rankings are stable | A content and intent problem. The pages that exist are not the pages people are searching for. | Repair. This is a content project, and a redesign will not change the outcome. |
| Conversion fell and nothing changed on your side | Something external moved — a competitor’s offer, an ad landing page, a browser default, a price expectation. | Repair at page level. A Conversion Redesign targets the templates that lost, not the whole site. |
| Every content edit needs a developer | The CMS was modelled around the old design rather than around your content. Friction compounds daily. | Repair if the model is fixable, rebuild if the platform cannot express what you sell. |
| Your runtime is past its security-support date | A dated, checkable fact — not an opinion. It is also the cheapest item on this list to resolve. | Repair. A Website Upgrade handles this without touching the design. |
| It fails WCAG 2.1 AA and you sell to EU consumers | Legal exposure since 28 June 2025, with penalties set per member state. | Repair first. Rebuild only if the markup structure itself blocks conformance. |
| Mobile is 60%+ of traffic on a desktop-first layout | A structural mismatch between the design and the audience, not a styling preference. | Rebuild the templates. Retro-fitting responsive behaviour onto a desktop-first grid costs more than replacing it. |
| Every new page needs a new one-off template | The design system has been eaten by exceptions — Nielsen’s cohesiveness argument, in practice. | Rebuild. This is the one signal on the list that a repair genuinely cannot fix. |
Five of these seven signals resolve to repair. That ratio is the honest picture, and it is why we quote an audit before a redesign rather than the other way round.
The three-year rule is a sales cycle, not a finding
There is no study behind “redesign every two to three years”. There is no measured half-life for a website, no point at which HTML degrades, and no evidence that a four-year-old site converts worse than a one-year-old one if both are maintained. What exists is a widely repeated number that happens to match how often an agency would like to sell you a project.
The useful replacement for the rule is a question: what specifically has changed since this site was built, and does the fix for it require replacing the structure? Almost always, the honest answer to the second half is no. Content is stale, a template underperforms, a dependency is out of date, an accessibility issue needs fixing — all of that is repair work, and pricing it as a redesign is the most common way businesses overspend on their website.
Four clocks run at different speeds
Content runs fastest. Services, pricing, team, case studies and proof points drift out of date within a year or two of any real business change, and no amount of visual polish compensates for a page describing a version of the company that no longer exists.
The platform clock runs on published dates. PHP gives each branch two years of active support and one further year of security fixes, all announced in advance — 8.2 stops getting security fixes on 31 December 2026, and every branch before it is already past that point. Frameworks, CMS versions and payment APIs work the same way. None of it is a surprise, which is exactly why being caught out by it is avoidable.
The standards clock is slower but harder. Interaction to Next Paint replaced First Input Delay as a Core Web Vital on 12 March 2024, with a “good” threshold of 200 ms at the 75th percentile — a site tuned to pass the old metric did not change, but what it was being graded on did. On the browser side, a feature only counts as Baseline “widely available” 30 months after all core browsers support it, so a codebase built three years ago is carrying workarounds that are now pure weight.
The legal clock has the hardest edges of all. The European Accessibility Act has been enforceable since 28 June 2025, it is enforced against EN 301 549 which is built on WCAG 2.1 AA, and it applies to businesses outside the EU that sell to EU consumers. This is the one clock where “we will get to it next year” has a price attached that is set by a regulator rather than by you.
Upgrade beats redesign more often than anyone selling redesigns will admit
Take the seven signals in the table above. Five of them are repaired without touching the site’s structure: a content project, a template-level conversion fix, a runtime upgrade, an accessibility remediation, a CMS model correction. Only two — a desktop-first layout under mobile-majority traffic, and a design system that has been replaced by exceptions — genuinely require rebuilding, because in both cases the thing that is wrong is the structure itself.
This matters financially because the two paths are not close in price. A Website Upgrade moves a site onto a supported stack and fixes what is broken while keeping the design, the URLs and the ranking history intact. A Technical Audit is the cheaper step before either decision: it produces the version numbers, the field vitals and the conformance gaps as a list, so the redesign conversation starts from facts instead of from whoever in the meeting is most tired of the homepage.
We are a small studio, which means we do not have a redesign quota to fill. Telling a client their site needs €800 of content work rather than a five-figure rebuild costs us the bigger invoice and wins the relationship, and that trade has been worth it every time.
When a rebuild is genuinely the correct answer
The strongest argument for rebuilding is not visual and never has been. Jakob Nielsen put it precisely in 2009: incremental change is normally right, because users dislike disruption — but “in the long run, incrementalism eventually destroys cohesiveness, calling for a new UI architecture.” Every site that has been patched for five years eventually reaches the point where the patches, not the design, are what a visitor is actually using.
The second solid argument is structural: the content model cannot express what the business now sells. Adding a market, a language, a product type or a service line should be a new entry, not a workaround. When it is a workaround every time, the data model is the problem, and no amount of design work reaches it. Our multilingual architecture guide covers the version of this that bites hardest.
The third is measurable rather than architectural: cost of change is rising. If the last five requests took visibly longer than the same requests two years ago, that trend line is the rebuild argument, and it is the only one that survives contact with a finance director.
What is not a good reason: the team is bored, a competitor relaunched, or the design “feels dated” to the people who look at it every day. Those are real feelings and they are terrible briefs. If a rebuild would not move any of the four numbers you baselined in year one, it is a repaint — which is a legitimate thing to buy, as long as it is priced and justified as one.
Rebuild without throwing away what already works
A redesign that loses rankings is a self-inflicted wound, and it is common enough to be predictable: URLs change without redirects, the staging noindex ships to production, internal links point at the old structure. We wrote up the full sequence in website redesign without losing SEO, and for larger platforms the enterprise CMS migration guide covers the cutover mechanics.
Keep the evidence, replace the structure. The page inventory, the templates that convert best, the entry pages that earn organic traffic and the copy that has been tested against real customers are assets — a rebuild should inherit all of them and rewrite only what the data says is failing.
Plan the stabilisation window rather than pretending it does not exist. Real traffic finds things staging never does, and a rebuild is not finished on launch day — it is finished when the first month has passed quietly. That is what Monthly Maintenance is scoped for.
How we decide this with clients
We start with a Technical Audit because it settles the arguable half of the question in a few days: versions against end-of-life dates, field Core Web Vitals including INP, WCAG 2.1 AA conformance gaps, and a page inventory with traffic attached. Most of the “does this need a redesign” debate evaporates once those four lists exist.
If the answer is repair, a Website Upgrade covers the stack and the broken parts, and a Conversion Redesign covers the specific templates that are losing money — neither touches the URLs or the ranking history.
If the answer is rebuild, we say so and scope it against the year-one baseline rather than against a mood board. A rebuild that cannot name which numbers it is expected to move is a repaint with a bigger invoice, and we would rather lose that project than deliver it.
Sources
Every dated claim above — support calendars, metric changes, the accessibility deadline and the Baseline rule — comes from these, checked August 2026. The phase structure, thresholds and the repair-versus-rebuild split are our own, from client projects.
- PHP — Supported Versions ↗
The official support calendar: each branch gets roughly two years of active support plus one further year of security fixes. PHP 8.2 (released 8 December 2022) receives security fixes until 31 December 2026; 8.3 until 31 December 2027; 8.4 until 31 December 2028. Everything before 8.2 is already end-of-life.
- web.dev — Interaction to Next Paint becomes a Core Web Vital on March 12 ↗
Google’s own announcement that INP replaced First Input Delay as a Core Web Vital on 12 March 2024, and that FID was deprecated in the same transition.
- web.dev — Interaction to Next Paint (INP) ↗
Defines the thresholds measured at the 75th percentile: good at or below 200 ms, needs improvement between 200 ms and 500 ms, poor above 500 ms — and confirms INP as the successor metric to FID.
- EUR-Lex — Directive (EU) 2019/882 (European Accessibility Act) ↗
The directive itself. Member states have applied its measures since 28 June 2025, covering e-commerce, banking, transport and consumer digital services — including businesses outside the EU selling to EU consumers.
- web.dev — Baseline ↗
Defines “newly available” (supported across all core browsers) and “widely available” (30 months after that date). The 30-month gap is why a three-year-old codebase is usually carrying workarounds it no longer needs.
- Nielsen Norman Group — Fresh vs. Familiar: How Aggressively to Redesign ↗
Jakob Nielsen, September 2009. Argues for incremental change as the default, with the exception this guide leans on: “in the long run, incrementalism eventually destroys cohesiveness, calling for a new UI architecture.”
- HTTP Archive — Web Almanac 2025, CMS chapter ↗
Platform-level Core Web Vitals pass rates across the real web, useful as an outside benchmark when judging whether your own field data is a site problem or a platform one.
— FAQ
Frequently asked questions
Not sure whether your site needs a rebuild or just a repair list?
Send us the URL and what is bothering you about it, and we will tell you which of the two it actually is — including when the answer is “leave it alone”.