Choose a redesign when the site's underlying structure can support the next business goal. Choose a rebuild when the current platform, content model, architecture, or integration boundary prevents the required work. Many agency projects use a staged combination: preserve sound assets and URLs while replacing the parts that create recurring constraints.
The decision should follow an audit. Starting with a preferred platform or a new visual direction can hide migration work and lead to a scope that solves the visible symptoms only.
Define what the current site cannot do
Write the problem in operational terms. "The site feels old" is an observation, not a scope. A more useful problem statement identifies what users, editors, sales teams, or maintainers cannot accomplish.
Examples include content that cannot be found through the current navigation, templates that cannot represent the approved content, release work that depends on fragile manual steps, or integrations that no longer fit the required workflow. Record evidence for each issue and identify who experiences it.
The new objective also needs a boundary. A site can change its design without changing its content model. It can change its content model without changing every URL. It can replace a front end while retaining an approved back-end service. Treat those as separate decisions.
Audit four layers before choosing
| Layer | Evidence to collect | Redesign may fit when | Rebuild may fit when |
|---|---|---|---|
| Business | Goals, audiences, conversion paths | The offer and journeys remain valid | The site must support a different operating model |
| Content | Inventory, owners, templates, gaps | Existing types can carry the revised content | Required content has no workable structure |
| Technical | Platform, dependencies, deployment, integrations | The foundation is supported and maintainable | Core constraints block required behavior |
| Search and URLs | Indexed pages, internal links, redirects | Most useful URLs and hierarchy can remain | Architecture changes require a controlled migration |
This table is a prompt for investigation. It is not an automatic scorecard. One severe constraint, such as an unsupported critical dependency, can matter more than several cosmetic issues.
Use a redesign for bounded change
A redesign is a credible option when the system can support the approved templates, content workflow, accessibility requirements, performance work, and integrations without extensive workarounds. The project may still involve substantial front-end and content work.
Check whether editors can maintain the result. A visually improved site that keeps an unworkable publishing process moves the problem to the next release. Confirm component reuse, content ownership, preview and approval behavior, and the path for routine updates.
Brownsofts offers white-label website redesign and speed optimization for agencies working from an approved client brief. The related service page covers the commercial production scope. The decision here should happen before that scope is fixed.
Use a rebuild for structural constraints
A rebuild becomes easier to justify when required content or behavior conflicts with the existing foundation. Common evidence includes a content model that cannot represent the new information architecture, a platform that cannot support the approved workflow, integrations tied to obsolete assumptions, or maintenance risk that the project owner has documented.
Preserve what still has value. A rebuild does not require discarding approved copy, visual assets, domain history, analytics definitions, or every URL. Inventory each asset and decide whether to retain, revise, migrate, or retire it.
Price the migration, not only the new pages
A rebuild scope should account for content extraction, content cleanup, media handling, metadata, forms, integrations, redirects, analytics, editorial training, acceptance testing, deployment, and rollback planning where applicable. The size of the navigation does not reveal all of that work.
If public URLs will change, build the old-to-new map early. Google's site-move guidance covers server-side permanent redirects, self-referencing canonicals on new URLs, and updated internal links. Those tasks belong in the implementation plan and acceptance review rather than a post-launch cleanup list.
A redesign can also change URLs, so do not skip this review simply because the project keeps its current platform.
Consider a staged route
A staged project can reduce simultaneous change when the dependencies allow it. One stage might repair the content model and key templates, while a later stage migrates lower-priority content. Another might stabilize performance and maintenance first, then revise the information architecture with better evidence.
Staging needs a usable boundary. Each stage should leave the site in a supportable state, with no broken navigation or temporary duplicate paths treated as permanent. Record what moves now, what remains, and which later decision could change the plan.
Write the decision brief
The agency's recommendation should fit on a short decision brief:
- the business outcome and affected audiences;
- evidence from the content, technical, and URL audits;
- the chosen option and what remains unchanged;
- migration work that must be included;
- risks, dependencies, and approval owners;
- acceptance checks for launch; and
- items deferred to a later stage.
The brief gives the client a reasoned choice and gives production a defined baseline. It also makes scope changes visible when new evidence appears.