Should You Redesign Your Site All at Once or Page by Page?

Should You Redesign Your Site All at Once or Page by Page?

Page by page, unless something structural is broken. Incremental change is lower risk, easier to measure, and easier to fund. A full rebuild is the right call when the foundation cannot support what you need, and the honest test is whether you can name the structural problem in one sentence.

Most redesign requests we receive are framed as all or nothing, and most of them do not need to be. The framing usually comes from how budgets work rather than from what the site needs.

So here is the case for each, with the research and the technical guidance that should inform the decision.

What Does the Research Say About Radical Redesigns?

That they are risky and often unnecessary. Nielsen Norman Group frames the choice as whether to pursue "a big bang and change everything in one go, or to rely in incremental quality improvements, one step at a time," and its warning about the first option is direct: "radical changes have a higher chance of inadvertently breaking something critical for users."

NN/g's advice before any major change is modest and cheap: it recommends "spending 1 or 2 days conducting a usability study." Two days is less than most teams spend arguing about the homepage hero.

It also names the failure mode behind a lot of redesign projects, and it is not a technical one: "Don't let panic or boredom lead you astray." Aesthetic fatigue inside the company is not evidence that customers are struggling.

When Is a Full Rebuild Genuinely Justified?

NN/g lists the cases, and they are all structural rather than visual. When you have "performed many iterations and found yourself at the point of diminishing returns." When the underlying technology cannot support the interactions or mobile access you need. When the site has become, in its words, "a big mess" with incoherent navigation after years of patchwork changes. When data shows "extremely high exit rates and bounce rates" that incremental fixes cannot resolve. And when benchmarking shows competitors serving user needs better.

Notice what is not on that list: a new brand, a new logo, a new investor, or a new marketing lead. Those are common reasons for rebuilds, and they are business reasons rather than user reasons. That does not make them invalid, but it does change how you should measure success.

In our own work, the clearest rebuild cases have been performance and structure. When a site takes 3.4 seconds to load, as ION Clean Energy's did before we rebuilt it to 0.8 seconds, you are not going to fix that by restyling sections. The problem is beneath the design.

What Does Google Say About Changing a Site in Chunks?

It recommends chunks, explicitly. Google's documentation on moving a site with URL changes says: "Split your move into smaller steps, if that makes sense for your site. If your site is large and it's technically possible, we recommend initially moving just a piece of the site to test any effects on traffic and search indexing."

Google also gives advice on choosing the test section: "pick a section that changes less frequently and isn't significantly affected by frequent or unpredictable events." And it adds an important caveat, that moving one section "is not necessarily representative of a whole site move when it comes to Search," because "the more pages that you move, the more likely you'll encounter additional problems to solve."

The strongest line in that document is a heading: "Change only one thing at a time." Google's reasoning is that plans should proceed one after the other, not everything at once. A redesign that simultaneously changes URLs, templates, content and hosting gives you no way to attribute a traffic drop to any of them.

What Does Phasing Actually Look Like in Practice?

Usually by template, not by page. Marketing sites are built from a small number of page types, and the efficient unit of work is a type rather than an individual URL.

Our normal order is: the pages with the most commercial weight first, then the pages with the most traffic, then the long tail. In practice that often means the homepage and the primary conversion pages, then service or feature pages, then the blog. Each phase ships behind the same design system, so the site does not look inconsistent for longer than necessary.

The one thing we do up front, before any page ships, is the foundation: the type scale, the colour tokens, the spacing system, the component library. If you phase that, you get eight phases of inconsistent decisions rather than one site.

Is a Half-Redesigned Site Really Acceptable?

For a few weeks, yes. For six months, no, and this is the real risk of phasing. A site in two visual eras reads as neglect, and it costs credibility with exactly the buyers you are trying to impress.

The mitigation is a hard deadline on the transition period, not on the whole project. Decide the maximum time the site may look mixed, and if a phase will not fit inside that window, make the phase smaller.

There is a cheap trick that helps more than it should: ship the global elements, the navigation, the footer, the typography and the colour system, across the whole site in phase one. Even old-layout pages then look like they belong. The structural work continues page by page behind a consistent surface.

How Do You Measure Whether It Worked?

This is the strongest argument for phasing and the one that usually wins the internal debate. When you change one template, you can attribute the result. When you change everything, you cannot.

NN/g's guidance is to rely on "conversion research (i.e., site analytics, user testing)" and "solid data" rather than assumptions, and it notes that radical redesigns are best tested with an A/B experiment while multivariate tests suit incremental improvement. A/B testing a whole-site rebuild is possible and expensive. A/B testing one new template against the old one is routine.

Write down the metric before the phase ships. For a conversion page, the conversion rate. For a service page, organic entrances and time to first meaningful action. For the blog, subscriptions or demo requests from content. Without that, "the new site feels better" is all you will have, which is what happens in most of the projects described in why website redesigns fail.

When Does Phasing Cost More Than It Saves?

Three situations. When the platform is changing, because you cannot run two content management systems well at once. When the URL structure is changing site-wide, since Google's own advice to change one thing at a time argues for doing the URL move as its own discrete step rather than spreading it. And when the site is small, because a 12 page site phased into four releases is four sets of coordination overhead for no benefit.

There is also a team-size threshold. Phasing requires someone to hold the plan across months. If the person who would hold it is also the person doing the work, and they have a day job, a phased project tends to stall after phase two and stay mixed indefinitely.

In that case a focused full rebuild with a fixed end date is genuinely the better option, and the honest reason is organisational rather than technical.

How Do You Protect the Search Traffic Either Way?

By treating the URL question as separate from the design question. A redesign does not require new URLs, and most of the SEO damage attributed to redesigns comes from URL changes, not from visual changes.

So keep the URLs unless you have a specific reason to change them, map every one that must change before you ship, and monitor both old and new addresses afterwards, which is the sequence Google's site move documentation lays out: prepare and test the new site, prepare a URL mapping, configure redirects, then monitor traffic on both. We wrote the longer version of this in migrating a website without losing SEO.

The corollary is reassuring. If you are not changing URLs, phasing a design is much safer than people assume, because Google is looking at the same addresses it always was.

So What Would We Recommend?

Default to phased, with the design system built once at the start and the global elements shipped everywhere in the first release. Reserve the full rebuild for cases where you can name the structural problem in a sentence: the platform cannot do what we need, the information architecture is incoherent, the performance is beyond repair.

And spend the two days NN/g suggests before you commit either way. Watching five people try to do something on your current site will tell you more about what needs to change than a quarter of internal debate, and it will usually reveal that the problem is narrower than the proposed solution. If the real issue is accumulated inconsistency rather than a broken foundation, the cheaper fix is the one we described in paying down design debt.

If you want a straight read on whether your site needs a rebuild or a sequence of fixes, we are happy to look and tell you honestly, including when the answer is do less. You can find us at phoenix.studio.