Latest · Interpreted · Published 11 Sep 2026 · GA Applications editorial
Most redesigns treat the symptom that embarrasses, not the one that costs.
The strongest reasons to replace a website are broken decisions and hidden operational risk: enquiries going nowhere, content nobody can update, search equity one migration away from loss. A dated look is usually the weakest reason, and the cheapest to fix. The triage board below sorts symptoms into repair, redesign or leave-alone, with the evidence each call requires.
The triage calls are GA practitioner judgement, labelled inference. No invented failure rates appear on this page.
Recognition
The dated-look trap
Most redesigns are triggered by embarrassment: the owner sees a competitor’s newer site and feels the gap. Embarrassment is real, but it is not evidence. The problems that actually cost money rarely show in a screenshot — forms that fail silently, content nobody can update without a developer, decision paths that strand the visitor, search value accumulated in URLs nobody has mapped.
Replacing a site for fashion while leaving broken handoffs intact produces a more attractive version of the same problem, at full project cost. And a rebuild is itself a risk event: anything the new site does not deliberately carry — rankings, bookmarks, familiar navigation — is destroyed by default.
The question worth asking is not “do we need a new website?” It is “which symptom are we treating, and what evidence says this is the cause?”
Symptom to smallest intervention
The repair-or-redesign triage board
Seven common symptoms, their likely causes, the smallest credible intervention, and the evidence that would confirm the call.
| Symptom | Likely cause | Smallest intervention | Evidence required |
|---|---|---|---|
| “It looks old” | Visual layer aged; structure possibly fine | Restyle: type, colour, imagery, spacing | Enquiry or replay data showing the look is the actual barrier |
| Enquiries arrive but vanish | Notification path broken or unowned | Fix the route to a human; test weekly | Form test submissions reach a person, reliably |
| Simple edits take weeks | Wrong tool or a locked-down build | Move content to an editable layer | A staff member can publish a change unaided |
| Traffic fine, enquiries thin | Decision path broken; evidence missing | Rebuild key pages around the trust sequence | Replayed visits showing where people stall |
| Slow and getting slower | Accumulated plugins, unoptimised media | Performance pass before any rebuild | Field data below the Core Web Vitals thresholds |
| Cannot express what the business now does | Structure no longer matches the operation | Redesign with a migration plan | Content inventory and URL map agreed first |
| Nobody knows what the site does | No measurement, no owner | Install measurement; assign an owner | A monthly review exists and actually happens |
Only the sixth symptom reliably justifies a full redesign on its own. GA judgement; your evidence may reorder the board.
The honest case
When a redesign genuinely is the answer
Redesign earns its cost when the structure itself is wrong: the site cannot express what the business now does, the platform blocks necessary change, or accumulated search equity needs a controlled migration to survive. Even then, a redesign is a migration of meaning, trust and search equity — run it with a risk register, not a mood board.
The stable checklist for that decision lives in the website redesign checklist, and the engagement it describes is the redesign service. This article’s job is narrower: stop you funding the wrong intervention.
Four steps
Before you sign a redesign quote
An afternoon of homework that routinely saves the difference between a repair and a rebuild.
Inventory what exists
Every URL, its traffic, its enquiries, its inbound links. You cannot protect value you have not counted.
Replay the visitor journey
Five real tasks on a phone. Note where each stalls. The stall points are the brief — not the colour scheme.
Price the repairs separately
Ask any provider to split repair items from rebuild items. If they cannot or will not, that is your answer.
Set the migration plan before design starts
Redirect map, content carry-over, measurement continuity. Design is the last step of a redesign, not the first.
The hidden risk in every redesign
A rebuild destroys whatever it does not deliberately carry: search rankings attached to old URLs, bookmarked pages, learned navigation, logged-in histories. The risk register is not bureaucracy; it is the difference between a migration and an amputation. Any provider who starts in the design tool has skipped the part that protects you.
Evidence honesty
Sources, method and what would change this
- Inference
Triage board
The symptom-to-cause mapping is GA practitioner pattern recognition across NZ business sites, not a controlled sample. Frequencies are deliberately left unquantified.
GA Applications editorial
- Verified fact
Performance threshold reference
“Slow” on the board refers to the published Core Web Vitals thresholds: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 at the 75th percentile of real visits.
web.dev, 7 May 2025
- Verified fact
Repair-first sequence
The repair-before-rebuild sequence reflects GA’s documented scoping method for redesign engagements, including migration risk registers.
GA Applications method documentation
- Proposal
What would change this conclusion
If repair-first engagements in GA’s own work stopped outperforming rebuild-first ones on enquiry outcomes, the board would be reweighted and the change dated here.
GA Applications editorial
Get a triage before a quote
Send your URL and the symptom that prompted the thought. GA replies with the triage row it matches, the evidence worth gathering, and whether a redesign is even on the table.
Sometimes the reply is “restyle for a tenth of the price”. That answer is the point of triage.