Most website projects begin with the words “it looks dated”. Sometimes that is the whole problem and a redesign is the right answer. Often the appearance is the only symptom anyone can articulate, and the real trouble is underneath. Choosing wrongly between a redesign or rebuild is the most common reason a website project costs more and takes longer than expected.
The distinction
A redesign changes the presentation. New typography, new colour, new layout, better photography, tighter copy. The structure stays: the same pages exist, the same things link to the same things, the same system runs it.
A rebuild changes the structure. Different pages, different relationships between them, often a different platform underneath. What visitors see may end up looking similar, but almost nothing beneath it is the same.
They are different projects with different costs and different risks. A redesign is largely predictable. A rebuild has genuine unknowns in it, because you are changing how things work rather than how they look.
Signs you need a redesign only
- People can find what they need, it just looks tired doing it.
- Your content is broadly right and reasonably current.
- Analytics show people reaching the pages you want them on.
- The complaint is aesthetic and comes mostly from inside the business.
- The site is reasonably quick and works properly on a phone.
If most of those are true, be suspicious of anyone proposing to start again. You would be paying to rebuild something that works.
Signs you need a rebuild
- Visitors cannot find things that definitely exist. Your internal search gets used heavily, or people phone to ask questions the site already answers.
- Adding a page means finding somewhere to put it rather than knowing where it goes. That is a structural failure, and it compounds.
- The navigation has grown a “more” or “other” item. Those are where information architecture goes to die.
- Editing anything requires a developer, so nothing gets edited, so the content is old.
- It is slow in a way that resists fixing, because the underlying build is the problem.
- It is not genuinely usable on a phone, as opposed to technically responsive.
The test that settles it
Take the three things you most want a visitor to do. Ask someone who does not work for you to do each one, on their phone, while you watch and stay silent.
If they get there but grimace, you need a redesign. If they get lost, backtrack, or give up, you need a rebuild, and no amount of new typography will help. This takes twenty minutes and is more reliable than any amount of internal discussion.
Content is usually the real work
Here is the part that derails schedules. On most rebuilds, the design is not the long pole. The content is.
Restructuring means someone has to decide what each page is for, what stays, what merges, what should have been deleted years ago. That work belongs to people who understand the business, and they already have full-time jobs. Design and build can move quickly. Waiting on copy for a page nobody wants to own can add months.
If you are planning a rebuild, start the content audit before you start anything else. It is unglamorous, it is the critical path, and it is almost always underestimated.
What a rebuild must not lose
Two things get destroyed by rebuilds more often than they should.
The first is your search position. Every URL that changes needs a permanent redirect to its replacement, mapped page by page. Redirecting everything to the homepage is not a migration plan, it is data loss with extra steps.
The second is anything that quietly worked. The form that goes to the right person. The page one customer segment relies on. The integration nobody documented. Inventory these before the old site is switched off, not after someone notices.
A middle path worth considering
You do not always have to choose. Restructuring the twenty pages that carry your business, while leaving the long tail alone until later, is often the sensible move. It concentrates effort where it pays and keeps the project small enough to finish.
The mistake is deciding that because something needs doing, everything needs doing at once.
If you are trying to work out which of these you are actually looking at, our decision guide walks through it in more detail, and we are happy to give an honest read on it through a conversation before anyone writes a proposal.
Related reading
- Core Web Vitals, explained without the jargon — Core Web Vitals are three measurements of how fast a page feels. What each one measures, what usually causes a bad score, and what you can ignore.
- Your contact form is probably the weakest part of your website — The contact form is where a website pays for itself. The common faults that lose enquiries, and what to do about each one, with a test you can run today.
- API integration: what actually goes wrong between two systems — An API integration is easy to demo and hard to keep running. The failure modes that appear in month three, and how to design around them from the start.