The cost of taking over an inherited WordPress site depends almost entirely on what an audit finds under the surface, which is why a fixed price should follow the audit rather than precede it.
It depends on whether the site’s foundation is sound. If the theme and structure are workable and the problems are contained, fixing is cheaper; if the problems are structural, rebuilding usually costs less over any real timeframe because you stop paying to work around them.
The instinct with an inherited site is to fix it, because a rebuild sounds bigger and more expensive. Sometimes that instinct is right. But a lot of the sites we are handed were built in a way that makes every fix slower than it should be — a change that would take an afternoon on a well-built site takes two days because you first have to reverse-engineer what the last person did and why.
The honest answer is that nobody can tell you which is cheaper until someone has looked underneath. The visible problems — a broken form, a slow page, a layout that falls apart on mobile — are rarely the whole story. What decides the cost is the stuff you cannot see from the front end: how the theme was assembled, whether the layout lives in templates or in the database, how many plugins are doing load-bearing work, and whether there is any version control at all.
Where the visible list of problems is short and the foundation is sound, fixing is almost always the cheaper path and we will tell you so. Where the same problems keep coming back, or where fixing one thing breaks another, that is usually a sign the foundation is the problem, and no amount of patching gets ahead of it.
This is why we quote a takeover after an audit, not before. A number pulled out of the air before anyone has seen the code is a guess dressed up as a quote, and the person who pays for the gap between the guess and the reality is always the client.
Through an audit that looks at the theme structure, the plugin stack, the hosting, the database and whether there is any version control — not just at the symptoms you can see on the front end.
The symptoms a client describes are the starting point, not the diagnosis. Someone reports the site is slow; the real question is whether it is slow because of unoptimised images, a bloated plugin doing too much, a cheap shared host, or a theme that runs dozens of database queries to build a single page. Each of those has a different fix and a different cost.
An audit answers a handful of specific questions. How was the theme built — is the layout in template files or scattered across database rows built by a page builder? How many plugins are installed, and how many are actually needed? Is there a repository, or does the live server hold the only copy of the code? What is the hosting, and is it the bottleneck? Is the database clean, or has years of orphaned data accumulated?
The page-builder question matters more than people expect. When a layout is built with a visual page builder, the design lives as data in the database rather than as code in a template. That makes the site heavy, ties you to a specific plugin forever, and means the layout cannot be version-controlled the way real code can. We do not build that way, and inheriting a site built that way changes the maths on fix-versus-rebuild considerably.
The audit is also where the unknowns get counted. Inherited sites are full of them, and unknowns are what blow up budgets. Finding them before work starts is the entire reason a fixed price is possible at all.
Rescue when the foundation is sound and the problems are contained to specific features or a specific plugin; rebuild when the problems are structural — a page-builder layout, no repository, or a plugin stack that fights every change.
A rescue keeps the existing site and repairs what is broken. It is the right call when the theme is reasonably built, the site is version-controlled or can be brought under version control cleanly, and the trouble is confined — a broken checkout, a failing integration, a specific feature that never worked. WooCommerce rescues are a common version of this: a store that mostly works but has one part of the order or payment flow that has been quietly costing the owner money.
A rebuild replaces the underlying code while keeping your content, your URLs and your brand. It is the right call when the problems are everywhere at once, when the site is built on page builders and cannot be maintained without them, or when there is no clean copy of the code to work from. In those cases every rescue fix is temporary, because the thing causing the problems is the thing you are keeping.
The deciding factor is usually how contained the trouble is. One broken feature on a sound site is a rescue. A site where fixing one thing reliably breaks another is telling you the foundation is the problem, and that is a rebuild.
The table below sets the two paths against each other so you can see which describes your situation before you spend anything on either.
| Factor | Points to a rescue | Points to a rebuild |
|---|---|---|
| Theme | Built in template files, reasonably clean | Built with a page builder, layout lives in the database |
| Version control | Repository exists or can be added cleanly | No repository, live server holds the only copy |
| Problems | Contained to one feature, plugin or page | Structural, recurring, one fix breaks another |
| Plugin stack | A manageable set, each doing a clear job | Dozens of plugins, unclear what’s load-bearing |
| Cost over time | Lower if problems stay contained | Lower because you stop paying to work around the foundation |
You keep your content, your page URLs, your images and your search rankings. What you generally do not keep is the underlying code, which in a rebuild is the thing you are deliberately replacing.
The fear behind most rebuild decisions is losing everything — the content written over years, the search rankings earned over years, the URLs that other sites link to. None of that has to go. Content lives in the database and moves across intact. URLs can be preserved exactly, or redirected properly where they change, so links and rankings survive.
Search rankings are preserved by keeping the URL structure stable and mapping any changes with redirects, not by keeping the old code. Rankings are attached to your content and your addresses, not to the theme underneath them. A rebuild done carefully is invisible to Google except that the site becomes faster, which helps rather than hurts.
The design can be kept, refined, or replaced — that is a scope decision, not a technical constraint. Plenty of rebuilds keep the existing look almost exactly and only replace the broken foundation beneath it, because the client was never unhappy with how the site looked, only with how it worked.
What you replace is the code. On a rebuild we put the site on a custom theme with the layout in template files, not in database rows, and the whole thing goes into a repository on your own account. That is the difference that stops the next owner of the site from inheriting the problem you inherited.
Without a repository, the live server holds the only copy of the code, so every change is riskier, harder to review, and impossible to roll back cleanly — and that risk gets priced into the work.
Version control — a repository — is a complete, tracked history of the code with the ability to review changes before they go live and undo them cleanly if something breaks. A surprising number of inherited sites have none. The code exists only on the live server, edited in place, with no record of who changed what or how to get back to a working state.
When there is no repository, every change is performed without a safety net. You cannot test a fix in isolation, you cannot roll back a mistake in seconds, and if the live edit goes wrong the site is down while you work out what you did. That risk is real work to manage, and it gets reflected in the cost of any change.
The first thing we do on a takeover is bring the code under version control if it is not already, in a repository on the client’s own account. From that point every change is reviewable, reversible and tracked, and the site is far cheaper to maintain — which is exactly why we hand new-build clients the repository from day one.
Ownership matters here too. When the repository is on your account rather than the developer’s, you are never locked in. If you and your developer part ways, the next one starts with the full history in hand instead of reverse-engineering a live server, and that alone can save more than the takeover cost.
It varies with what the audit finds, but a takeover starts with access and an audit, then either a contained set of fixes or a full rebuild on a staging URL, with the live site untouched until the replacement is ready.
There is no honest single number, because the timeline is set by what the audit uncovers, and inherited sites are unpredictable by nature. A rescue of one broken feature on a sound site is short work. A full rebuild of a large store with several integrations is not. The audit is what turns an open-ended job into a defined one with a scope and a timeline attached.
Whatever the path, the live site keeps running throughout. We build and fix on a staging URL that is live from the first day of the work until launch, so you and we can both see progress at any point and nothing is happening blind on your production site. There is no window where your site is down while work is underway.
Launch is a planned switch, not a leap of faith. Because the new or repaired version has been visible on staging the whole time and the code is in version control, going live is a controlled step with a clear way back if anything surprises us — which, on a site that has been properly audited first, it rarely does.
Scope changes are the main thing that moves a timeline, and they move it because you have asked for something new, not because we guessed wrong. The fixed price and timeline hold for the scope agreed; if the scope changes, the number changes with it, openly, rather than quietly.
Get your WordPress admin login, your hosting account login and your domain registrar login, plus whatever documentation the previous developer left, because a developer who cannot get into the site cannot audit or quote it.
The single biggest delay on a takeover is access. People inherit a site and discover they do not actually control it — the hosting is in a former agency’s account, the domain is registered under someone who has left, the WordPress admin password is lost. Sorting that out can take longer than the technical work, so start on it before you call anyone.
At minimum you want three logins: admin access to WordPress itself, access to the hosting account where the site lives, and access to the domain registrar where the domain is managed. If any of these sit with a previous developer or a former employee, begin recovering them now, because you will need them regardless of who does the work.
Anything the previous developer left is useful — documentation, a list of plugins and their licences, notes on custom functionality, records of any paid tools the site depends on. Paid plugin licences in particular can lapse and quietly break things, so knowing what the site relies on is worth the search.
You do not need to diagnose anything yourself. Write down the symptoms as you experience them — what is slow, what is broken, what you wish worked differently — and leave the diagnosis to the audit. The symptoms plus the access are enough to get a real conversation started.
The common failures are quoting before auditing, editing directly on the live site with no repository, and adding another layer of plugins or page-builder work on top of the mess instead of fixing the foundation.
The first failure is a quote given before anyone has looked underneath. It feels reassuring to get a fast number, but a takeover quoted without an audit is a number that will change, and it changes in one direction. The fixed price only means something if it comes after someone has counted the unknowns.
The second failure is working directly on the live site with no version control and no staging. It is faster in the moment and it is how a lot of the broken sites we inherit got broken. One edit goes wrong, there is no clean way back, and the site is down. Staging and a repository exist precisely to stop this, and skipping them is a false economy.
The third failure is treating symptoms by piling on more of what caused them — another plugin to paper over a slow page, more page-builder work on a layout that should have been rebuilt. Each layer makes the next problem harder to reach and the site heavier. It is why some inherited sites have thirty or forty plugins doing the work a properly built theme would do on its own.
Subcontracting is the quieter version of the same problem. When the studio you hire passes the work to someone you never speak to, accountability thins out and the person who understands your site is not the person you can call. We keep every project in-house with our own fourteen-person team for exactly that reason — the people who build or rescue your site are the people you deal with.
We audit first, quote a fixed scope and fixed price after we’ve seen the code, build or fix on a staging URL with the live site running, and hand you a repository on your own account so you’re never in this position again.
We have spent eleven years and over 340 projects on WordPress, and a steady share of that work is inheriting sites other people built — including WooCommerce stores that need rescuing rather than replacing. So the process is built around the reality of an inherited site: unknowns first, decisions second.
We start with access and an audit, then quote a fixed scope and fixed price. That number does not move unless the scope moves, and if it does move you will know why. The work happens on a staging URL that is live from day one until launch, so your production site is never the workbench and you can watch progress the whole way through.
When it is done, the code sits in a repository on your own account, not ours. You own it from the start, which means the next developer — us or anyone else — inherits a clean, tracked, documented site instead of the puzzle you were handed. We carry professional liability insurance and will sign your NDA or ours before we begin.
Maintenance afterwards, if you want it, has no lock-in — you can cancel with thirty days’ notice — and our median first support response is four hours. Ninety-six percent of our clients are still with us after their first year, which we take as the real measure of whether the takeover was worth it.
No, and you should be wary of anyone who does. The cost of a takeover lives in things that are invisible from the front end — the theme structure, the plugin stack, whether there’s a repository. We audit first, then give a fixed price that doesn’t move unless the scope does.
Yes, if it’s done carefully. Rankings are tied to your content and your URLs, not to the code underneath. We keep the URL structure stable and use proper redirects for anything that changes, so search engines see continuity. A rebuild usually helps rankings because the site gets faster.
Recovering access is often the first task, and it can take longer than the technical work if the previous developer or a former employee still controls the accounts. Start on it before you call anyone — you’ll need your WordPress admin, hosting and domain registrar logins whoever does the work.
Not necessarily. Whether hosting is part of the problem is one of the things the audit answers. Sometimes a cheap or overloaded host is the real cause of a slow site; often it isn’t, and there’s no reason to move. We’ll tell you which applies to your site rather than moving it by default.
Often, yes — that’s what a rescue is. If your site’s foundation is sound and the trouble is contained to one feature, plugin or page, we fix that and leave the rest alone. We only recommend a rebuild when the problems are structural enough that fixes won’t hold.
No. We build and fix on a staging URL that stays live from the first day until launch, so your production site keeps running the whole time. Going live is a planned switch, and because the code is in version control there’s a clean way back if anything surprises us.
No. Maintenance is optional, and if you take it there’s no lock-in — you can cancel with thirty days’ notice. Because the code lives in a repository on your own account, you’re free to take the site elsewhere at any point without our help.