Redesign or rebuild? Five signals to make the right call

"My site is too old, I want to redo it" — another owner said this last week.

I asked three questions: What does the page look like? What CMS is the admin running on? Who do you call to add a new page? Five minutes later I told him: you don't need to redo it. You need a redesign. That saves $7,000 and three months.

Redesign and rebuild are two completely different engineering projects, but clients use the words interchangeably. This post breaks down: when to redesign, when a rebuild is unavoidable, and how to tell.

Definition: redesign vs rebuild

Redesign: visual refresh, UX adjustments, a few new features — but the underlying architecture doesn't move.

• Same WordPress, same database, same admin
• CSS changes, component swaps, new pages
• 30-80 hours, $2,000-$7,000
• 2-6 weeks to launch

Rebuild: from-zero, often on a different stack, CMS, or host.

• Replace WordPress with Next.js; migrate from Wix to Webflow; build a custom backend instead of a packaged one
• Data migration, URL redirects, SEO rebuilding all required
• 200-600 hours, $9,000-$50,000
• 8-20 weeks

3-7× the cost, 3-5× the time. This is not a casual decision.

Five signals: redesign or rebuild?

Signal 1 · Is your pain "visual" or "structural"?

Ask yourself: when you complain about your site, what's the subject?

• "Looks ugly" / "design is dated" / "colours are off" → visual problems → redesign
• "Adding a new page requires the original developer" / "Admin is unusable" / "Search is broken" → structural problems → leans rebuild

90% of visual problems can be fixed by a redesign because the front-end can be changed independently. Structural problems usually require touching the backend — and that's where redesign hits a wall.

Signal 2 · Does the admin feel "stuck"?

Open your admin and try three things:

1. Create a new standalone page (not a blog post — a new top-level page)
2. Reorder the navigation
3. Change a footer link

If you can't do these / need a developer for each one, the original build never planned for client maintainability. Redesign here is usually a band-aid — the architecture itself limits what's fixable. Lean rebuild.

If you can do them and only the visuals are off — redesign solves it.

Signal 3 · Where's the source code, and what's its quality?

Code not in your hands → likely a rebuild (no one else can change it).

If you have the code, ask the next developer three questions:

1. "Open it up — how's the code structured?"
2. "Are the dependencies still maintained?"
3. "How long to redesign one component?"

A developer who's willing, gives sane hour estimates (1-3 hours per component) → redesign is viable.
A developer who frowns, says "I'd recommend starting from scratch," and quotes astronomical numbers → probably not a scam, the code is genuinely that bad.

But watch for the inverse: some developers default to rewrite-everything mode — they look at someone else's code and want to scrap it. Get a second opinion. If both say rebuild, rebuild; if one says rebuild and one says redesign, get specific reasons.

Signal 4 · Is the SEO traffic worth preserving?

Often overlooked, but for a site with traffic, this is decisive.

Rebuild = URLs change, content structure changes, sometimes hosts change. Organic traffic typically drops 30-70% in the first 1-3 months, then slowly recovers — and "recovery" can take 6-12 months.

If your site has:

• Under 500 monthly organic visits → rebuild is fine, traffic was light anyway
• 500-3,000 monthly organic visits → redesign preferred; if rebuilding, get someone serious on redirects
• 3,000+ monthly organic visits → strongly redesign. The rebuild cost is half a year of revenue.

Worst case I've seen: an ecommerce site doing $250K/year rebuilt to "modernise the stack." Organic traffic dropped 60%, took six months to recover. The lost revenue in those six months would have funded five redesigns.

Signal 5 · Can the current architecture support what you want next?

This is the line where rebuild becomes unavoidable.

Examples — your site is currently "info + contact form," and you want to add:

• Member system + order management → needs a backend → if it's currently static, must rebuild
• Multi-language (en + zh + ja) → most CMS multi-lang plugins are bad → rebuild recommended
• Subscriptions + monthly auto-charges → needs payment + scheduling → must rebuild
• Blog with tags + search → most CMSes have this built-in → redesign works

Ask your developer: "I want to add X, Y, Z — can the current architecture support it?" If the answer is "no, this needs to come from the foundation" → rebuild. If the answer is "yes, with some effort" → redesign.

Underrated upsides of redesign

People prefer rebuild because "scrap and restart" feels satisfying. But redesign has real advantages:

1. SEO equity preserved — existing URLs, ranking, backlinks all stay
2. Data preserved — posts, members, orders don't migrate
3. Fast — 2-6 weeks vs rebuild's 8-20
4. Cheap — 3-5× cost difference
5. Low risk — if something breaks, roll back to the old version

If your core architecture isn't rotted, redesign is usually the smarter call.

When rebuild is the only answer

Some situations a redesign genuinely can't fix:

• WordPress theme abandoned + a stack of outdated plugins — security time bomb
• Site speed dragging Google rankings down, and the cause is foundational (Wix / Squarespace and similar locked platforms — you can't fix what you can't access)
• Database designed wrong from day one (e.g. all products in one 100-column table)
• The features you want next require a completely different stack

Forcing a redesign here is patching a leaking roof — fix one hole, another opens. Rebuild is the long-term cheaper option.

Quick decision flow for owners

Five yes/no questions:

1. Is the pain mostly visual / UX? (yes → redesign +1)
2. Can you / your team operate the admin? (yes → redesign +1)
3. Is source code in your hands and inheritable? (yes → redesign +1)
4. Does the site have over 1,000 monthly organic visits? (yes → redesign +1, because rebuild loses traffic)
5. Can the current architecture support what you want to add? (yes → redesign +1)

• Redesign 4-5: redesign with confidence
• Redesign 2-3: case-by-case, possibly a rebuild of specific modules (hybrid approach)
• Redesign 0-1: rebuild is more rational

Stop using "scrap and rebuild" to escape reality

A rebuild feels like leaving the past behind, but the real bad problems follow you into the new version — a site with unclear positioning, an unfinished customer journey, content that was never optimised for SEO. A new stack saves none of that.

Next time someone (including me) says "just rebuild it," counter with three questions:

• Why won't a redesign solve this? What specifically is the gap?
• What capabilities will I gain post-rebuild?
• How is the SEO and data being handled?

Vague answers = unnecessary work being sold to you.

If you're unsure whether your site needs a redesign or a rebuild, hop on a 15-min call. Send me the URL — I'll tell you straight, and if redesign is the answer, I'll say redesign.