These two words get used as though they mean roughly the same thing at slightly different prices. They do not. One changes the surface and keeps the machinery. The other replaces the machinery and usually the surface with it, at several times the cost and with a category of risk the first does not carry.
Choosing wrongly is expensive in both directions. A rebuild where a redesign would have done wastes money and puts search visibility at risk for no reason. A redesign where a rebuild was needed produces a better-looking version of the same problems, and the disappointment arrives about four months later.
The distinction that matters
A redesign changes appearance, layout and content. The pages are the same pages, the addresses stay the same, the underlying system stays the same. It is work on the visible layer.
A rebuild replaces the underlying system: the platform, the way content is stored, the page structure, often the hosting. The visible result may look similar or completely different, and that is beside the point. The machinery is new.
There is a third option people forget, and it is frequently the right one.
A repair fixes specific problems in place. Rewrite three pages, remove the video that makes the homepage slow, add the two answers customers keep phoning about, fix the contact form on mobile. No redesign, no rebuild, a fortnight of work, and a large share of the benefit.
Before choosing between the two large options, it is worth asking honestly whether a repair addresses most of what is actually wrong. Frequently it does.
Four questions that decide it
One: is the problem what visitors see, or what the site can do?
If your list of complaints is about appearance, tone, dated styling, or content that says the wrong things, that is a redesign. If the list includes things the site cannot do at all, or can only do by paying someone each time, that points at the machinery.
Two: can your team change things without a developer?
If a price change means an email to an agency, that is not a design problem and no redesign will resolve it. Content management is structural. Adding it to a site that was not built for it is normally a rebuild wearing another name.
Three: is the site slow because of what is on it, or because of how it is made?
A slow site caused by unoptimised images and four tracking scripts can be repaired in days. A slow site caused by a heavy theme stacked with 20 plugins, each loading its own code on every page, cannot be fixed by removing pictures. That distinction is worth having examined by someone technical before deciding, because it separates a cheap fix from an expensive project.
Four: does the structure still match the business?
Sites are built around the business as it was. Companies add services, drop others, start serving a second type of customer, expand into another country or another language. When the navigation no longer describes what the company does, and every new addition has to be forced into a category that does not fit, the structure has stopped fitting. That is a rebuild, and no amount of restyling will hide it.
Two or more answers pointing at the machinery means a rebuild is likely justified. One means look harder before spending.
What each one actually involves
| Repair | Redesign | Rebuild | |
|---|---|---|---|
| What changes | Specific pages and assets | Appearance, layout, content | Platform, structure, content model, usually design too |
| Typical duration | Days to a fortnight | Weeks | Months |
| Relative cost | Lowest | Middle | Highest, often several times a redesign |
| Search risk | Almost none | Low, if addresses do not change | Real, and the main thing to manage |
| Integrations | Untouched | Usually untouched | All must be re-tested, some rewritten |
| Content | Edited | Reviewed and rewritten | Migrated, which is a project of its own |
| What you get | The specific problems gone | A current-looking site doing the same things | A site that can do things the old one could not |
| The risk you carry | Fixing symptoms while a cause remains | Fixing appearance while the cause is structural | Losing things the old site quietly did well |
What a rebuild puts at risk
This is the part that goes missing from most proposals, and it is where rebuilds fail.
Search visibility. A site that ranks does so partly because of pages that have existed at fixed addresses for years, and links pointing at them from elsewhere. A rebuild that changes those addresses without redirects throws that away. Recovery takes months, and is not guaranteed. Redirect mapping is not a technical detail to be handled at the end; it is a deliverable that should be agreed before the build starts.
Content nobody remembers. Old sites accumulate pages that quietly do work: a technical specification a customer base still references, a page that answers one question extremely well and brings in a steady trickle of the right people. A migration driven by the new navigation will drop them, because nobody in the room knows they exist. The protection is a full inventory of existing pages and their traffic before anything is designed.
Things attached to the old site. Forms feeding a CRM, a booking widget, a payment integration, tracking someone set up four years ago, an email service that pulls from a page. These get discovered in the final week of the project with reliable regularity.
Institutional knowledge. The old site encodes decisions nobody wrote down: why a page is worded a certain way, why that form asks for a purchase order number. Some of those decisions were responses to real problems that will now recur.
None of this argues against rebuilding. It argues for treating a rebuild as a migration project with a design component, rather than a design project with a migration at the end. That distinction changes what gets planned and what gets paid attention.
The migration checklist
If it is a rebuild, these belong in the scope before work starts, not in the final fortnight.
- A full inventory of every existing address, with its traffic and its inbound links, exported before anything changes.
- A redirect map from every old address to its closest new equivalent. Every one, including pages you are removing, which should point at the nearest useful page rather than at the homepage.
- A list of every integration currently touching the site, tested individually on the new one.
- The pages that must not lose their address, protected explicitly. If a page brings in real search traffic, keeping its address is worth more than fitting it into a tidier structure.
- A content decision per page: keep as is, rewrite, merge, or drop with a redirect. Made deliberately, not by omission.
- Analytics and tracking, re-implemented and verified on a real transaction rather than assumed.
- A comparison point: search traffic and enquiries for the three months before launch, recorded, so that you can tell afterwards whether something went wrong. Without this you are left with impressions.
That list is unglamorous and it is the difference between a rebuild that keeps what worked and one that starts from zero without anyone deciding to.
An illustrative example
A company with a six-year-old site wants a rebuild. The complaints are that it looks dated, it is slow on mobile, and adding a case study takes a week of waiting on their agency.
Assessed against the four questions: appearance points to a redesign, editing points to structure, and the slowness needs examination before it can be classified. The site turns out to run on a heavy commercial theme with 23 plugins, which explains both the speed and the editing difficulty, since the editor is a page builder that produces layouts nobody else can safely modify.
That is a rebuild, on two of the four questions. But the sequencing matters. Their most valuable asset is a technical guide page that has ranked for years and brings in a third of their enquiries. In the first version of the plan it was being merged into a new resources section at a new address, which would have risked the best-performing page on the site to tidy the navigation. Keeping its address, and building around it, costs nothing and removes the largest risk in the project. Hypothetical, but that specific mistake is one of the most common in website rebuilds.
Common questions
How long should a website last before rebuilding? Well-built sites can run five to eight years with content updated throughout. The trigger should be structural mismatch or a platform that is no longer safe to run, not the calendar. Rebuilding every three years because a style feels dated is an expensive habit that produces no compounding benefit.
Can we rebuild in stages? Sometimes. A site with clearly separable sections can move in parts, with both running behind one address. It adds complexity and it is worth it when the site is large or when a single launch would carry too much risk. For a small site it is usually more trouble than a clean cut-over.
Will a rebuild improve our search performance? It can, through better structure, faster pages and better content, and it can also do serious damage through lost addresses. The outcome depends almost entirely on the migration work above rather than on the new design. Any proposal that promises improved rankings without describing a redirect strategy has not thought about the question.
Should we keep the same platform? Only if it is still a reasonable fit. Moving platforms for its own sake adds cost and risk. Staying on one that is genuinely holding you back means paying for a rebuild without solving the problem that prompted it.
The short version
- A redesign changes the surface. A rebuild replaces the machinery. A repair fixes specific problems in place and is often most of what is needed.
- Four questions: is the problem what visitors see or what the site can do, can your team edit it, is the slowness superficial or structural, and does the structure still match the business.
- Two or more answers pointing at the machinery justifies a rebuild. One does not.
- The real risk in a rebuild is not design. It is losing search visibility, quietly valuable pages, and integrations nobody remembered.
- Treat a rebuild as a migration project with a design component. The inventory, redirect map and integration list belong in the scope at the start.
- Record traffic and enquiries for the three months before launch, so you can tell afterwards whether it worked.
Where to take this next
If you have not yet worked out what is actually wrong, run the test in what a business website should actually do first. It is 20 minutes, and it frequently turns a rebuild conversation into a repair.
If the answer is a rebuild, the cost drivers are the same ones as any custom project, and what drives the cost of custom software explains why quotes vary so widely for what looks like the same site.
If you would like an opinion on which of the three you need before committing to a budget, describe the situation. Discuss your idea, or say hi on WhatsApp.
# Visual recommendations
Concepts only. Hairline drawing, ink and brass.
Hero visual — surface and machinery
Concept. One page outline drawn twice, in cross-section. The left version shows a new surface layer in brass over an unchanged block of machinery beneath, labelled redesign. The right shows both layers replaced, labelled rebuild, with a small hatched band underneath labelled migration: addresses, content, integrations. A third smaller figure sits to the side: the same page with three small brass patches on it, labelled repair.
Purpose. Fixes the vocabulary in one image, which is the article's first job.
Alt text. A redesign replaces the visible surface over unchanged machinery. A rebuild replaces both and adds a migration layer of addresses, content and integrations. A repair patches specific problems in place.
Supporting visual — what a rebuild puts at risk
Concept. An old site drawn as a set of page blocks, four of them shaded to indicate steady inbound traffic, with thin arrows arriving from outside the frame. Beside it, the new site, where three of the shaded pages have arrows landing on them and one has an arrow ending in a broken line short of the page.
Purpose. Makes the abstract risk concrete: the loss is not visible on the new site, which is why it goes unnoticed for months.
Placement. At the head of the "What a rebuild puts at risk" section.
Alt text. Four pages on an old site receive steady inbound links. After a rebuild, three still receive them and one has lost its address, with its incoming link ending nowhere.