Web development

Old Website Still Works: When to Rebuild It and When Not To

A rebuild is justified when the old site no longer brings enquiries, cannot be updated safely or holds the business back. If the problem is one page or one text, a fix is enough.

FSM Studio · · 4 min read · Updated:

Two browser windows with user cards and arrows between them on a red and blue split — old site and new site

The site opens, the contacts are correct, nobody has complained. So the rebuild question is postponed for years. But “works” is not the same as “works for you”. Below are five signals that a rebuild is justified, and the cases where a smaller step is enough.

“Works” versus “works for you”

A page works if it loads without errors. It works for you if it does three things: brings enquiries, lets your team change content without help, and does not put the company at risk. If one of these fails, “works” is only a technical description.

A rebuild costs money and time, so do it only when you know which problem it solves.

Signal 1: enquiries fall while the rest of the business has not changed

If visits and enquiries have dropped over the last years while sales in other channels hold, the site is often the cause. Find out where first:

  • does traffic fall on all pages or only a few;
  • do enquiries fall, not just visits;
  • do competitors rank above you for the same queries.

If slow loading or a poor mobile version blocks enquiries, that is an argument for a rebuild. If the problem is outdated text, you can fix it without new code.

Signal 2: the site is slow and awkward on a phone

Google’s Core Web Vitals thresholds: Largest Contentful Paint (LCP) within 2.5 seconds, Interaction to Next Paint (INP) within 200 milliseconds and Cumulative Layout Shift (CLS) at most 0.1, measured at the 75th percentile (web.dev). You can measure your own site for free with PageSpeed Insights and Search Console.

If an outdated template architecture keeps you above these thresholds whatever you optimise, rebuild. If the slowness comes from three huge images and an old plugin, a fix is enough. More in our article on Core Web Vitals and business impact.

Signal 3: nobody dares to update the system

If the CMS, the programming language version or the plugins have not been updated for years because “everything will break”, you already live with risk:

  1. security vulnerabilities that are no longer patched;
  2. a vendor that ends support for old versions;
  3. a developer who is gone or no longer knows how the site works.

The third is the most dangerous. We describe it in when WordPress is no longer enough. If the site can be updated safely and someone is responsible for it, a rebuild is not urgent.

Signal 4: the business needs what the site cannot do

A rebuild is justified when the site has to talk to other systems it cannot reach: enquiries into a CRM, stock synchronised with accounting, or a second language. If every new requirement is solved with another plugin or another patch on top, the cost grows faster than the price of a new site.

A simple test: list three things you want and ask your current developer what each change involves. If the answer is “not possible” or “very expensive”, you have found the ceiling.

If you rebuild: protect the old URLs

The biggest risk is the old URL structure, not the new design. Google recommends redirecting each old URL to its new equivalent with a permanent redirect (301 or 308) and keeping redirects “as long as possible, generally at least 1 year” (Google Search Central). List all old URLs, map each to a new page, keep titles and internal links, and check after launch. Details in redesign without losing SEO.

When a rebuild is not needed

A rebuild costs more than the problem in these cases:

  • the site is fast, secure and updatable, but looks “old-fashioned”;
  • one section or page is missing;
  • texts are outdated but the structure works;
  • conversion is low on one path, such as the contact form, and can be improved locally;
  • you want a new design but cannot say which problem it solves.

Start with targeted fixes and measure the result. If the problem remains, you know it is deeper.

Decision rule

  • Site secure, fast, updatable and run by your team, but you dislike the look: start with design and content fixes.
  • Measurable decline with a technical cause (speed, mobile, outdated platform): rebuild.
  • Cannot update safely or nobody is responsible: plan the rebuild now, not after an incident.
  • Business needs integrations the site cannot provide: price the rebuild against the cost of patching further.

If you are unsure which case you are in, describe the situation. As a web development studio we will assess the site and say whether it needs a rebuild or a smaller step. Discuss your project.

Sources