Website redesign vs. rebuild: which does your site need?

There are really three sizes of website project, not two. A refresh tweaks the surface of the site you have. A redesign rethinks how it looks and how it is organized. A rebuild goes deeper still and replaces the foundation underneath. This is the decision between the last two, which is where most of the money and most of the confusion sits.

The line between them is simple once you name it: a redesign changes the surface, a rebuild changes the foundation. A redesign gives you a new look, layout, and content structure on the same platform. A rebuild replaces the platform, the code, and the architecture, and almost always ships a new design along with it.

The expensive mistake runs in both directions. Companies buy a redesign to fix a problem that lives in the foundation, then wonder why the new site still can't do what they need. Others pay for a full rebuild when a redesign would have done the job. The way to avoid both is to diagnose the real problem before you pick the size of the project.

At a glance

Update or start over? Match the symptom to the project

Each symptom below points to the smallest fix, and some don't need a project at all. If the only complaint is the look, that's a refresh, covered further down.

• Photos and pages show products, equipment or people that are gone: a content update, not a project. One stale page is upkeep. When the homepage, the services page and the team page all describe an older version of the company, it's the next symptom down.
• The business has changed what it sells or who it sells to, or rebranded around a new position: a redesign, because the structure and the words have to follow the business. A new logo and colors on the same business is usually a refresh.
• Your salespeople send prospects a PDF instead of a link to the site: often a redesign, when it comes alongside other symptoms here. If they've stopped sending the link because it doesn't explain the company, the PDF is a rough outline of what the new pages need to say.
• It ranks and gets traffic but few enquiries: check two cheaper things first. Are the searches bringing that traffic ones your buyers make? Do enquiries actually arrive, with the form reaching a person and forms and calls getting counted? If both hold, redesign the pages people land on: keep their addresses and the substance of what they say, and change the first line, the proof and the next step.
• Every text change needs a developer: check the editor before you scope anything. If it was never set up for your team, that's a CMS setup job on the current platform, not a project. If the platform can't give your team a usable editor at all, that's usually a rebuild. More in why small changes take weeks.
• You need a customer portal, account-specific pricing from your ERP or a product configurator: usually integration work or a separate tool. It's a rebuild only if the platform can't host or connect to it.
• The platform is out of support: if the platform has ended support for a major version and the upgrade is effectively a migration, as with Drupal 7, that's usually a rebuild, before a security problem makes the decision for you. Being behind on updates on a platform that updates in place is maintenance.
• It's slow on a phone: find out why before you pick a project. Oversized images and old plugins and scripts get fixed in place. Pages built loosely in a theme or page builder usually need new templates, which is a redesign on the same platform. It's a rebuild only when the platform itself sets the limit.

Redesign: new surface, same foundation

A redesign changes what visitors see and how the site is structured while keeping the platform it runs on. New visual design, new layouts, reorganized navigation and content, often new copy. The CMS, the code, and the hosting stay where they are.

It is the right call when the problems are on the surface. The site looks dated next to competitors, it is off-brand after a rebrand, the messaging no longer fits, or pages simply aren't converting. If the foundation is sound and only the surface has aged, a redesign fixes it faster and cheaper than tearing everything down.

Rebuild: new foundation, usually new surface

A rebuild replaces the foundation: the platform, the code, and the information architecture. It is effectively a replatform with a redesign riding along, since you rarely rebuild the structure and keep the old look.

You rebuild when the platform has started blocking the business rather than serving it. You can't add the integration or feature you need, the maintenance and security burden has crept up, or the accumulated technical debt makes every change slow and risky. Past that point, patching the surface again just delays the real fix.

The SEO risk follows the URLs

A redesign that keeps its URLs and content usually carries the rankings straight over. A rebuild is where traffic most often gets lost, because it nearly always changes addresses, and a changed URL with no redirect, or content and metadata dropped in the migration, is exactly how a site falls out of search results.

That risk is manageable, not a reason to avoid rebuilding. A serious rebuild plans the URL map, the redirects, and the content migration up front, so the new foundation launches without surrendering the equity the old site earned.

Which does your site need?

List the three things that are actually wrong with your current site, then match them to the size of the project.

• Lean redesign if the complaints are about how the site looks, reads, or converts, and the platform underneath is still doing its job.
• Lean rebuild if the complaints are about what the site can't do: can't integrate, can't scale, can't be maintained or secured without a fight.
• If the problems are cosmetic, no rebuild will feel worth it; if they are structural, no redesign will make them go away.
• Not sure which camp you're in? The Alkali Score benchmarks your site against 55,000+ B2B sites and sends you the first fix we'd make, which usually makes the surface-versus-foundation call obvious.

The third option: a refresh

Redesign and rebuild are the two words people arrive with, and a refresh is the option that often fits better than either. A refresh keeps the structure and the platform and changes the presentation: type, spacing, photography, a tidier homepage, better hierarchy. It's the cheapest of the three by a wide margin and the fastest to ship, usually weeks rather than months.

A refresh is the right call when the site is technically fine and the complaint is that it looks older than the company. If pages load acceptably, the navigation makes sense, and a first-time buyer can already tell what you do, then what you have is a presentation problem and the expensive answers are overkill.

It's the wrong call when the complaint is that nobody understands what you sell, when the pages a buyer searches for don't exist, or when the platform fights every change. A refresh can't fix a structure problem, and the risk is spending real money to make an unclear site look better, which usually buys another two years of the same conversation.

The quick test: write down what a first-time buyer can't do on your site today. If the list is about how it looks, refresh. If it's about what it says or how it's organised, redesign. If it's about what the platform won't let you do, rebuild.

What each path costs in time and money

A refresh is measured in weeks and is the cheapest by a wide margin, because nothing structural moves. A redesign is the middle path and the one most established companies actually need: the work is deciding what the site says and how it's organised, which is thinking time rather than engineering time. A rebuild carries everything a redesign does plus the platform migration underneath it, which is where the schedule and the budget both stretch.

The spread between quotes is driven less by page count than by two things: custom functionality that touches product data, a login or an ERP, and how much of the content somebody has to write from scratch. A rebuild that carries over the same content and structure as the old site is the most expensive way to change nothing.

The timing trap is sequencing. Teams often rebuild first and rewrite later, because the platform decision feels concrete and the messaging work feels vague. That order means paying to move content you're about to replace, and it usually ends with the same unclear homepage launching on faster infrastructure.

How to decide without guessing

Start from what a first-time buyer can't do, not from what the site looks like to you. Show the homepage to somebody outside the company for five seconds and ask what you do and who it's for. Open the site next to three competitors and ask honestly which you'd contact. Count the clicks from landing to a submitted enquiry. Those three tests separate a presentation problem from a structure problem in about ten minutes.

Then check the constraint. If the platform blocks things you actually need, a page type it can't express, a form it can't build, an integration it can't reach, that's a rebuild and no amount of redesign will get around it. If the platform is fine and the content is the problem, a rebuild is an expensive way to keep the problem.

Whichever path you pick, treat the URL map as part of the scope rather than a technical afterthought. Most of the traffic damage that shows up after a launch traces to addresses that changed without redirects, and that's true of a refresh with a new page structure just as much as a full rebuild.

Finally, get the decision made by people who see both sides. The person who lives in the site every day knows what it cannot do; the person who talks to buyers knows what they ask before they call. Redesign scope decided by only one of those two reliably produces a site that is pleasant to administer and still does not answer the question a first-time buyer arrived with. Our B2B website redesign page covers how that work actually runs.

The same complaint, two different projects

Leadership says the site feels dated and isn't generating enquiries. What happens next depends on which problem it actually is.