Comparison · Platforms
Redesign vs rebuild: improving your website or starting again
When a website stops meeting the business's needs, two routes are possible. A redesign improves the design, structure and content on the existing technical foundation. A rebuild replaces the foundation — platform, code, sometimes the whole architecture — and usually the design too. The decision depends less on how the site looks and more on what is wrong underneath.
[ 01 ]
In short
In short
- 01
Redesign when the platform is sound but the design, structure or content no longer work.
- 02
Rebuild when the platform is outdated, insecure, slow by design or cannot support what the business needs.
- 03
Targeted improvements are sometimes enough — neither a full redesign nor a rebuild.
- 04
Both carry risks for search traffic; URLs, content and technical settings must be carried over.
- 05
Decide based on an audit, not on appearance alone.
[ 02 ]
Comparison
Side by side
| Criterion | Redesign | Rebuild |
|---|---|---|
| What changes | Design, structure, content, templates | Platform, code, data model, usually design |
| Cost and time | Lower | Higher |
| Risk | Moderate | Higher: migration of content and functions |
| Solves outdated platform | No | Yes |
| Solves performance built into the platform | Partly | Yes |
| Enables new functions and integrations | Within platform limits | Designed for them |
| SEO risk | URL and content changes | URL, content and technical changes |
Signs a redesign is enough
- The platform is maintained, secure and flexible enough.
- Problems are about presentation: outdated look, unclear structure, weak texts, poor mobile layout.
- Integrations and functions work as needed.
- Editors are comfortable with the admin panel.
Signs a rebuild is needed
- The platform or framework no longer receives security updates.
- Speed problems come from the platform itself, not from content.
- Required functions or integrations — local payments, CRM, 1C, multilingual SEO — are impossible or fragile.
- Every change requires workarounds, and developers are reluctant to touch the code.
- The site has been hacked repeatedly due to its architecture.
Targeted improvements
Sometimes the right answer is neither: speed optimisation, rewriting key pages, fixing forms, improving mobile layout or adding a missing integration. An audit shows whether the problems are concentrated or systemic. See technical SEO audit checklist.
Protecting search traffic
Both routes risk losing rankings if URLs change without redirects, content is removed, or technical settings are lost. A redirect map, content inventory and post-launch monitoring are part of either project. See redirects when changing a website.
Applications and internal systems
The same logic applies to business software: improve the interface and modules if the core is sound, rebuild gradually when it is not. See legacy software modernisation.
Decision checklist
- Is the platform supported and secure?
- Can it deliver the performance you need?
- Can it support the functions and integrations planned for the next two years?
- Are editors and developers able to work with it efficiently?
- Are problems mainly about design and content?
Mostly "yes" to 1–4 and "yes" to 5: redesign. "No" to any of 1–3: consider a rebuild.
[ 03 ]
FAQ
Frequently asked questions
Is a rebuild always more expensive?
Upfront, usually. But maintaining an outdated platform with workarounds can cost more over time than rebuilding.
Can we redesign now and rebuild later?
Yes, if the redesign is modest. Investing heavily in a redesign on a platform you will replace soon is usually wasteful.
Will a rebuild improve our rankings?
Not automatically. It can remove technical obstacles; rankings depend on preserving content and signals and on what the new site offers.