On this page
An old-looking website is not enough reason to replace it. Start with the business task it should support: explain your offer, receive a qualified enquiry, accept a booking, or let someone find essential information.
A repair makes sense when that task is clear and the current platform can support it. A rebuild deserves consideration when the structure or platform repeatedly prevents it. If the offer itself is unclear, clarify it before buying either option.
Decision at a glance
Choose the smallest change that solves the constraint
| What you find | First option to assess | Evidence to collect |
|---|---|---|
| One broken form or confusing page | Targeted repair | A reproducible failure or unclear step |
| Useful pages with weak explanations | Content and navigation update | Questions visitors cannot answer |
| The same obstacle across key journeys | Structural redesign or rebuild | Tasks the current setup cannot support |
| No clear offer or target customer | Clarify the brief first | One audience, one offer, one next action |
Scroll horizontally to see the full comparison.
Define success in observable terms
Replace “make it modern” with a task someone can complete. For example: a visitor identifies the relevant service, understands what is included, and submits an enquiry that reaches the right inbox. Decide what must happen after submission too. A confirmation on screen is not proof that the business received the message.
- Write down the intended audience and its main question.
- Name the action the page should make possible.
- Define how you will verify that action from start to finish.
Separate page problems from platform limits
Walk through your important journeys on a phone and a desktop. Record the page, the problem, and whether it can be reproduced. Include the work your team does behind the page; a site can look acceptable while routine updates remain unnecessarily difficult.
- Can visitors understand the offer without an explanation from you?
- Do navigation, forms, and confirmation messages work?
- Can the team update essential content reliably?
- Can the platform support the languages and integrations you actually need?
Use a bounded repair to test the diagnosis
Hypothetical example, not a client project: a business receives vague enquiries because its service page omits scope and its form asks only for a name. Rewrite that page and add a relevant question before proposing a new platform. Test delivery, then review whether the enquiries contain the information needed for a response. Set a review date; low traffic may mean there is not enough evidence yet.
Rebuild when the underlying constraint is demonstrated
A rebuild becomes more reasonable when required changes depend on unsupported software, fragile workarounds, or a structure that cannot accommodate the agreed journeys. Ask for a comparison of repair and rebuild scope, including content migration, integrations, ongoing editing, and maintenance. A new design alone does not resolve an unclear offer or an unanswered enquiry.
Treat existing URLs as part of the project
If URLs will change, require a map from old pages to relevant replacements and test the redirects. Google’s migration guidance recommends server-side permanent redirects where possible and monitoring after the move. Search visibility can fluctuate during migration. Keep working URLs when there is no business reason to change them, and include a recovery plan for launch problems.
Prepare a brief before requesting a quote
Collect the current URL, priority journeys, observed failures, content owner, and required connections. Ask for a proposal with explicit acceptance checks and a separate explanation of recurring costs. Chronicle quotes projects in USD after scope is agreed. If a content correction or a form fix is sufficient, keep the existing site and reassess before commissioning a rebuild.
Before you commit
Your decision checklist
- Define the business task before discussing appearance.
- Try a contained repair when the constraint is local.
- Compare migration and maintenance alongside implementation.
- Approve a rebuild only against clear acceptance checks.
Sources and further reading
The next step
Website design and development
If this is the right direction for your business, start with a clear scope, testing plan, and handover.