A website can look outdated while its foundations remain sound, or look polished while content, performance and operations are failing underneath. The right decision is not driven by appearance alone. A redesign changes the experience within a viable foundation; a rebuild changes the foundation because it blocks important outcomes. The assessment should make that boundary visible before scope and budget are fixed.
Diagnose the problem before naming the project
Start with evidence from the current site: critical user journeys, search visibility, content publishing, accessibility, page speed, integrations and support effort. Separate symptoms from causes. Low conversion may come from unclear positioning, a broken mobile journey, weak traffic quality or an unreliable checkout. Calling every problem a redesign creates a visual brief before the business and technical constraints are understood.
Identify what is still worth preserving
A redesign is usually appropriate when the platform is secure, maintainable and able to support the required information architecture. Existing URLs, content, integrations and analytics history may carry significant value. Preserve what works and change the layers that limit comprehension or task completion. A rebuild becomes more likely when upgrades are blocked, templates cannot support needed structures, performance fixes repeatedly fail or operational work depends on fragile manual patches.
Audit content and SEO before moving URLs
Create an inventory of important pages, their purpose, traffic, links, conversions and current status. Decide what to keep, improve, merge, redirect or retire. Map old URLs to final destinations before launch and keep each redirect direct. Rebuilding without a content model simply moves old inconsistency into new templates. A useful migration protects established demand while removing pages that no longer serve a clear audience or decision.
Plan delivery around risk, not page count
Group work by dependencies: content model, design system, core templates, integrations, data migration and release controls. Prototype the riskiest journey early. If the existing platform can evolve safely, release improvements in stages and measure their effect. If a rebuild is required, define a content freeze, migration rehearsal, rollback path and ownership for launch day. Page count alone does not describe integration, permission or editorial complexity.
Validate the operating model after launch
A successful launch is not only a visual comparison. Editors must be able to publish safely, redirects and forms must work, monitoring must expose errors, and the team must know who owns updates. Compare performance, completion of critical journeys and support effort with the baseline. Keep a controlled improvement backlog instead of reopening the entire redesign whenever a new request appears.