A website can feel old without needing to be rebuilt.
That distinction can save a business a surprising amount of money.
When a site stops representing the business properly, three very different jobs often get called a “redesign”: a refresh, a redesign, or a rebuild. They solve different problems, carry different risks and should not automatically have the same budget.
The useful question is not “How old is the website?” It is what is actually failing?
The short answer
Choose a refresh when the structure and technology still work, but the presentation has fallen behind. Choose a redesign when visitors struggle to understand, trust or act on the site. Choose a rebuild when the underlying system itself is creating the problem.
A rebuild is the most invasive option. It should earn that disruption.
A refresh fixes the surface without replacing the system
A refresh is appropriate when the bones of the website are still sound.
Perhaps the business has changed its positioning. The photography is weak. Service descriptions are outdated. Typography feels dated. Calls to action are inconsistent. The homepage no longer reflects the strongest offer.
Those are real problems, but they do not automatically justify replacing the CMS, changing every URL or moving the site to a new stack.
A good refresh can include new visual direction, stronger copy, better images, clearer calls to action and selective layout improvements while leaving the underlying system largely intact.
This is usually the lowest-risk option because less changes at once.
A redesign fixes how the website communicates and converts
A redesign goes deeper.
The website may technically work, but the experience does not.
Visitors cannot tell what the company does quickly enough. Important services are buried. Mobile navigation is awkward. Enquiry routes compete with each other. The homepage gives every section equal weight. Forms ask too much. Trust arrives too late.
Those problems require more than changing colours.
A redesign rethinks hierarchy, navigation, page structure, responsive behaviour and the journey from arrival to action. Some technology may stay. Some may change. The decision should follow the problem rather than a preference for a particular platform.
If your site is getting visitors but not enough enquiries or sales, start by diagnosing the journey before assuming the entire system needs replacement. My guide to why websites get traffic but no sales is a useful companion.
A rebuild fixes the underlying system
A rebuild becomes reasonable when the technology underneath the website is now the constraint.
Examples include a CMS the team can no longer manage, fragile plugins, poor performance that cannot be fixed responsibly in place, inaccessible templates that fight every improvement, an architecture that makes ordinary changes expensive, or new requirements the current system was never designed to support.
A business may also outgrow a conventional website entirely. If the next version needs accounts, permissions, payments, dashboards or operational workflows, the project may be moving into MVP or product development rather than simply web design.
That is a legitimate reason to rebuild.
“Newer technology exists” is not.
Do not rebuild just because a designer prefers another stack
This is where businesses can waste money.
A developer may prefer a different framework. An agency may have a standard platform. A new tool may look more modern. None of those facts proves that moving your website creates enough value to justify the migration.
Changing the underlying system can affect content, forms, analytics, redirects, integrations, search visibility and the way staff update the site.
If the current system can support the required outcome cleanly, keeping it may be the better engineering decision.
I apply the same principle when choosing infrastructure for new projects: do not pay for complexity you do not need yet. The cheapest build is not always the cheapest website to own, but neither is the most elaborate architecture automatically the most professional.
SEO makes unnecessary rebuilds more dangerous
An established website has accumulated history.
Its URLs may already rank. Other sites may link to them. Google may understand which page owns which topic. Internal links have formed a structure. Search Console and analytics have historical data tied to those journeys.
A rebuild can preserve those assets, but only if migration is treated as part of the project rather than cleanup after launch.
Google’s Search Central documentation recommends mapping old URLs to new destinations and using permanent server-side redirects when URLs change. It also advises avoiding unnecessary combinations of major changes during a site move because changing too many things simultaneously makes problems harder to diagnose.
Source: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
That is why I prefer to preserve a working public URL unless changing it solves a real problem.
A visual redesign does not require a new URL structure.
A new framework does not require throwing away search equity.
Accessibility can change the decision
Sometimes a website looks fine but is difficult to use.
Keyboard navigation may be poor. Focus states may be missing. Contrast may be weak. Forms may not communicate errors properly. Motion may make the experience harder rather than clearer.
The W3C Web Content Accessibility Guidelines provide a shared standard for making web content more perceivable, operable, understandable and robust.
Source: https://www.w3.org/TR/WCAG22/
Accessibility problems do not automatically require a rebuild either. Some can be corrected within the existing design system. Others are deeply embedded in templates or components and make a larger redesign more sensible.
Again, diagnose first.
Look at the running cost, not only the redesign quote
A website decision should include what happens after launch.
Suppose one proposal is cheaper upfront but leaves the business paying for unnecessary hosting, plugins and services every month. Another costs more to build but removes recurring dependencies. A third rebuilds everything even though the current infrastructure is inexpensive and reliable.
The initial quote does not tell you which option is cheaper to own.
Before approving a rebuild, ask what changes in:
- hosting and infrastructure cost
- software subscriptions
- maintenance
- content editing
- developer dependency
- analytics and tracking
- ownership of accounts and code
This is one reason I plan web projects around the business before choosing the architecture. You should not be paying for infrastructure simply because it is fashionable or because the developer uses it on every project.
A simple way to make the decision
Ask these questions in order.
1. Is the current technology actually preventing the required outcome?
If no, do not start with a rebuild.
2. Is the problem mainly visual or content-related?
If yes, investigate a refresh.
3. Is the structure or customer journey failing?
If yes, you probably need a redesign.
4. Are performance, maintainability, ownership or new functionality constrained by the underlying system?
If yes, a rebuild may now be justified.
5. What valuable things already work?
List them before changing anything: URLs, rankings, content, analytics, integrations, forms, customer habits and internal workflows.
A good redesign protects what is working while fixing what is not.
What I look at before recommending a rebuild
When I audit an existing website, I am interested in more than whether it looks dated.
I look at the business goal, mobile journey, content hierarchy, search structure, accessibility, performance, editing experience, ownership and the cost of operating the current setup.
That often changes the recommendation.
Sometimes a business asking for a new website really needs a focused redesign.
Sometimes it needs three pages rewritten and a broken enquiry journey fixed.
And sometimes the old system genuinely is the problem and continuing to patch it will cost more than rebuilding it properly.
The point is to know which situation you are in before paying for the most expensive option.
If you are unsure whether your website needs a refresh, redesign or full rebuild, tell me what is not working. I can help you diagnose the problem before we decide what should be replaced.
