The choice of website rebuild vs redesign depends on what is wrong. A repair fixes a specific fault. A refresh changes a few visible details. A redesign changes the visitor experience. A rebuild replaces more of the system behind it.
These are working definitions, not fixed industry rules. Start with the smallest change that can solve the problem you can show, then ask each provider what its proposal actually includes.
The short answer
- Trace the problem before choosing repair, refresh, redesign or rebuild.
- Ask each provider why a smaller change would not solve it.
- Keep useful content, stable URLs, account ownership and needed business records.
How this guide was made
The scope choices and fictional cases are original decision aids informed by user research, accessibility planning and site move guidance. These are working definitions, not industry standards or a diagnosis of your website. No outcome or cost saving is claimed.
Sources checked .
Collect evidence before choosing
Write down what works, what fails and what you need next. GOV.UK user research guidance supports starting from real tasks and evidence. A site's age or style alone does not show which part needs replacing.
Source for this section: [1] GOV.UK guidance on learning user needs
What fails for visitors
Ask someone to find a service and explain how to start. Record the page, action and point of confusion. The menu label may be the problem even when the service content is accurate.
What fails for editors
Ask a staff member to change an opening time in a safe draft. If they cannot find the field, check permissions and training before assuming the platform needs replacing.
What the system cannot support
Name the required function and ask a qualified person to check its support. Separate an unsupported dependency from one wrong setting. Include the effort and risk of keeping or replacing it.
Keep accessibility in every scope
W3C treats accessibility as ongoing work with planning and owners. Neither a new theme nor a rebuild proves access needs have been met. Include review time in a repair, refresh or larger project.
Source for this section: [2] W3C guidance on planning accessibility
Choose a scope from evidence
Use this table to start a conversation. It is a planning aid, not a remote diagnosis. More than one row may apply to your site.
| Scope | Evidence that may support it | Next action | Why not go larger yet |
|---|---|---|---|
| Repair | Wrong phone number or broken inbox setting | Correct it and test the contact route | A wider design does not fix an uncorrected setting |
| Refresh | Readable content in a cramped layout | Adjust text and spacing, then check on a phone | Page structure may still work |
| Redesign | People cannot find a service on a supported site | Review menu, page order and wording | The platform may already meet the need |
| Rebuild | Unsupported system cannot meet a critical need | Get a technical scope and data move plan | Confirm repair options before committing |
A refresh changes a few things
A refresh keeps most of the site in place. You might make text easier to read, replace old photos or clarify the main heading. It is worth considering when customers can already find what they need and the site is easy to maintain.
For example, old photos and cramped spacing may justify a refresh when the offer and page order remain useful. Agree which parts will change and check that their contact links still work.
Check the result before adding more work. Ask someone to find a service and explain how to enquire. If the task is still hard, the issue may go beyond the surface.
A redesign changes the visitor experience
A redesign can change menus, page order, copy and layout while keeping the current platform. It should have a clear visitor task to improve, such as finding the right service and requesting a quote.
New colors alone do not resolve a confusing page plan. Write down the point where the reader gets lost so the builder can change the cause.
A rebuild changes more of the system
A rebuild may replace the platform, code or content system. It can make sense when a critical function cannot be maintained or supported on the current setup. Get a technical review before treating that as proven.
A replacement is not automatically faster, safer or better for search. Ask which limitation it removes and how content, forms and records will move.
Ask what the project label includes
Give each provider the same problem list. Ask them to separate essential work from optional changes. Have them explain why the smaller option would or would not meet your needs.
If page addresses change, ask for a move plan. Google's site move guide explains the work involved and suggests separating major changes when practical. A search handover deserves its own place in the scope.
- Which pages and functions will change?
- Will the platform or page addresses change?
- Who will move and check the content?
- What happens to forms and outside tools?
- Who owns the accounts and handles future updates?
- What checks must pass before launch?
- What evidence would rule out the smaller option?
- How will we know the change solved the original problem?
Source for this section: [3] Google guidance on site moves
Write down the smallest useful next step
Finish with a short decision note. State the problem, the evidence and the work you plan to approve. Include what you are keeping and what can wait.
If the cause is unclear, pay for or request a focused review before agreeing to a large build. Once the scope is clear, turn it into a website brief. That gives the builder a target you can check together.
Compare three fictional decisions
These examples show different choices. They are not client projects or tested results.
| Situation | Smallest useful decision | How to check it |
|---|---|---|
| A supported gardening site has a confusing menu | Redesign the menu and page order | A new visitor finds the right service |
| A consultant lists an old phone number | Repair the number and related contact links | The correct number is visible and the call link matches |
| An unsupported platform cannot support a required integration | Scope a rebuild after technical review | The replacement passes the agreed integration test |
Write down what stays
Keep approved content, media you own, useful page addresses, business account control and records needed for the service. Record the export or move owner for each item. The migration guide covers execution when the addresses or platform change.
Sources and further reading
Numbered links beside each section point to the source used there. Our examples and checklists are guidance from SnapRebuild. They are not claims of test results. Product details can change.
SnapRebuild sells a website building service. These guides are published under our editorial team name and use AI for research and writing. This is not a claim of independent expert review. Read how we make and update our content. Found an error? Tell us.
Ready for a fresh start?
Bring your website or your business idea. Explore a SnapRebuild preview and decide what comes next.
Try your free preview