Redesign when the platform underneath is sound and the problem is presentation, content or navigation. Rebuild when the foundation itself is the problem: unsupported software, a page builder you can’t make fast, or features the platform can’t carry. It is an architecture decision more than an aesthetic one, and you will live with the result for years, so it deserves more than a look at the homepage.

Here is the framework we use to help clients make it.

The definitions

Redesign

  • Keep the existing platform (often WordPress)
  • New theme or visual design
  • Reorganized content
  • Features added or improved incrementally
  • Existing data structure preserved

Rebuild

  • A new technical foundation
  • The site re-architected from the ground up
  • A modern framework (Astro, Next.js or similar), or a clean new WordPress build
  • Content migrated and cleaned up
  • A fresh start on infrastructure

A rebuild usually costs more and takes longer up front. Whether it costs more over three years is a separate question, covered below.

The decision framework

Factor 1: platform health

Redesign if:

  • WordPress core, theme and plugins are on current, supported releases
  • PHP is a version that still receives security updates (check PHP’s supported versions)
  • Updates apply without drama
  • The codebase is reasonably clean

Rebuild if:

  • The site runs an end-of-life PHP version or a long-outdated WordPress release
  • Updates are skipped because they break things
  • Layers of technical debt make every change slow and risky

Why it matters: an unsupported platform becomes a liability. Every update risks breaking something, and every new feature needs a workaround.

Factor 2: performance

Test with PageSpeed Insights, and look at the field data (real visitors), not just the lab score.

Redesign if:

  • Core Web Vitals pass on mobile
  • Pages are reasonably light
  • Slowness comes from fixable things: oversized images, a few heavy plugins, missing caching

Rebuild if:

  • Core Web Vitals fail and caching hasn’t fixed them
  • Pages are heavy because of the theme or a page builder itself
  • Every speed fix is undone by the next content change

A real example: Roseville Landscape Material Supply was on WordPress when we began working with it in 2021, and it was rebuilt in Astro in 2024. Static generation removed database queries, PHP and plugin overhead from every request.

Factor 3: content management needs

Redesign (and stay on a full CMS) if:

  • Several people edit content
  • Content changes daily or weekly
  • Editors are non-technical
  • Content workflows are complex (reviews, scheduling, permissions)

A rebuild on a lighter stack fits if:

  • Content changes infrequently
  • The team is comfortable with Git, or happy for a developer to make changes
  • Content as code is acceptable
  • Speed matters more than editing convenience

WordPress is a powerful CMS. If you need it, keep it. But if you update content once a month and fight a bloated admin every day, you are paying for capability you don’t use.

Factor 4: security and compliance

Redesign if:

  • The platform is maintained and patched
  • Plugins are kept up to date
  • No regulatory requirements apply to the site

Rebuild if:

  • The site runs end-of-life software
  • It can’t be updated without breaking
  • Compliance obligations (HIPAA, SOC 2, PCI DSS) touch what the site does, and the current stack can’t show the controls they require

Why it matters: a statically generated site has a smaller attack surface. There is no database or PHP running behind public pages, no plugin code executing on each request, and a CDN in front absorbs traffic spikes. (A framework that renders on a server, as Next.js often does, keeps some of that surface.) Compliance is about the whole system, not just the frontend, but a smaller surface makes the controls easier to prove.

Factor 5: feature complexity

Redesign if:

  • The site is mostly content and forms
  • Ecommerce is standard
  • Custom functionality is minimal

Rebuild if:

  • You need custom applications
  • Integrations are complex (CRM, ERP, billing)
  • Users log in to accounts or portals
  • Features are real-time

The rule: if well-maintained WordPress plugins can handle it, redesign. If you need custom services and integrations the platform wasn’t built for, rebuild.

Factor 6: mobile experience

Redesign if:

  • The responsive design works well
  • Mobile speed is acceptable
  • Touch interactions work

Rebuild if:

  • The design is effectively desktop-only
  • Mobile was an afterthought
  • You need app-like features

