Improve or rebuild your website?
By Uniqode
A website that feels outdated does not automatically need replacing. A new design will not necessarily fix unclear content or slow internal approvals either. Start with the problem you need to solve, then decide how much of the website has to change.
Separate symptoms from causes
“The website does not work for us” is a starting point, not yet a brief. Ask people to show a specific task that goes wrong. Can a visitor find the right service? Can an editor publish a case study? Does changing one language unexpectedly affect another?
Write down what happens, who it affects and what a successful outcome would look like. That gives you something to evaluate beyond whether the website looks modern.
When improvement is a sensible first step
- The structure still fits. Your audiences, services and main content types can be represented without awkward workarounds.
- The problems are local. A confusing service page, weak navigation labels or an unnecessary form field may be addressed without replacing the whole site.
- The platform remains maintainable. Your technical partner can explain the update path and the risks involved.
- Your team can use it. Editors can complete ordinary tasks once a specific configuration or training gap is addressed.
A useful first phase might be rewriting key service pages, improving the enquiry journey and simplifying an editor’s most frequent task. Define how you will judge the result before starting.
When a rebuild deserves consideration
A rebuild becomes more relevant when the problems are structural: the content model cannot represent your services, the language workflow conflicts with how the team operates, or essential integrations require repeated workarounds. A platform that can no longer be maintained also needs a technical review.
Compare the cost and disruption of improving the existing foundation with replacing it. Include content preparation, migration, testing, training and ongoing care in both options. Reusing sound content or integrations may still make sense within a rebuild.
Three illustrative decisions
Unclear services, workable CMS. A consultancy has a supported website but visitors cannot distinguish its services. Start by improving the service structure, copy and next steps. A rebuild is not yet justified by that problem alone.
Every new page needs custom development. An organisation repeatedly commissions one-off layouts because the CMS cannot express its content. Review the content model and templates. A focused rebuild of that foundation may be more useful than another visual refresh.
Two languages, conflicting workflows. Editors need local variations but the site forces both languages into identical structures. First check whether the existing CMS configuration can support the requirement. Rebuild only if a practical, maintainable improvement is not available.
These are hypothetical examples, not client results. Your own decision depends on the evidence from your website.
Website planning checklist
Copy these prompts into a document and answer them with your team. Mark unknowns instead of guessing.
- Purpose: What must the website help your organisation achieve?
- Audiences: Who uses it, and what are their three most important tasks?
- Evidence: Which pages, support requests or editing tasks show the problem?
- Content: What should be kept, rewritten, removed or created?
- Languages: Which content is shared, translated or local?
- Connections: Which systems, forms and external services must keep working?
- Ownership: Who prepares content, approves work and makes final decisions?
- Constraints: What budget range, deadline and internal capacity are available?
- First release: What is essential now, and what can wait?
- Success: Which visitor or editor outcomes will you check after the changes?
Turn the discussion into a decision
You do not need every answer before talking to a web partner. You do need a shared view of the questions. A Website Roadmap can turn them into a recommendation, priorities and a defined first phase.