Rebuild when the site prevents the changes your business needs. Repair it when a focused change can do the job. Low enquiry volume, an old design or a long list of complaints is a reason to investigate, not a verdict on its own.
The expensive mistake is choosing the project before identifying the constraint. A new design will not fix an offer aimed at the wrong audience. A paragraph change will not solve a platform that cannot support the required service structure or integrations.
Start with what the business needs to do next. Then ask what can be retained, what must change and whether the current site can support that work reliably.
Describe the business change first
Use a specific requirement: “Buyers need to choose between our advisory and implementation services”, “We need to publish an approved service without rebuilding the whole layout”, or “A received enquiry must reach the right team.”
These are illustrative requirements. Your own should come from the services you sell, the questions buyers ask and the work your team needs to carry out.
If the only symptom is traffic without suitable enquiries, use the enquiry diagnosis first. If the choice is between publishing and improving existing content, use more content or better pages. This page helps once you need to judge the scale of website work.
What can be repaired, and what points to a rebuild?
| Requirement or constraint | A focused repair may be enough when… | A rebuild deserves consideration when… |
|---|---|---|
| Explain the services buyers can choose. | Current pages and navigation can support clearer scope, proof and links. | The templates or architecture cannot support the required service structure without extensive replacement. |
| Keep the site accurate as the business changes. | Editing problems can be solved with permissions, training or a small template improvement. | Necessary updates repeatedly require fragile workarounds, and repairing the system is less practical than replacing it. |
| Let buyers enquire and reach the right team. | The issue is an isolated form, integration or routing fault. | Required integrations conflict with the current platform and a technical review supports replacement. |
| Make important pages usable and accessible. | Specific layout, performance or interaction defects have feasible fixes. | Problems are embedded across the templates and a scoped comparison favours replacing them. |
| Support the next stage of the business. | Existing content and structure can be adapted without losing useful material. | A materially different service model requires extensive structural and technical changes together. |
Ask the implementation team to show the constraint and compare the two routes. “The site is dated” is not a scope. “The service templates cannot accommodate these requirements, and here is the repair-versus-replacement estimate” gives you something to evaluate.
Compare the complete job, including what happens after launch
A repair quote and a rebuild quote are only comparable when they address the same requirements. Ask both to explain:
- What changes: pages, content, templates, navigation, platform and integrations.
- What stays: useful URLs, existing answers, proof, downloads and business records.
- What your team supplies: expert input, approvals, access and review time.
- How it is accepted: checks for the buyer journey, accessibility, forms, search controls and handover.
- Who supports it: responsibility for fixes, hosting, maintenance and later changes.
Include the interruption to your team and the cost of maintaining workarounds. A smaller initial quote can leave substantial work behind. A larger replacement project can also solve problems you do not have. Compare the work against the requirement rather than treating either route as automatically better value.
Use a repair-or-rebuild decision record
Put the alternatives beside the same requirement before comparing quotes. The record below keeps the observed problem, proposed work, feasibility evidence and remaining questions together. It is a working document for you and your delivery partner, with no score that automatically recommends a rebuild.
| File | What you can do with it |
|---|---|
| Decision workbook, Markdown | Follow the instructions, read the field guide and fictional example, then copy the blank recommendation note. |
| Blank comparison record, CSV | Compare repair, structural improvement and replacement against the same task. |
| Worked comparison record, CSV | Inspect six fictional options for three requirements, including a repair candidate and two decisions needing investigation. |
These static files do not inspect a website, calculate a recommendation or submit entries. Open Markdown in a text editor or copy it into a document. Import CSV as UTF-8 and treat the columns as text. Keep private evidence in your own workspace and leave credentials out of the record.
Separate the symptom from the restriction
“The team cannot update a service page” describes a problem. It does not establish whether the cause is permissions, training, a template or the platform. Ask the delivery partner to demonstrate the task, name the actual restriction and explain which feasible alternatives were considered.
For a buyer journey, observe a realistic task: find the relevant service, understand its boundaries and reach the enquiry step. GOV.UK’s usability-testing guidance describes observing users attempting tasks. The difficulty you observe still needs investigation before choosing the technical remedy.
For performance evidence, retain the page or origin, device, date and whether the result is a lab test or field data. Google’s PageSpeed Insights documentation explains those differences. A missing field report is an unknown, and one lab result does not establish that replacement is necessary.
Keep a repair and an unresolved decision visible
In the fictional worked record, the existing templates are assumed to support distinct service pages. That makes clearer service structure a candidate for repair within the current site. A separate claim that the platform prevents editing has no demonstrated cause, so that decision remains open. Performance evidence is also incomplete. No real inspection, repair or rebuild has occurred in the exercise.
The recommendation is to request a bounded repair proposal and investigate the two open questions. It does not approve a whole-site replacement or certify that a repair will succeed. A different record could justify replacement if it demonstrates the required changes and why feasible repairs do not meet them.
For your own decision, record what each option keeps and changes, owner input, a comparable scope for estimates, ongoing responsibilities and the same acceptance checks. Mark missing terms as unknown. End with the next action, its owner and the evidence that would change the recommendation. Further investigation or deferring nonessential work can be the right next step.
What our HR advisory rebuild actually changed
The confidential HR advisory case began with several reasons to hire the firm presented through one broad page. We reorganised the offer into eight service choices and a second route starting from the buyer’s problem.
That is a concrete structural change: a buyer seeking recruiting support or compensation advice can find a relevant place to start. The case shows the implemented navigation and recorded search figures.
It does not make eight service choices the right structure for your business. The useful question is whether your current site gives each meaningful buying decision enough room, and whether that can be achieved by improving what you already have.
Put preservation in the scope before design starts
Start with an inventory of the pages and assets people already use. Include service pages, useful articles, linked downloads, images, forms and essential integrations. Agree what remains, what changes and who checks it.
Keep existing URLs where they still make sense. If addresses must change, define the destination for each important old URL, use appropriate permanent redirects and update internal links, canonicals and the sitemap. Avoid sending unrelated old pages to the homepage simply because it is convenient.
Google’s site-move guidance covers these steps and recommends separating major changes where practical. It also explains that rankings can fluctuate while a move is processed.
Before launch, check the actual forms and receipt, mobile journeys, key URLs and search indexing settings. After launch, verify them on the public site, monitor errors and compare consistent search records. A design preview alone does not establish that the new site works in production.
Use the rebuild preservation pack to retain URL decisions, launch evidence and unresolved checks with your delivery partner.
Leave the conversation with a recommendation you can inspect
A useful recommendation names the constraint, the proposed route, what will be retained and the work needed to make the change safely. It should also explain why the alternative route was not selected.
Bring one service page, an example of something your team cannot do on the current site and any deadline that affects the decision. You do not need to decide on a platform before that discussion.
Use the provider comparison worksheet to record scope and responsibilities. Our website rebuild service explains our separately quoted route; the AI SEO plan explains agreed Setup followed by ongoing work.