Whether to patch or rebuild a site a previous developer left broken depends on its foundations, not its symptoms — here’s how to tell, and what each path really costs.
Should I fix my website or rebuild it from scratch?
Fix it when the foundation is sound and the problems are cosmetic, structural or performance-related but contained. Rebuild when the platform, code or data model is the problem itself, because every fix on a broken foundation costs more than the last and holds for less time.
The honest answer is that nobody can tell you down the phone. The same complaint — "my site is slow and half the pages are broken" — can mean a fifteen-minute fix or a build that was never going to work. What separates the two is underneath the surface: how the site was built, what it was built on, and whether the person who built it followed the platform’s conventions or fought them.
We see two clean cases and one messy middle. The clean fix is a site with a sensible foundation — a standard WordPress or Shopify setup, a reasonable theme, content that’s structured properly — that has cosmetic damage, a few broken plugins, or performance that was never tuned. The clean rebuild is a site held together by custom code nobody documented, a page builder stacked three tools deep, or a platform choice that can’t do what the business now needs. Most inherited sites sit in the middle, and that’s where an audit earns its keep.
The trap is treating this as an emotional decision — "I’ve spent so much already, I can’t throw it away" — or a cosmetic one — "it just needs to look better". Neither tells you whether the next twelve months of maintenance will be quiet or a running battle. The money already spent is gone whichever way you go; the only question is which path costs less from today forward.
A useful test: ask what happens when you want to add one ordinary feature — a new product type, a booking form, a language. On a sound site that’s an afternoon. On a broken one, every request turns into "we can’t do that without touching everything", and that answer, repeated, is the sound of a rebuild you’re paying for in instalments.
How do I tell whether my site is worth saving?
Look at the platform, the code quality, the content structure and the performance ceiling. If three of those four are sound the site is usually worth fixing; if the platform or the code is the problem, fixing only postpones the rebuild.
The platform is the first thing to check because it caps everything else. A standard content platform — WordPress, Shopify — with a mainstream theme can be handed to any competent developer and worked on. A bespoke system, an abandoned framework, or a site locked to one agency’s proprietary builder means you’re either dependent on people you’ve already lost faith in, or paying someone to reverse-engineer it before they can even start.
Code quality is harder to see but shows itself fast. Sites built by cutting corners tend to have the same tells: no version control, no staging environment, changes made live on the running site, plugins installed to solve problems that a line of code should have solved, and a database full of orphaned data from tools that were tried and abandoned. Any one of these is survivable. All of them together mean every fix risks breaking something unrelated.
Content structure decides how much survives a move. If your pages, products and categories are stored the way the platform intends, they migrate cleanly. If your previous developer jammed everything into freeform page-builder blocks with the text baked into images or hardcoded into templates, the content has to be rebuilt by hand — and that rebuilding is often the largest hidden cost of a migration.
Performance has a ceiling set by the build. Some slow sites are slow because nobody optimised them, and they speed up dramatically once someone does. Others are slow because of how they were architected, and no amount of caching or image compression gets them past a wall. Google’s Core Web Vitals give you a measurable read on where a site sits, and whether the numbers can realistically be moved without a rebuild.
What actually goes wrong on sites a previous developer left behind?
The recurring problems are broken or abandoned functionality, no way to update safely, security holes from outdated software, and a build that lost search rankings the business never knew it had.
The most common inheritance is a site that was launched and then left. The developer’s job ended at go-live, so nothing has been updated since. Plugins and platform versions drift out of date, which is both why things break and how sites get hacked — outdated software is the single largest cause of compromised websites, and an unpatched site is a target regardless of how small the business is.
The second pattern is half-finished. A project ran out of budget or the relationship broke down, and the site was left at 80%: the checkout works but the confirmation emails don’t, the blog exists but has no way to add posts, the contact form submits into a void nobody monitors. These are the frustrating cases because the site looks done and isn’t, and the gaps only surface when a customer hits them.
The third is invisible until you look: a site with no analytics, no conversion tracking, and no idea whether it’s working. The business is spending on a website and on ads pointing at it, with no measurement in between. This is often the first thing worth fixing whether or not the rest gets rebuilt, because you can’t make a sensible fix-or-rebuild decision about a site whose performance you’ve never measured.
The fourth, and the most expensive to discover late, is lost search visibility. A rebuild or a botched migration that changed URLs without redirects can quietly wipe out years of accumulated ranking. We’ve seen sites where the traffic collapse was blamed on "the market" when it was really a launch that dropped every old URL. Search engines treat a moved page with no redirect as a page that no longer exists.
What does it cost to fix a badly built website versus rebuild it?
There’s no flat figure — the cost tracks the amount of work, which the audit determines. What’s reliable is the shape: fixing is cheaper up front but can cost more over a year if the foundation is bad, and rebuilding costs more up front but stops the recurring bleed.
We don’t quote a fix or a rebuild before auditing, because a fixed price for "fixing your site" from someone who hasn’t opened it is a number pulled from the air — and it’s usually the low number that hides the discoveries. The cost of a genuine fix depends on how much is broken and how cleanly it can be reached; the cost of a rebuild depends mostly on how much content and functionality has to be recreated, not on the design.
The table below sets out what each path involves and where the money actually goes, so you can reason about your own situation before any quote. The pattern to watch for is a fix that keeps needing more fixes: if you’ve already paid two or three times to "finally sort it out", the sum of those has often exceeded what a clean rebuild would have cost, and you still have the broken site.
The honest framing is total cost over the time you’ll own the site, not the invoice in front of you. A cheaper fix on a sound foundation is genuinely cheaper. A cheaper fix on a rotten foundation is a subscription to the same problem. The audit’s job is to tell you which one you’re looking at, so the cheaper-looking option is the one that’s actually cheaper.
| Factor | Fixing the existing site | Rebuilding from scratch |
|---|---|---|
| Up-front cost | Lower — scoped to what’s broken | Higher — full build effort |
| Best when | Platform and code are sound | Platform, code or data model is the problem |
| Content | Stays in place | Migrated across; freeform content may need rebuilding |
| Search rankings | Preserved by default | Preserved only if URLs are mapped and redirected |
| Cost over 12 months | Low if foundation is good, high if it isn’t | Predictable once launched |
| Main risk | Fixes keep uncovering more problems | Traffic loss if migration is rushed |
| Right for | Cosmetic, performance or contained functional issues | Recurring breakage, platform lock-in, unmaintainable code |
Why do cheap rebuilds end up back in the same place?
Because the saving on a cheap rebuild almost always comes from skipping the same things the original build skipped — structure, testing, tracking and a maintenance plan — so the new site inherits the old site’s future.
A rebuild that costs a fraction of a proper one is cheaper for a reason, and the reason is rarely efficiency. It’s usually a theme applied with minimal customisation, content pasted in without structure, no staging environment, no analytics, and no handover — the exact conditions that produced the site you’re replacing. Within a year you’re back to broken plugins and a build nobody can safely touch.
The parts that make a build last are the parts that are invisible on launch day and therefore the easiest to cut: a sensible content model so the site can grow, version control and a staging site so changes can be tested before they go live, conversion tracking so you know what the site is doing, and documentation so the next person can pick it up. None of these show in the design, which is why they’re the first to disappear from a low quote.
This is also why the person who built your site badly could show you a design that looked fine. The failure wasn’t visible at launch — it was baked into decisions you couldn’t see and only surfaced months later. Judging a rebuild quote by the mockup repeats exactly that mistake.
The way out is to price the whole thing, including the invisible parts, and to treat a suspiciously low quote as a warning rather than a bargain. A rebuild that includes tracking, testing and a maintenance path costs more and is the only version that actually replaces the problem instead of renaming it.
What can I keep when I rebuild, and what do I lose?
You keep your domain, your content, and — if the migration is planned — your search rankings. You lose them only when a rebuild changes URLs without redirects or discards content that took years to accumulate.
The single biggest fear about rebuilding is losing search traffic, and it’s a legitimate fear because it happens constantly — but it happens to migrations that were improvised, not to migrations that were planned. Google’s own guidance on site moves is explicit: every old URL that changes needs a redirect to its new equivalent, so that the ranking a page earned transfers instead of evaporating. Map the redirects before launch and rankings hold; skip that step and they don’t.
Content is the other asset worth protecting. Years of blog posts, product descriptions and pages carry both search value and the plain work of having written them. On a well-structured old site this migrates almost automatically. On a badly structured one it has to be lifted out by hand — which is real cost, but it’s a one-time cost that ends with content stored properly for the future rather than trapped again.
Your domain and email stay yours throughout — those live independently of the website and don’t need to change. What people sometimes lose here is access, when a previous developer registered the domain or hosting in their own name. Getting your own name on your own domain, hosting and analytics accounts is worth doing regardless of the fix-or-rebuild decision, because without it you don’t fully control the thing you’re paying to improve.
What you deliberately leave behind is the accumulated mess: the abandoned plugins, the dead database records, the tracking that was never set up. A rebuild is the one clean chance to start the new site measured, structured and maintainable from day one, and that fresh start is much of its value.
How do I stop this happening again with the next site?
Own your accounts, insist on measurement and a staging environment, get a handover in writing, and choose a maintenance arrangement rather than a launch-and-vanish build. The problems you inherited came from the absence of these, not from bad luck.
Nearly every inherited-site problem traces back to a build that ended at launch with nothing behind it. The fix is to require the things that make a site maintainable as part of the deal, not as extras: analytics and conversion tracking configured, a staging environment so changes are tested before they’re live, and access to every account in your own name.
Ask for a handover. A site you can’t administer, update or move is a site you don’t really own, however much you paid. A competent build leaves you able to make basic changes yourself and to hand the rest to any developer, not only the one who built it. If a proposal makes you dependent on one supplier forever, that dependency is the risk, whatever the price.
Decide up front who maintains the site after launch, because "nobody" is the answer that produced your current situation. Software needs updating, and updates occasionally break things that then need fixing — that’s normal ownership, not a sign of a bad build. A relationship that continues past go-live is what keeps a good site good.
This is the reasoning behind how we work: a dedicated account manager per client and monthly reporting in plain language, so the site is watched and measured rather than launched and forgotten. The reporting matters as much as the build — a site nobody is measuring is a site drifting back toward the state you’re trying to escape.
What does a website audit actually tell me before I commit?
An audit tells you which of the two paths you’re on — fixable foundation or unfixable one — with evidence, so the decision and any quote rest on what’s actually inside the site rather than on how it looks or who quotes cheapest.
An audit opens up the things you can’t see from the front: the platform and how it was built, the state of the code and plugins, the content structure, the security exposure, the performance ceiling, and whether anything is being measured at all. Those are exactly the factors that decide fix-versus-rebuild, and none of them are visible to a business owner looking at their own homepage.
It also catches the invisible losses — the missing tracking, the URLs quietly returning errors, the search rankings that may already be leaking. Often the audit itself surfaces the cheapest high-value fix, which is simply turning on measurement so that every decision after it is informed.
We offer the website audit free precisely because the decision should be made on evidence before any money changes hands, and because the honest recommendation is sometimes "fix this, don’t rebuild" — which is the opposite of what an agency selling rebuilds would tell you. Our diagnosis process runs the same way whether it points to a fix or a build.
Walk into the fix-or-rebuild decision with the audit in hand and the choice usually makes itself: the evidence points one way clearly enough that you’re no longer guessing, and you’re no longer at the mercy of whoever quotes the lowest number for work they haven’t looked at.
Common questions
Can you fix a site built by a developer I no longer have access to?
Usually yes, provided we can get into the hosting, domain and platform accounts. If those are held in the previous developer’s name, recovering them is often the first step — and getting them into your own name is worth doing regardless, because a site whose accounts you don’t control is one you don’t fully own.
Will rebuilding my website hurt my Google rankings?
Only if the rebuild is rushed. Rankings are lost when old URLs change without redirects pointing to their new equivalents. Map those redirects before launch, as Google’s own site-move guidance requires, and the rankings carry across to the new site.
How long does it take to know whether to fix or rebuild?
The audit that answers this is quick relative to the work itself, because it’s diagnosis rather than building. Timelines for the fix or rebuild that follows depend entirely on scope, so we scope those against what the audit finds rather than quoting blind.
Is it cheaper to just move to Shopify or WordPress than fix a custom site?
Often, yes. A custom or proprietary build that only its original author can work on tends to cost more to maintain than a fresh site on a mainstream platform costs to build, because you’re paying for scarcity every time something needs changing. The audit confirms whether that applies to your specific site.
My site works but is very slow — is that a fix or a rebuild?
It depends on why it’s slow. Sites that were never optimised can speed up dramatically with tuning — image compression, caching, cleaning up plugins. Sites slow because of how they were architected hit a ceiling no tuning gets past. Core Web Vitals measurements tell us which case you’re in.
What if my site is only half-finished, not broken?
Half-finished sites are common inheritances — the checkout works but the emails don’t, or the blog exists but can’t be updated. Whether it’s worth completing or restarting depends on how the finished part was built. If the foundation is sound, finishing it is the cheaper path; if the 80% that exists is unmaintainable, so is the 20% you’d add.
Do you charge for the website audit?
No — the website audit is free. We run it before any quote so the fix-or-rebuild decision is made on evidence, and so our recommendation isn’t dependent on selling you the more expensive option.
