Rebuild strategy
When should you rebuild a website instead of redesigning it?
A redesign changes presentation. A rebuild changes architecture. Confusing the two produces a site that looks new and behaves exactly like the one it replaced.
Almost every website conversation starts in the same place: the site looks dated. That statement is accurate and rarely diagnostic. Underneath it sit two very different projects with different costs, different risks and different outcomes — and choosing the wrong one is why a business can spend a substantial budget and end up with the same problems in a new typeface.
Redesign and rebuild are not the same project
A redesign works within the existing system. It changes what visitors see and how the site reads, using the templates, content model and platform already in place. It is faster, cheaper and lower-risk, because nothing beneath the surface moves.
A rebuild replaces the construction: how pages are assembled, how content is modelled, how components are reused, how the site is delivered and, frequently, which content system runs it. It is a longer project with real migration risk attached, and it is the only one of the two that changes what the site is capable of.
Surface layer vs structural layer
When a redesign is enough
- The visual hierarchy is tired: everything is the same weight, so nothing leads.
- Typography and spacing are inconsistent between pages built at different times.
- Components have drifted — four button styles, three card treatments, two navigation patterns.
- The messaging no longer matches how the business describes itself.
- Conversion is weak for reasons of clarity and sequence rather than platform capability.
- The underlying site is otherwise fast, editable, accessible and stable.
If that list describes your situation, a rebuild is an expensive way to solve a design problem. Spend the money on structure of content and clarity of message instead.
Signals the underlying website needs rebuilding
These are the symptoms that survive a redesign, because they are properties of the system rather than the skin on top of it.
- Brittle templates: small changes break unrelated pages, and nobody can predict which.
- Dependency sprawl, where core behaviour lives in a dozen plugins or add-ons nobody controls the release schedule of.
- Performance that resists tuning because the delivery model, not the imagery, is the bottleneck.
- Structure that is inaccessible at the markup level — headings used for size, layout tables, controls that are not real controls.
- Editing that requires a developer for changes an editor should be able to make in minutes.
- Responsive behaviour patched breakpoint by breakpoint rather than designed once.
- No component architecture, so the same block is reimplemented on each page it appears on.
- A technical foundation that no longer receives meaningful security or compatibility updates.
- Integrations that are effectively impossible because the system has no clean data boundary.
- Recurring regressions: the same defects return after every update.
Don't rebuild simply because the site looks old
Age is not an architectural fault. A well-structured site built five years ago on a sound content model, with clean markup and disciplined components, can be redesigned convincingly and cheaply. A poorly structured site built last year can already be beyond economic repair. The relevant question is never how old the system is; it is how much every future change costs.
Content migration changes the equation
The moment content moves between systems, the project stops being a build and becomes a migration. That is where the genuine risk sits: URLs, redirects, metadata, internal links, structured data and the accumulated search equity of every page that already ranks. The mechanics of protecting all of that are covered in SEO migrations and redirects, and the internal link structure that has to be rebuilt alongside it in internal linking architecture.
Treat the content inventory as the first deliverable of the rebuild, not as a task for the week before launch. Every URL, its purpose, its performance and its destination in the new structure — decided before anything is designed.
Inventory → decide → rebuild
Preserve URLs and search architecture
A rebuild is an opportunity to fix a genuinely wrong URL structure — inherited category prefixes, dated paths, duplicate hierarchies. It is not a reason to change URLs that already work. Where paths do change, permanent redirects map old to new one-to-one wherever a direct equivalent exists, and internal links point at the new destination directly rather than routing visitors through a redirect chain.
What should survive a rebuild
| Preserve | Why it matters |
|---|---|
| Content that earns traffic or leads | It is the evidence of what the audience actually wants |
| URL structure, where it is sound | Every external link and ranking signal depends on it |
| Titles, descriptions and structured data | Regenerating them wholesale discards years of refinement |
| Analytics continuity | Without it, nobody can tell whether the rebuild worked |
| Conversion paths | The forms, calls to action and journeys that already convert |
| Business rules | Pricing logic, eligibility, regional handling and other quiet dependencies |
| Brand equity | Recognition survives a redesign; discarding it restarts it |
What should not survive
- Plugins added for a single feature that the new system handles natively.
- Duplicated templates that differ by a heading and a background colour.
- Tracking scripts nobody can name the owner of.
- Layout hacks holding a broken grid together.
- Content models that were never used, and taxonomies with one entry.
- Pages that exist because they were once required, and now serve no visitor.
The rebuild decision checklist
| Question | Redesign | Rebuild |
|---|---|---|
| What is the primary complaint? | How it looks and reads | How it behaves and what it costs to change |
| Can editors make routine changes? | Yes | No, or only with developer help |
| Is performance fixable by tuning? | Yes | No — the delivery model is the limit |
| Is the markup structurally accessible? | Broadly yes | No, at the component level |
| Are new page types straightforward? | Yes, within existing templates | Each one is a bespoke project |
| Are integrations possible? | Yes, or not needed | Blocked by the platform |
| Is the foundation supported? | Yes | No longer maintained |
| Is content moving systems? | No | Yes — plan it as a migration |
We made this decision on our own site and documented the reasoning and the outcome in rebuilding our own website into a working platform. Where the conclusion is a rebuild, it belongs in the same scope as application and PWA development, because the architecture decisions are the same ones.
A redesign answers how the site should look. A rebuild answers what the site should be able to do next year. Only one of those is a design brief.
Frequently asked questions
- What is the difference between a website redesign and a rebuild?
A redesign changes the presentation layer: layout, typography, imagery, hierarchy and messaging, on top of the existing system. A rebuild replaces the system underneath — templates, content model, components, delivery and often the CMS. A rebuild almost always includes a redesign; a redesign rarely fixes anything structural.
- How often should a website be rebuilt?
There is no fixed cycle, and any agency quoting one is describing its own sales calendar. The honest measure is the cost of change: when routine edits, new page types or a simple integration each require a specialist and carry regression risk, the architecture is charging rent.
- Can a redesign improve performance?
Sometimes, and usually less than hoped. Removing heavy imagery, sliders and unnecessary scripts genuinely helps. If the delivery model, template structure or plugin stack is the constraint, a new visual layer sits on the same foundation and the improvement plateaus quickly.
- Will rebuilding a website hurt SEO?
It can, and the damage is almost always self-inflicted rather than inevitable. Loss happens when URLs change without redirects, content is dropped, metadata is regenerated carelessly or internal linking is flattened. Planned properly, a rebuild usually improves search performance because structure and speed improve together. See SEO migrations and redirects.
- Should URLs change during a rebuild?
Only where the existing structure is genuinely wrong, and then deliberately, with permanent redirects and an updated internal link graph. Changing URLs because the new system prefers a different pattern is the most common avoidable cause of lost visibility.
- Should content be rewritten during a rebuild?
Audit first, then decide page by page. Pages that earn traffic or conversions are usually refined rather than replaced. Rewriting everything at once means changing structure and content simultaneously, which makes it impossible to attribute any change in performance afterwards.
- When is rebuilding unnecessary?
When the complaints are all about appearance, messaging or conversion, and the underlying site is fast, editable, accessible and stable. That is a redesign, and treating it as a rebuild spends the budget in the wrong layer.