Check your analytics for the mobile share of visitors. For most sites it is large enough that a broken mobile experience loses real customers.

The running costs people forget

Build cost is the number everyone compares. The decision turns on what each option costs to run for three years after launch.

Running costs of keeping a heavy platform

  • Plugin and theme license renewals
  • Hosting sized for a heavy WordPress install
  • Developer time for updates, conflicts and fixes
  • Security monitoring and cleanup
  • Backups

Running costs of a rebuild

  • The team’s learning curve on a new workflow
  • Re-entering content, if it can’t be migrated cleanly
  • SEO migration risk, if redirects and URLs aren’t handled properly
  • Keeping integrations up to date

Add three years of running costs to each option’s build cost before comparing. A rebuild that costs more up front can be cheaper over three years if it removes heavy hosting, license renewals and maintenance hours; a redesign stays cheaper when the platform is healthy and its running costs are low.

The hybrid approach

Sometimes the answer is both.

Phase 1: headless WordPress

  • Keep the WordPress admin, so editors keep their workflow
  • Rebuild the frontend in Astro for speed
  • Get the performance without losing editing convenience

Phase 2: gradual migration, if it makes sense

  • Move content to Markdown or another CMS section by section
  • Retire WordPress over a planned period
  • No big-bang cutover

This works when:

  • The team is split on the platform
  • The business can’t afford disruption
  • You want to lower the risk of the change

Our headless CMS decision framework covers when that split is worth it.

Three illustrative scenarios

These are typical patterns, not client case studies.

A local service business

Situation: an eight-year-old WordPress site, a handful of content updates a year, dozens of plugins, and pages that are slow on a phone.

Likely decision: rebuild on a static stack such as Astro.

Reasoning: infrequent updates don’t justify the weight and upkeep of the current setup.

A content publisher

Situation: a three-year-old WordPress site, many articles a week, several editors and a slow admin panel.

Likely decision: redesign and optimize.

Reasoning: the CMS is essential to the editorial workflow. A lighter theme, object caching and a CDN address the speed problem without disrupting the newsroom.

A SaaS company’s marketing site

Situation: a marketing site on WordPress that is five or more years old, needs to integrate with the product’s API, and falls under SOC 2 controls.

Likely decision: rebuild, often with a static marketing site and a small set of server functions for the product features.

Reasoning: the security requirements and custom features fit a modern stack better than a plugin-based one.

The five-question gut check

When in doubt, ask:

  1. Is maintenance costing more than a rebuild would? If yes, rebuild.
  2. Do we need WordPress’s CMS specifically? If no, a rebuild is an option. If yes, redesign or go headless.
  3. Is performance a competitive differentiator? If yes, lean toward rebuilding. If no, either can work.
  4. Will this decision haunt us in three years? If the redesign feels like kicking the can down the road, rebuild. If the rebuild feels like a leap the team isn’t ready for, redesign.
  5. What does the three-year cost of ownership show? Do the math, then trust the math.

How we make the recommendation

When a client asks us, we start with a Performance & Architecture Audit: a paid, fixed-scope diagnostic of performance, architecture, technical debt and security surface, delivered as a prioritized findings report. It ends in a written verdict (rebuild, targeted refactor, or leave it alone), and we go through the findings with you on a working call.

The recommendation is based on what the audit finds, and sometimes the answer is “do nothing yet.”

The worst decision is indecision

A common pattern:

  • Year 1: “We need to fix this.”
  • Year 2: “We need to fix this.”
  • Year 3: “We really need to fix this.”
  • Year 4: an emergency rebuild, under pressure, after the problems have compounded.

Limping along has a cost. Calculate it.

Next steps

If you’re facing this decision:

  1. Run PageSpeed Insights and note the field data for mobile.
  2. Check your WordPress, theme, plugin and PHP versions against what is still supported.
  3. Add up current maintenance costs, honestly.
  4. Project where the business will be in three years.
  5. Get an independent technical audit.

Then you’ll know. For the cost of putting it off, read the business cost of WordPress technical debt.