Should You Revamp Your Website in Stages or All at Once?

A phased website revamp is usually the right call for the pages, and the wrong one for the structure that holds them together. The words, photos and individual service pages can be revamped a few at a time over months. The navigation, the shared templates and any change to the page addresses cannot be half-done: they change everywhere at once, so they belong in one release, ideally the first. On a small or medium site, Google’s own advice points the same way for the addresses.

So the useful question is rarely “stages or all at once?” It is which parts of your site can wait, and which have to move together.

What can a phased website revamp actually split up?

Think of a site as two layers. The first is shared: the navigation, the header and footer, the page templates, the page addresses (URLs) and the platform underneath. Each appears on every page, so it changes once, everywhere. The second layer can change page by page: the copy, the photos, the individual service pages, a better contact form.

The second layer stages well. Rewriting twelve service pages two at a time is a sound plan, because the first two teach you what the other ten need. Most of what makes a revamp slow lives here, which is why how long a revamp takes depends so heavily on content.

The first layer does not stage. Put a new menu and design on the homepage and three service pages, leave the rest on the old template, and a visitor who clicks from a new page to an old one sees two websites in one visit — a different menu, different fonts, sometimes a different phone number in the footer. That looks less trustworthy than either version alone. When the structure is the problem, it is the structure that has to move first and all together.

Should the URLs change in stages or in one go?

If the addresses are changing — /services/aircon-repair becoming /aircon-repair, say — Google has answered this directly. Its guidance on site moves with URL changes says:

• “Small or medium sites: We recommend moving all URLs on your site simultaneously instead of moving one section at a time. This helps users interact with the site better in its new form, and helps our algorithms detect the site move and update our index faster.”
• “Large sites: You can choose to move larger sites one section at a time. This can make it easier to monitor, detect, and fix problems faster.”

Almost every Malaysian SME site we see is in the first group: a few dozen pages, perhaps a hundred with the blog. For those, the URL map and every 301 redirect go live on the same day as the new structure, rather than handing Google a moving target for months.

The same page adds a caution for anyone tempted to “test” with one section first: “while moving just one section is a great way to test your move, it’s not necessarily representative of a whole site move when it comes to Search.” A twenty-page service site gains nothing by it. Redesigning without losing rankings covers the redirect work, and the cleanest outcome is often to keep the addresses you have: a revamp that changes no URLs has no site move to stage.

When does a single relaunch beat a staged revamp?

Nielsen Norman Group’s article on radical redesign or incremental change leans firmly towards small steps: “Drastic website changes are jarring for users and risky for business,” and “Never make radical changes when minimal adjustments will suffice.” We agree for most sites. But the same piece lists when an overhaul is the honest answer, and those cases map onto the shared layer:

• The structure is the problem. NN/g describes a site where, “after several years of patchwork the site is incohesive and people can’t accomplish what they need.” You cannot fix a tangled menu one page at a time.
• The platform is changing. Moving off an old page builder, or from a hosted builder to WordPress, changes every template at once. There is no half-migrated state worth publishing; what a page builder costs after the build is often why.
• The brand is changing. A new name or logo on half the site reads as two companies.
• The site is small. On a fifteen-page site the shared layer is most of the work, and staging the rest saves little.

None of these needs a rebuild: a single release can keep the content, addresses and platform that work. Revamp or full rebuild is a separate decision from how many releases it takes.

When does a phased website revamp make more sense?

When the shared layer is sound, or can be fixed in one release, and the slow part is the pages. Four situations fit:

• Content is the bottleneck. If the owner is writing the service pages, or they need translating into Bahasa Malaysia, finished pages can go live instead of waiting for the slowest. Running two languages is a common reason to stage.
• Cash flow matters more than total cost. Stages can be paid for as they land, though a staged revamp rarely costs less in total: each stage carries its own planning, review and launch checks. What drives a revamp’s price explains where those hours go.
• The business cannot pause. A shop heading into a Hari Raya sale should not freeze its site for months; revamping without taking the site offline covers keeping the live site trading.
• You want to learn before committing. Release the service pages first, watch whether enquiries move, then decide how far to take the rest.

That last point is the case the GOV.UK Service Manual makes for government services, and it travels well. Its standard on iterating starts from the premise that services are never “finished”, and its core principles of agile warn against “creating a ‘too-big-to-fail’ service that should not be released, but must be released anyway”. A relaunch nobody dares delay is that service, at SME scale.

What is a sensible first stage?

The shared layer, plus the pages that carry the enquiries. In practice:

The first stage that does not work is the homepage alone, redesigned but still on the old menu and templates. It is the commonest request, and it pays for the shared decisions twice. Whether to fix the homepage or revamp the whole site explains why most visitors never see the homepage anyway.

Before stage one starts, decide what survives (what to keep from the old site covers the audit) and put the whole plan in the revamp brief, so each stage is quoted against the same scope.

How do you stop a staged revamp from stalling?

Stage two is where staged revamps die: stage one launches, the pressure lifts, and the old pages sit there for a year. NN/g’s piece notes the pattern in big redesigns too: “Some projects start and stop multiple times, while other projects fizzle completely.” Three habits prevent it:

• Agree every stage, with dates, before stage one starts. “The rest later” is not a plan.
• Give each stage its own measure. A key event such as a WhatsApp click or form submission, recorded before and after; the minimum analytics setup lists the ones worth tracking.
• Run the same launch checks every time. Redirects, forms, mobile layout, page speed — the go-live checklist applies to stage three as much as stage one.

Frequently asked questions

Where iRevamps fits

When a client asks us to revamp in stages, we usually agree — and then argue for putting the navigation, templates and any URL changes into stage one. Our web development and design service plans every stage up front, so later stages are content work inside a finished structure. Not sure the site needs a revamp at all? Start with the signs it needs more than a refresh.