Rebuild the website without breaking what already works

Plenty of website rebuilds are just a redesign with a bigger invoice attached.

The old site is slow, awkward or ugly, so everyone sprints toward the new look. New pages, new navigation, new templates, new copy, new CMS, new everything. Then launch day arrives and the business finds out what was actually useful about the old site, right after it’s been deleted.

Search traffic drops. Old links break. Forms quietly stop sending. Analytics resets to zero. Staff can’t edit the new pages. The site looks better and the business has gone backwards.

A good rebuild starts by working out what already works, before anyone touches the design.

The rebuild that went backwards

Here’s how it usually plays out. An equipment-hire company on the Darling Downs rebuilds its site. The old one was a decade old, slow on a phone and embarrassing next to competitors, so nobody argued with the decision. The new site launches, everyone likes it, the agency sends the final invoice, and for three weeks nothing seems wrong.

Then the operations manager notices the phones have gone quiet. Enquiry emails are down by about half. Nobody connects it to the website at first, because the website is the thing that just got better. It takes another month before someone checks Search Console and finds the crawl errors: dozens of old URLs returning 404s, including the page that ranked for the company’s single best search term, a specific machine plus a town name. That page got merged into a general fleet page because the new design had no slot for it. The address it lived at for eight years now goes nowhere, and Google has started handing the ranking to a competitor in Brisbane.

Clawing it back takes most of a year. Redirects added late, the specific page rebuilt from a cached copy, rankings inching up month by month while the enquiries it used to bring in go elsewhere. The rebuild itself was fine. The launch deleted the part of the site that made money, and nobody on the project was responsible for noticing.

Audit before design

Before you go near layout, take stock of the current site. Which pages bring in search traffic? Which ones generate enquiries? Which have backlinks pointing at them? Which forms get used? Which content answers the questions your sales team hears all the time? And which URLs are sitting in proposals, email signatures, brochures or partner sites where you can’t easily change them?

Check what staff hate about the site too, because editing pain matters more than people think. If the CMS fights the team, the site will rot after launch no matter how sharp it looked on handover day.

The audit doesn’t need to drag on for months. It just needs to happen before design decisions quietly turn into deletion decisions.

Take a baseline you can compare against

While you’re auditing, capture the numbers the new site will be judged against. Export the top pages and top queries from Search Console. Note how many enquiries the forms send in a normal month, and which pages the enquiries come from. Write down which pages carry the traffic and which carry the conversions, because they’re often not the same pages, and a rebuild that protects one can still quietly kill the other.

This takes an afternoon and it changes the whole project. Without a baseline, a post-launch traffic drop turns into an argument about feelings, with the builder saying give it time and you unable to prove anything. With one, you can point at the exact page that lost its ranking and the week it happened, and get it fixed while it’s still fixable.

Keep useful URLs where you can

URLs aren’t decoration. They’re addresses that people and search engines already know by heart.

If a page has value, keep its URL when you can. If the URL has to change, redirect it properly. If you are merging several old pages, map each one to the closest new page. And if you are removing a page, make sure first that it wasn’t carrying search traffic, links or customer value out the door with it.

The mechanics deserve to be spelled out, because this is where rebuilds go wrong quietly. Every old URL with traffic or links needs a permanent redirect to the single closest new page, not a lazy blanket rule that dumps everything on the homepage. Search engines treat the blanket version as a soft deletion, and a visitor who followed a link to a specific machine and landed on your homepage treats it as a dead end. The redirect map is nothing fancy, a spreadsheet with an old address column and a new address column, but someone’s name has to be on it.

This is basic work, and it gets skipped constantly because nobody owns it. Designers are focused on the new pages, developers are focused on the build, and the old URL map falls straight through the gap between them. Ask your builder who owns the redirects. If the answer is a pause, you’ve found the gap before it costs you.

Content migration is real work

Moving content isn’t a copy-paste job. A rebuild is your chance to improve headings, cut stale claims, tighten the calls to action, fix internal links, update images, clean up metadata, and decide which pages should even exist anymore.

But the content still needs continuity. If a service page ranks because it answers one specific question, do not swap it for a vague brand statement. If a case study is pulling its weight in sales conversations, do not bury it under a new structure just because the template had no obvious slot for it. Good migration keeps the useful parts and sharpens the weak ones. Bad migration treats the old site as a bin to be emptied.

The CMS needs to match the team

The best CMS is the one your team can run without breaking it. For some businesses that is WordPress with a sensible theme and a tight set of plugins. For others a static site, a headless CMS, a custom admin area or a managed content workflow is the better fit.

The wrong CMS turns a five-minute edit into a support ticket, and the wrong page builder leaves the site slow and fragile. Worse, a sloppy handover leaves staff too scared to touch anything. Before you pick a platform, ask who edits the site, how often, what they need to change, and what should be locked away from accidental damage.

Rebuild the technical foundations

A rebuild should fix the technical reasons the old site struggled in the first place. That covers performance, accessibility, metadata, schema, forms, analytics, redirects, mobile layout, image handling, hosting, security updates and deployment.

It also means stripping out weight. A lot of older sites are slow because years of plugins, scripts, tracking tags and page-builder layers have piled up on top of each other. Treat the rebuild as a chance to throw out what the business no longer needs, not to recreate the same mess with nicer styling on top.

Launch with a checklist

Before you go live, work through the basics:

• Redirects from old URLs to new URLs.
• Forms and confirmation emails.
• Analytics, conversions and search console verification.
• Sitemap and robots rules.
• Metadata on key pages.
• Page speed and mobile rendering.
• Broken internal links.
• 404 handling.
• CMS permissions.
• Backup and rollback path.

None of it is exciting. All of it matters.

Watch the site after launch

Going live isn’t the finish line. For the first few weeks, keep an eye on search traffic, form submissions, crawl errors, performance, broken links, enquiry quality and any editing trouble staff run into. That period surfaces things staging never could.

Know what normal looks like, too. Some wobble in rankings for a week or two after a rebuild is ordinary and settles on its own. A sustained slide on pages that used to rank is not, and the 404 report in Search Console is usually where the culprit shows up first, wearing the address of a page somebody forgot to redirect.

If a redirect is wrong, fix it. If a page drops in the rankings, go and inspect it against the old version, because the answer is usually something concrete: a heading that changed, a chunk of specific content that got cut, a URL that moved twice. If staff can’t update something, adjust the workflow before the site starts going stale again. A rebuild done right leaves the business with a better site and a clearer way of running it.

Rebuild for ownership

A website is a business system, even when it looks simple on the surface. It carries search traffic, sales conversations, hiring signals, credibility, forms, analytics and the publishing work your team does week to week. Treat a rebuild as a coat of paint and you miss most of the actual risk.

Rangefront Labs builds websites and web platforms and handles website rebuilds and performance work with the old site kept firmly in view: the useful URLs, the content, the redirects, the CMS, and the handover.

If your current site is slow, messy or a pain to edit, rebuild it carefully. Keep what works, fix what does not, and leave your team with a site they can actually run themselves. And if you’re partway into a rebuild and nobody has mentioned redirects yet, get in touch with the old sitemap and the new page list, and we’ll tell you what’s about to break.