A website can look old while its content model, integrations, search visibility, and conversion path still work. It can also look acceptable while a brittle platform blocks releases, measurement, accessibility, or safe operations. Measure the problem before choosing the size of the project. A rebuild should be the conclusion of an evidence chain, not the first response to frustration.
Define the decision and the alternatives
Write the decision in one sentence: keep the current platform, make targeted repairs, redesign the presentation, rebuild the technical foundation, or run a bounded pilot. Record who owns the decision, what budget is at risk, and what would count as enough evidence to pause.
Do not compare “old site” with “new site.” Compare alternative interventions against the same business outcomes. A navigation repair, template refactor, tracking fix, content rewrite, or platform migration may solve different parts of the problem at different levels of risk.
Create the Website Rebuild Evidence Ledger
| Evidence layer | What to record | Decision it supports | | — | — | — | | Business | qualified enquiries, sales cycle, service mix, owner constraint | whether the problem is commercially material | | Journey | entry page, task, friction, form or booking step | whether users can complete the job | | Content | page purpose, freshness, proof, gaps, duplication | whether content or structure is the cause | | Technical | platform limits, integrations, security, performance, access | whether repair is feasible | | Search | indexed URLs, redirects, canonicals, queries, internal links | migration and visibility risk | | Operations | editors, release process, support, testing, rollback | whether the new system can be run safely | | Economics | build cost, delay, opportunity cost, capacity | whether the decision is affordable |
Give every row an evidence date, owner, confidence, alternative explanation, proposed test, and stop rule. A ledger that only records reasons to rebuild is advocacy, not diagnosis.
Measure business impact before page metrics
Start with the pages and journeys that affect a real decision: request, qualification, booking, purchase, or renewal. Define the outcome locally. A form submit, a sales-qualified lead, and a paid customer are not interchangeable.
Segment by page group, device, market, new or returning visitor, and entry source. Compare a meaningful period with an annotated baseline. Mark launches, price changes, outages, campaign shifts, staffing changes, and tracking edits. If the business outcome is unchanged, a visual complaint may not justify a full rebuild.
Use event data to describe observable interactions. Google’s GA4 event guidance explains event and parameter design, but it does not define your qualification or revenue truth. Reconcile a sample of events with forms, calls, bookings, CRM stages, and finance records before using them in the case.
Measure content and journey fit
For the highest-value page groups, record the user task, promise, evidence, next step, and failure point. Review whether the page answers the question before the visitor reaches a form. A rebuild will not fix an unclear offer, missing proof, or an intake process that rejects the wrong leads.
Map the path from organic or paid entry to the first meaningful action. Record exits, backtracking, error states, slow steps, and requests for clarification. Qualitative evidence can be a support transcript, sales note, moderated task, or owner observation; label it as qualitative and do not turn a handful of comments into a prevalence claim.
Measure technical constraints and migration risk
Record the platform capability that is actually blocking work: a missing integration, unsafe update path, unmanageable template, permission defect, performance issue, accessibility barrier, or inability to test. “The stack is old” is a context, not a failure mode.
Inventory URL patterns, templates, metadata, canonicals, redirects, structured data, internal links, media, forms, analytics, and external integrations. Google’s site-move guidance treats URL changes as a migration that requires mapping, redirects, verification, and monitoring. Keep a representative URL set rather than trusting a page count.
Measure field performance and user conditions instead of relying on a single lab score. The Web Vitals guidance describes user-centred performance signals; record device, template, connection, and field-versus-lab context. A score is an input to a diagnosis, not a rebuild trigger by itself.
Measure delivery capacity and reversibility
Ask who can approve content, test forms, validate redirects, maintain integrations, and respond to defects. Record the owner for each dependency and the smallest rollback that would restore a working journey.
Compare the rebuild plan with current release capacity. If the team cannot preserve content, QA critical paths, or monitor the migration, the risk may exceed the expected benefit. A smaller repair with an explicit follow-up test can be the more responsible decision.
Measure reversibility at the level of a user task, not only at the level of a server snapshot. Record how the team would restore a working enquiry form, a booking path, a key URL, an analytics property, and an editor workflow. Note the time, access, dependency, and owner for each recovery step. If nobody can explain how a failed release would be detected and contained, the project is not ready for a large change.
Also record what the rebuild would make harder. A new component system may reduce design debt but increase editorial effort; a new integration may improve automation but create a support dependency; a URL consolidation may simplify navigation but remove useful intent coverage. Include these trade-offs in the ledger rather than counting only the visible improvements.
Use a decision table and stop rule
| Pattern | Plausible explanation | Next measurement | Provisional choice | | — | — | — | — | | low enquiries, healthy traffic | offer, proof, or intake friction | page and sales-record review | repair journey first | | strong demand, broken releases | platform or process constraint | capability and incident ledger | consider rebuild | | search loss after URL changes | migration or canonical error | URL map and Search Console sample | pause expansion, repair | | isolated slow template | component or media issue | field sample by template | targeted optimization |
Approve a rebuild only when the ledger identifies a material root problem, compares a cheaper alternative, assigns owners, and defines migration acceptance criteria. Keep the baseline and do not delete it after launch. If the evidence cannot distinguish a rebuild from a focused repair, hold the project and run the cheapest discriminating test.
How did this article land?
Choose one reaction. You can change it anytime.
