Redesign and rebuild describe different kinds of change
Teams often use “redesign” to mean any substantial website project. In practice, the work can range from refining a few weak pages to replacing the platform and rebuilding every template. Clear terms matter because each path changes cost, schedule, migration risk, and what the business must provide.
| Path | What changes | When it can fit |
|---|---|---|
| Refine | Targeted copy, layout, speed, accessibility, or conversion improvements. | The structure and platform are sound and the failures are contained. |
| Redesign | The visual system, page layouts, messaging, and customer paths are reworked. | The site needs coordinated experience changes but useful foundations can remain. |
| Restructure | Navigation, page hierarchy, content model, and internal links change. | The business or service offering has outgrown the current organization. |
| Migrate | Content and functionality move to another platform or implementation. | Editing, hosting, support, or platform constraints justify the move. |
| Rebuild | Templates, components, and technical foundations are implemented again. | Technical debt or required functionality makes patching the old system impractical. |
Fix the existing website when the foundation still works
A rebuild is wasteful when the platform is stable, the content model fits the business, the site can be edited, and the main problems are limited to a few pages or components. Focused work can improve messaging, mobile layouts, images, forms, accessibility, speed, and calls to action without moving everything.
This path works best when the issues can be isolated and tested. If a contact flow is weak, repair that flow. If a group of service pages no longer reflects the offer, rewrite and redesign those pages. The business should not absorb migration risk merely to make the project feel more substantial.
Redesign when the experience needs a shared system
A redesign becomes useful when problems repeat across the site: unclear hierarchy, inconsistent pages, weak mobile behavior, difficult navigation, inaccessible interactions, or conversion paths that no longer match how customers buy. Correcting each symptom separately can create another layer of inconsistency.
Focused changes may still be appropriate when the existing system is sound. A custom rebuild becomes more valuable when specialized content, performance control, customer-facing integrations, or conversion functionality requires a more flexible foundation.
Rebuild when technical constraints control the outcome
Rebuilding is more likely when the code or theme is brittle, the content structure cannot represent the business, routine editing breaks layouts, plugins or extensions create recurring failures, or required integrations cannot be supported safely. Serious accessibility and performance problems can also be architectural rather than cosmetic.
A rebuild does not require discarding everything. Useful copy, imagery, domain authority, indexed URLs, analytics history, customer workflows, and recognizable brand elements can still be preserved or mapped into the new system.
Choose the smallest complete solution
- Document the business goals and current customer paths.
- Inventory useful pages, URLs, content, integrations, and analytics.
- Identify whether each problem is local, repeated, or architectural.
- Test what the current platform can support without fragile workarounds.
- Compare improvement, redesign, migration, and rebuild risk.
- Define what must remain true after launch.
The answer may combine paths: preserve the domain and strongest content, restructure the navigation, redesign the customer-facing pages, and rebuild only the templates or functions that need it.