Michele Eccher
On this page
Choose a focused redesign when the website’s foundations still support the business but the brand, content or user experience needs improvement. Choose a rebuild when the platform, architecture, content model, integrations, maintainability or performance prevents the site from doing its job. Many projects need a phased combination rather than an all-or-nothing choice.
‘The website feels old’ describes a symptom, not a scope. The problem may be inconsistent typography, an unclear offer, a navigation model that no longer reflects the business, a fragile CMS or a codebase where every change creates risk. Treating all of these as visual design can under-scope the project; treating all of them as a rebuild can discard working assets and increase migration risk.
This guide helps choose the level of change. It is distinct from estimating how much a website costs and from the detailed SEO migration checklist. Scope comes first; cost and migration planning follow.
Diagnose
Separate visual, content, experience, technical and operating issues.
Preserve
Identify the pages, signals, systems and behaviours already working.
Choose
Refresh, redesign, rebuild or phase the work.
Control
Plan migration, QA, measurement and post-launch ownership.
Use three levels of change, not two vague labels
| Approach | What changes | What usually stays |
|---|---|---|
| Visual refresh | Typography, colour, imagery, component styling and selected templates | Core architecture, CMS, content model, URLs and integrations |
| Structural redesign | Messaging, journeys, navigation, page hierarchy, templates and design system | The platform and sound technical foundations may remain |
| Full rebuild or replatform | Architecture, codebase, CMS, data model, integrations and front-end implementation | Valuable content, URLs, search signals and proven user behaviours should be preserved where possible |
A redesign can include development, and a rebuild still needs design. The useful distinction is not whether code changes; it is whether the existing technical and content foundations remain the right foundation. Define the terms in the brief so every supplier prices the same problem.
Trace each complaint to its underlying constraint
Review the current website across
- Business goals, priority audiences and measurable website outcomes
- Positioning, offer clarity, proof and content quality
- Navigation, search, user journeys, forms and accessibility
- Organic visibility, URL performance and internal linking
- CMS editing, governance, localisation and publishing workflow
- Performance, security, maintainability and technical debt
- CRM, ecommerce, analytics and other integrations
- Ownership, vendor dependency and the real cost of change
Collect analytics, Search Console data, content inventory, support issues, search logs, usability findings, sales feedback and editor interviews. Then inspect the code and CMS. A team that only reviews visual references cannot know whether the problem is a weak interface, weak content or a weak platform.
Surface constraint
The brand feels inconsistent, hierarchy is weak or components look dated.
Experience constraint
People cannot find, understand, compare or complete important tasks.
Content constraint
The architecture, copy and evidence no longer reflect the business or audience.
Platform constraint
Editing, integrations, security, performance or maintenance blocks progress.
Choose a focused refresh when the foundation is sound
A refresh is appropriate when the information architecture, core journeys, CMS, performance and integrations still support the business, but the visual language has drifted or selected templates underperform. It can improve credibility and consistency without forcing a high-risk migration.
Signals that a refresh may be enough
- Editors can create and update content without workarounds
- Priority tasks are easy to find and complete
- The URL structure and organic landing pages remain appropriate
- The front end can support a coherent component and accessibility update
- Required integrations are stable and documented
- The main gap is visual consistency, hierarchy or a limited set of templates
A refresh should still begin with a design-system audit and representative templates. Recolouring the homepage while leaving forms, articles and service pages inconsistent creates a new layer of visual debt rather than resolving it.
Choose a redesign when the experience must change
A structural redesign is justified when the platform remains viable but the site no longer communicates the offer, serves the right audiences or supports important journeys. The work may change positioning, content hierarchy, navigation, page types, interaction patterns and conversion paths while retaining the CMS and selected integrations.
Reframe the brief
Define the audience, business outcome and experience problem rather than asking for a new look.
Redesign the structure
Test navigation, page relationships, content hierarchy and task flows before high-fidelity screens.
Create the system
Build reusable components and content rules that work across representative templates.
Validate in the existing stack
Confirm that the CMS and front end can implement the proposed experience without fragile exceptions.
Choose a rebuild when the foundation blocks the required future
| Rebuild signal | Evidence to require | Question before proceeding |
|---|---|---|
| CMS no longer fits | Recurring editing workarounds, missing permissions, weak localisation or unusable content models | Can configuration solve it, or is the model fundamentally wrong? |
| Technical debt dominates change | Small releases are slow, risky and expensive; dependencies are obsolete or unsupported | What must be retired, and what can be migrated safely? |
| Required capabilities are impossible | Critical integration, commerce, search or personalisation needs cannot be supported reliably | Is the requirement valuable enough to justify lifecycle cost? |
| Performance and accessibility are structural | The rendering model or component base prevents consistent compliance | Can targeted engineering resolve the bottleneck first? |
| Ownership is unacceptable | The organisation cannot export content, control deployment or change supplier safely | What ownership and exit conditions must the new platform guarantee? |
Do not rebuild simply because the current stack is unfashionable. A new platform creates migration, training, integration and maintenance costs of its own. Compare the cost and risk of repairing the present system with the complete lifecycle of the replacement, not only the launch quote.
Score the options against evidence and risk
| Criterion | Refresh | Redesign | Rebuild |
|---|---|---|---|
| Brand and visual inconsistency | Strong fit | Strong fit | Possible but excessive alone |
| Unclear journeys or information architecture | Weak fit | Strong fit | Strong fit if foundations also fail |
| Poor content model and publishing workflow | Weak fit | Partial fit | Strong fit |
| Unsupported code or critical integrations | Weak fit | Weak fit | Strong fit |
| High-value SEO footprint to preserve | Lower migration risk | Moderate risk | Highest planning and QA requirement |
| Need to launch improvements quickly | Often fastest | Can be phased | Usually slowest |
| Long-term operating flexibility | Limited change | Improves front-end system | Can reset the full operating model |
Weight the criteria by business importance. If editors publish daily, CMS workflow may matter more than a marginal infrastructure saving. If organic search produces a large share of qualified demand, URL preservation, content parity and migration control carry more weight. Record assumptions so the decision can be challenged before procurement.
Protect SEO, analytics and accessibility in every approach
Even a visual refresh can alter headings, links, templates and performance. A redesign or rebuild can change URLs, rendering and content coverage. Preserve a baseline of rankings, traffic, conversions, Core Web Vitals and key user tasks; inventory current URLs and map every change before launch.
Non-negotiable launch controls
- A complete current URL inventory and one-to-one redirect map where URLs change
- Content parity and an explicit decision for every valuable page
- Self-referencing canonicals, hreflang where relevant and an updated sitemap
- Internal links that point directly to final URLs
- Analytics, consent, forms, CRM handoffs and key events tested end to end
- Responsive, keyboard, contrast and assistive-technology checks
- Performance tests on representative templates and real devices
- Crawl, status, indexation and conversion monitoring after launch
Google recommends mapping old URLs, updating internal links and using server-side permanent redirects when URLs move; its site move guidance also advises changing one major element at a time where practical. Accessibility should be treated as a design and engineering requirement throughout the project; the W3C overview of WCAG provides the shared standard.
Brief the outcome, preserved assets and constraints
A decision-ready website brief should state
- The business change and user tasks the project must support
- Evidence from the current site and the diagnosed constraints
- What must be preserved, improved, migrated or retired
- Representative content types, templates and journeys
- Technical, data, accessibility, localisation and integration requirements
- Ownership of domains, code, design files, content, analytics and accounts
- Acceptance criteria, launch controls and post-launch responsibilities
- Budget range, timing constraints and decisions still open
Ask potential partners to explain which level of change they recommend, what evidence supports it and which risks remain. A responsible proposal should make trade-offs visible. If you need one team to connect strategy, content, UX/UI, development, CMS and measurement, explore Qreativa’s web design and development service.
Website redesign and rebuild FAQs
What is the difference between a website redesign and a rebuild?
A redesign changes how the site communicates and works for users, and may retain the existing CMS and technical foundation. A rebuild replaces significant parts of the platform, codebase, content model or integrations. Both require design and development; the distinction is which foundations remain.
Can a website be redesigned without changing its URLs?
Yes. If the existing URL structure still reflects user needs and valuable search demand, it can often be preserved while content, templates and navigation improve. Change URLs only for a clear architectural reason, then map redirects and update all internal references.
Does an old-looking website always need a full rebuild?
No. If the CMS, architecture, performance, accessibility and integrations remain sound, a focused visual and component refresh may solve the problem with less risk. Diagnose the operating and technical foundations before selecting the scope.
When is a staged redesign better than a big-bang launch?
A staged approach is useful when the site is large, evidence is incomplete, the organisation cannot pause publishing, or critical improvements should launch early. It allows the team to validate architecture and components on representative sections before extending the system.
Will a website rebuild damage SEO?
A rebuild creates SEO risk when valuable content, URLs, internal links, metadata, rendering or performance change without control. It does not have to cause lasting loss. Preserve a baseline, map every URL, use relevant permanent redirects, test before launch and monitor crawling, indexing and outcomes afterwards.
How should website redesign proposals be compared?
Compare whether they diagnose the same problem and include comparable strategy, content, design, development, migration, integrations, accessibility, measurement, ownership and post-launch work. A lower quote may simply omit parts of the system rather than deliver them more efficiently.
