Fixing an inherited site rarely means starting from zero — the cost depends on what a developer can salvage versus what has to be torn out and rebuilt.
Does fixing a badly built website mean starting from scratch?
Usually not. Most of what makes a site valuable — its content, images, domain, and search history — lives separately from the code that renders it, so those assets carry across even when the underlying build is scrapped and replaced.
When people fear a rebuild, they are usually picturing losing everything they have accumulated: years of blog posts, product descriptions, the Google rankings, the email list, the domain everyone already knows. In practice those things are decoupled from the code. Your content sits in a database or can be exported; your domain is registered independently; your rankings attach to URLs, not to the framework rendering them. A rebuild replaces the machinery, not the cargo.
What actually gets thrown away is the part that was making your life hard in the first place — the bloated theme, the conflicting plugins, the custom code no one can safely touch. That is the liability, not the asset. Losing it is the point.
The honest exception is when the previous build entangled content and code so tightly that separating them is itself the work. A site where product data is hardcoded into templates rather than stored as data, for example, means the migration is manual. That is recoverable, but it is where the hours go, and it is exactly what an audit is meant to surface before anyone commits.
Before we quote anything at BluPixel, we run a free website audit to establish which of these situations you are actually in. A reader who assumes the worst tends to over-scope and over-pay; a reader who assumes the best inherits the same problems in a new coat of paint. The audit is the cheap way to find out which.
What does a rebuild keep from the old site, and what gets scrapped?
You keep the assets — content, media, domain, rankings, and usually the database — and you scrap the delivery layer: the theme, the plugins, the hosting setup, and any custom code that can’t be maintained.
It helps to separate a website into what it holds and what renders it. What it holds is durable and portable. What renders it is where bad builds do their damage, and it is the part most worth replacing.
Deciding what to keep is not automatic. Some content is worth migrating as-is, some is worth rewriting on the way over, and some — thin pages, duplicate category pages, abandoned drafts — is worth deliberately leaving behind so the new site starts lean. That editorial decision is separate from the technical one and often gets skipped, which is how a rebuild ends up carrying forward the same bloat it was meant to fix.
| Asset | Typically kept | Usually scrapped |
|---|---|---|
| Written content and product data | Yes — exported and migrated | Only if it’s thin or duplicated |
| Images and media library | Yes — re-optimised on the way over | Oversized unoptimised files |
| Domain name and email | Yes — always | No |
| Search rankings / SEO history | Yes — via redirect mapping | No, if URLs are handled well |
| Theme and page templates | Rarely | Usually — this is the problem layer |
| Plugins and custom code | Case by case | Undocumented or conflicting ones |
| Hosting environment | Sometimes | If it’s the cause of slowness |
Why is one badly built site cheap to fix and another expensive?
The cost is set by how the previous developer built the site, not by how many pages it has. A clean, standard build is quick to work on; a tangle of custom code and undocumented plugins takes hours just to understand before anything can be changed.
Two sites can look identical to a visitor and cost wildly different amounts to fix. The difference is under the hood. A site built on a well-supported theme with standard plugins is something any competent developer can pick up and work on immediately. A site where the previous developer hand-rolled custom functionality, left no documentation, and modified core files is one where the first several hours are spent just working out how it hangs together.
This is why page count is a poor guide to cost. A 200-page site built cleanly can be cheaper to work on than a 12-page site held together by five conflicting plugins and a payment integration someone bodged in. The question a developer is really pricing is: how long before I can safely change something without breaking three other things?
Custom code is the single biggest variable. Custom is not automatically bad — but custom that nobody documented, that depends on a specific old version of PHP, or that was written by someone no longer reachable, is a liability priced accordingly. When you brief an agency, the most useful thing you can hand over is any documentation, login list, or access to the original developer, because it shrinks the discovery phase directly.
The other quiet cost is access. Sites where the previous developer holds the hosting, the domain, or the admin accounts and won’t hand them over turn a technical job into a recovery job. Establishing who controls what is part of any audit worth the name.
Should I repair the site I have or rebuild it?
Repair when the foundation is sound and the problems are specific and contained; rebuild when the problems are structural, when the platform is unmaintainable, or when the cost of understanding the old code approaches the cost of replacing it.
The instinct to repair is usually the right starting point, because it is cheaper and keeps more intact. Repair makes sense when you can name the problems — a slow homepage, a broken checkout, a form that stopped sending — and they trace to identifiable causes rather than the whole build being rotten.
Rebuild becomes the honest answer when the problems are systemic: the site is slow everywhere because the theme is bloated everywhere, the platform is on a version that can no longer be updated safely, or every fix risks breaking something else. At that point money spent repairing is money spent propping up something that will need replacing anyway.
There is also a middle path that gets overlooked: keeping the platform and the content but replacing the theme. On WordPress especially, moving from a heavy, poorly coded theme to a clean one can resolve most speed and maintainability problems without a full ground-up rebuild. It is worth asking about, because it often sits at a fraction of the cost of a full rebuild.
The deciding test is comparative, not absolute. If understanding and safely modifying the old build will take nearly as long as building fresh, rebuild — you get a maintainable result for similar money. If the old build is basically sound, repair and stop there.
RepairFoundation is soundProblems are specificand namedPlatform is current andsupportedLowest cost, fastestturnaroundRe-themeContent and platformworth keepingTheme is the source ofslownessStructure is fine,delivery isn’tMid-range costRebuildProblems are structuralPlatform can’t beupdated safelyUnderstanding old code ≈building newHighest cost, cleanestresult
Will a rebuild wreck my Google rankings?
Only if redirects and URL structure are handled carelessly. Rankings attach to URLs, so a rebuild that maps every old URL to its new equivalent preserves search history; one that changes URLs without redirects loses it.
This is the fear that keeps people on a broken site, and it is legitimate — plenty of rebuilds have tanked traffic. But the cause is almost always avoidable. Google associates your accumulated authority with specific URLs. Change or drop those URLs without telling search engines where the content moved, and you throw that authority away.
The fix is a redirect map: a documented one-to-one plan pairing every meaningful old URL with its new home, implemented as permanent redirects at launch. Done properly, a visitor or a search crawler hitting an old link lands on the right new page and the ranking follows. Skipped or done loosely, you get a wall of dead links and a traffic collapse that takes months to recover from.
Keeping the URL structure identical where possible removes the risk entirely — if the addresses don’t change, there is nothing to redirect. Where the new site genuinely improves the structure, the redirect map absorbs the change safely. Either way it is deliberate work, not something that happens on its own, and it belongs in the scope from the start.
Because SEO and web development sit under one roof at BluPixel, redirect mapping is treated as part of a rebuild rather than a separate afterthought handed to a different team once the site is already live and the damage is done.
How do I know how bad my current site actually is?
An audit measures it against objective standards — load speed, mobile behaviour, code health, security, and search visibility — instead of guesswork, and tells you whether you’re facing a repair, a re-theme, or a rebuild.
Owners usually know something is wrong long before they can say what. The site ‘feels slow’, sales ‘seem down’, the developer ‘stopped answering’. An audit converts those feelings into specifics you can act on and quote against.
A useful audit checks measurable things: how the site scores on Google’s Core Web Vitals, whether it works properly on phones, whether the code and plugins are current and secure, whether search engines can crawl and index it, and whether analytics and conversion tracking are even installed correctly. Each answer points toward repair, re-theme, or rebuild.
It also flags the non-technical risks that quotes miss — who owns the hosting, whether backups exist, whether the previous developer left access you can’t revoke, whether the platform is on a version that will stop receiving security updates. Those determine the real cost more than the visible symptoms do.
BluPixel offers this audit free, and the reason is self-interested in an honest way: the wrong scope wastes everyone’s time. We would rather tell you the site needs a small fix than sell you a rebuild you don’t need, and the audit is how that conversation starts on facts.
How do I make sure I don’t end up with a badly built site again?
Insist on ownership and standards up front: you hold the domain, hosting, and admin accounts, the build uses maintainable standard tools, and you receive documentation. The way to avoid a second bad site is to make the next one handoverable.
Most badly built sites weren’t badly designed — they were badly built to hand over. The design looked fine; the problem was code only the original developer could touch, accounts only they controlled, and no documentation for anyone who came after. Avoiding a repeat is about the terms as much as the craft.
Establish ownership before work starts. You should hold the domain registration, control the hosting account, and have full admin access to the site and every connected service. If an arrangement leaves any of those in someone else’s hands, you are one dispute away from being locked out of your own business.
Favour maintainable, standard tools over clever custom ones. A site built on a mainstream platform with well-supported components can be picked up by any competent developer if your relationship with the current one ends. A site built on bespoke code ties you to one person, which is precisely how the last one went wrong.
Ask what you get at the end: documentation, a list of every account and plugin, and clarity on who can maintain it. At BluPixel each client works with a dedicated account manager and receives plain-language monthly reporting, which is the same principle applied to the relationship — you should always be able to see what has been done and take it elsewhere if you choose.
Common questions
Can you fix a site the original developer refuses to hand over?
Often, but it depends on what they control. If they only hold the code and you own the domain and hosting, a new build can replace theirs cleanly. If they control the hosting or domain itself, recovering access becomes the first task — and it’s a reason to establish ownership on any future project before work begins.
How long does a rebuild take?
It varies with scope and with how much of the old site can be salvaged. A re-theme that keeps the platform and content moves faster than a ground-up rebuild that has to untangle custom code first. An audit gives a realistic timeline because it establishes how much discovery work stands between the current site and a clean one.
Is WordPress or Shopify better for a rebuild?
It depends on what the site does. Shopify suits e-commerce that wants a managed, hosted platform with less maintenance overhead; WordPress suits content-heavy sites and cases needing more custom flexibility. We build on both and choose based on what you’re selling and who will maintain it, not on a house preference.
Will I lose my content during the migration?
No — content is exported and migrated deliberately, and a proper migration keeps a backup of the old site until the new one is verified. The risk isn’t losing content; it’s carrying forward thin or duplicate content that should have been left behind, which is a decision made during the rebuild rather than an accident.
Do I need a full rebuild if my site is just slow?
Not necessarily. Slowness often traces to a heavy theme, unoptimised images, or poor hosting — each fixable without a full rebuild. Sometimes it’s site-wide and structural, in which case a re-theme or rebuild is warranted. The audit distinguishes the two by measuring against Google’s Core Web Vitals rather than guessing.
What happens to my email and analytics during a rebuild?
Email tied to your domain continues independently of the site rebuild as long as the domain and DNS are handled carefully. Analytics and conversion tracking are re-verified at launch — a common flaw in inherited sites is tracking that was broken or never installed correctly, so a rebuild is a good moment to fix it properly.
