Rebuild or Repair? A Framework for an Aging Website

Everyone selling you a website has an interest in the answer being rebuild. That is worth holding in mind while reading anything on the subject, including this, so here is the disclosure up front: we build websites, and we still turn down rebuilds regularly — because a site that needed three thousand dollars of maintenance and got a fifteen-thousand-dollar replacement usually ends up in the same condition four years later, having taught the owner nothing except that rebuilds do not stick.

The distinction that matters is between a site with problems and a site whose problems are structural. The first is a maintenance backlog. The second has a ceiling you cannot optimize past. Five questions separate them.

Run a PageSpeed check and read the mobile number.

Above 90: speed is not your problem. Whatever is wrong is content, structure, or visibility, and a rebuild aimed at performance would be solving something you do not have.

Between 50 and 90: almost always repairable. Oversized images, unused plugins, third-party scripts, undersized hosting. These are afternoons of work, not projects, and the gains are real.

Below 50: look at the causes rather than the score. If it is twelve megabytes of unoptimized photographs, that is fixable. If it is a page builder emitting hundreds of kilobytes of framework code before a word of your content renders, you have found a ceiling — the weight is what the platform does, not something layered on top of it, and optimization passes will claw back a portion and lose it again. That is the structural case.

Ask a plainer question than it sounds: if you needed a new service page live by Friday, could you get one?

If the answer involves a developer who no longer responds, a theme nobody understands, a page builder whose license lapsed, or a login nobody has — the technology is not really the issue. The operating arrangement has failed, and rebuilding without fixing that just produces a newer site with the same fate. This is worth reading alongside Who Actually Owns Your Website?, because the two failures usually arrive together.

A site that is technically mediocre but that you can actually change is worth more than an excellent one you cannot.

This is the question that most often justifies a rebuild, and the one owners raise last because it does not feel like a website problem.

You sell seven services across fourteen cities and the site has one Services page. You are a manufacturer whose buyers search by capability and certification, and the site has an About page and a contact form. You have a catalog of hundreds of parts sitting in a system that generates thin, unrankable pages for each one.

In each case the site is not broken — it is undersized for the business. And adding a hundred pages to a platform that gets slower with every page, or that requires manual work for each one, is where repair stops making sense. QTC is the extreme version: a 597-part catalog that needed to become a thousand-plus real pages with capability, aircraft, manufacturer and certification structure behind it. No amount of maintenance on the old WooCommerce install produces that, because the old install was storefront software for a business that never sold off a shelf.

The useful test: is the gap between what you have and what you need a matter of adding content, or of adding a structure the current system cannot express?

Some sites are not slow or broken. They just look like the business might have closed.

This matters unevenly. If your work is bought on trust and comparison — professional services, healthcare, anything where someone chooses between three unfamiliar options — a dated site is doing measurable damage in the first seconds, before anyone reads anything. The David Plotkin practice was a clear case: a 2017 theme fronting a Los Angeles clinical psychology group whose prospective patients are often anxious people reaching for a phone at two in the morning. The design was not a taste question. It was affecting whether people called.

If your work comes overwhelmingly from referrals and repeat customers who already know you, this factor is much weaker. Be honest about which you are.

Price both paths over the same horizon, because a build quote compared against nothing always looks expensive.

Repair: the fixes now, plus hosting and maintenance for three years, plus the incidents you should expect on the current platform, plus the rebuild at the end if the ceiling is real. Rebuild: the build, plus hosting and maintenance for three years, minus the incidents that stop happening.

Run honestly, the gap is usually smaller than the sticker prices suggest, and occasionally inverted — a heavily maintained legacy site can cost more over three years than replacing it. We laid out the full arithmetic in Static vs. WordPress: The Real Total Cost.

Repair when the score is recoverable, you can get changes made, the structure fits the business, and the design is merely unfashionable rather than untrustworthy. Fix the images, cut the plugins, upgrade the hosting, tighten the content, and revisit in a year. This describes more sites than the industry likes to admit.

Rebuild when the platform is the ceiling rather than the contents, when the structure cannot express what you sell, or when the site is actively costing you credibility in a business where credibility is the product. Two or more of those together makes it clear-cut.

And do neither, for now, if the honest problem is that nobody is visiting. A rebuild does not create demand. Work out which of the six lead failures you actually have first — the answer changes what you should spend money on, and sometimes the answer is not a website at all.

If you want a second opinion that includes the possibility that you should not rebuild, that is a fifteen-minute conversation. Get in touch and you will get the direct answer.