Rebuild the website, or fix the one you have?

Why does everyone recommend a rebuild?

Because it is easier to scope, easier to price, easier to make look impressive, and worth considerably more. None of that makes it wrong. It does mean the recommendation arrives with a thumb on the scale, and you should weigh it accordingly.

A rebuild is a clean project. It has a start, an end, a visible before and after, and a number everyone can agree on in advance. Fixing an existing site is the opposite: unclear scope, awkward estimates, and a result that looks like nothing much happened even when it worked.

There is a second reason, less cynical. Working inside someone else's codebase is genuinely unpleasant and genuinely riskier to estimate. A supplier who quotes a rebuild is partly pricing their own uncertainty, which is legitimate, and which you are nonetheless paying for.

So the question to hold onto is not whether the site could be better. Every site could be better. It is whether the specific thing costing you money can be reached without starting again.

What is the actual test?

Ask whether the problem can be fixed without changing the URL structure, the content model, or the platform. If all three can stay, it is a surface problem and rebuilding is an expensive way to solve it. If any one of them has to change, you are already most of the way into a rebuild whether you call it one or not.

This is a better question than the ones usually asked, because it maps onto the actual work rather than onto how the site feels. A site can look dated and have a perfectly sound structure. A site can look modern and have a content model that makes every new page a custom development ticket.

Run it against your real complaint. If the complaint is that the homepage does not explain what you do, nothing structural is involved and a rebuild is not the answer. If the complaint is that adding a case study takes a developer three days, that is the content model, and no amount of redesign fixes it.

Most complaints we hear are surface complaints described in structural language, which is how a copy problem turns into a six month project.

Where the real complaints land

Sorted by what we are actually told in a first conversation, and what each one turns out to require.

The pattern is that the top half of that table is where the money usually is, and the bottom half is where the projects usually are. That gap is worth staring at before signing anything.

What does a rebuild cost beyond the invoice?

Search standing, several months of no improvements at all, and a migration that will go wrong somewhere. The invoice is the part everyone plans for and the smallest of the three risks.

Changing URLs without a complete redirect map is the single most reliable way to lose rankings a site spent years earning. It is entirely avoidable and it happens constantly, because the redirect map is boring and gets done last by whoever is left at the end of the project.

Then there is the dead period. A rebuild typically means three to six months where nothing improves, because all the effort is going into arriving back at parity. If the site currently generates leads, you are choosing to freeze that while you rebuild the thing generating them.

And parity is optimistic. New sites routinely launch slower than the one they replaced, because the old site's performance problems were known and worked around while the new one's are still undiscovered. Plan for a dip, and plan to measure it, or you will not know it happened.

When is rebuilding genuinely right?

When the foundation blocks the work rather than merely annoying you. Four situations qualify, and outside them a rebuild is usually a redesign wearing a bigger budget.

What is missing from that list is worth as much as what is on it. Age is not on it. A site built five years ago on a sound structure is fine. Ugliness is not on it either, and ugly is much cheaper to fix than broken.

If your reason for rebuilding is not in those four lines, write down what it actually is and look at it honestly. Frequently it is that someone is embarrassed by the site, which is a real feeling and a poor basis for a six figure decision.

• Publishing anything new requires a developer, so the site cannot keep up with the business
• The platform is being discontinued, is insecure, or nobody left can maintain it
• The content model cannot express what you now sell, so every page is a special case
• You are changing what the company is, not how it looks, and the structure has to follow

Is there a path between the two?

Usually, and it is the option almost nobody offers because it is the hardest to sell. Replace the site page by page, starting with the pages that actually earn, while the rest keeps running.

The mechanics are unglamorous and well understood. Build the new templates alongside the old, migrate the highest value pages first, keep the URLs identical so nothing has to be redirected, and retire the old templates as they empty out. Each step ships and each step can be judged.

The advantage is that value arrives continuously instead of at the end, and a project that stalls halfway leaves you better off rather than stranded. Most rebuild horror stories are stories about a project that stalled at seventy percent.

The disadvantage is real: it takes longer overall and it needs someone with judgment about ordering. It is also the approach we recommend most often, because the risk profile is so much kinder to a company that depends on the site while the work happens.

How do you decide this week?

Write down the one thing the site is costing you, in a sentence, with a number attached. Then apply the test. Most of the time the decision makes itself once the complaint is specific.

The sentence has to be concrete. Not that the site underperforms, but that the demo request form gets forty submissions a month and thirty of them are unusable, or that publishing a case study takes eleven days. A vague complaint reliably produces a broad project, and a broad project is how budget disappears without a measurable result.

Then ask the URL, content model, and platform question. If all three can stay, get quotes for fixing the specific thing, not for a redesign. If any must change, you are rebuilding, so scope it properly with the redirect map in the plan rather than at the end.

And if you cannot write the sentence at all, that is the finding. Diagnose before you spend, because a rebuild commissioned without a named constraint is a very expensive way to discover the constraint was somewhere else.