A business website can look mostly fine and still be quietly expensive: enquiries stop arriving, checkout fails on mobile, a plugin update breaks a key page, analytics stop recording leads, or the site becomes so fragile that nobody wants to touch it.
So how much does it cost to fix a business website in 2026? There is no honest universal price. The cost depends less on the number of pages than on what is broken, why it broke, how risky the repair is, and how much testing is needed before the site can be trusted again.
A useful repair quote should therefore tell you what is being diagnosed, what will be changed, how the fix will be tested, and what happens if the visible symptom turns out to have a deeper cause.
Start by pricing the failure, not the website
Two websites can show the same symptom and require completely different work.
A contact form that “doesn’t work” might be a simple notification problem. It might also be successfully saving enquiries while email delivery fails, or it might never submit because of a JavaScript error. Replacing the form before tracing the failure can create more work without fixing the business problem.
I use the same principle for repairs that I use when planning products: follow the important user action from beginning to end before deciding what to rebuild.
| Repair level | Typical problem | What should happen before the quote is final |
|---|---|---|
| Isolated fix | Broken link, layout issue, missing image, small content or style bug | Reproduce the issue and identify the affected component |
| Functional repair | Form, login, booking, checkout, email or integration failure | Trace the full workflow and its dependencies |
| Performance repair | Slow pages, poor responsiveness, unstable layouts | Measure the real bottleneck before changing infrastructure |
| Conversion repair | Traffic arrives but visitors do not enquire, book or buy | Audit message, proof, CTA, form friction, mobile journey and tracking |
| Structural repair | Fragile CMS, conflicting plugins, unclear code ownership, repeated regressions | Assess whether targeted repair is still economically sensible |
| Rebuild | The current system cannot safely support the business requirement | Define what must be preserved, migrated and tested before replacement |
That distinction matters because a “website fix” can mean anything from changing one broken component to recovering a business-critical customer journey.
What actually changes the repair cost?
1. How easy the problem is to reproduce
A bug that happens every time on one page is easier to diagnose than an intermittent failure that only affects certain devices, browsers, logged-in users or payment states.
Good repair work begins with reproduction. If nobody can reliably trigger the failure, the first job is often observability: browser errors, server logs, form records, payment-provider events or analytics signals.
2. Whether the symptom and the cause are in the same place
The page a customer sees is not always where the fault lives.
A checkout can fail because of frontend JavaScript, an API, a payment callback, a database rule or a configuration change. A form can display a success message even though the notification never reaches the business inbox.
The more systems involved, the more the quote should account for diagnosis and testing rather than just visible editing.
3. The platform and quality of the existing build
A well-maintained WordPress site with current plugins is a different repair job from an old site with abandoned extensions and undocumented custom changes. The same is true for custom applications: clear repository history and predictable deployment reduce uncertainty; unknown production-only edits increase it.
Before significant changes, there should be a recoverable state. WordPress’s own ecosystem strongly reflects this practice: current backup tools explicitly support creating backups before updates or edits so a broken change can be reversed. See the WordPress plugin directory guidance around pre-update backups.
4. How much business risk the failure carries
A spacing problem on an About page is not priced like a checkout that is preventing orders.
Business-critical repairs require more careful testing because a rushed “fix” can move the failure somewhere less visible. For payments, bookings and lead capture, I would rather test the full state transition than celebrate because the button works once.
5. Whether the site is actually a repair problem
Sometimes the cheapest long-term answer is not another patch.
If every small change breaks something else, the site has no clear owner, the hosting account is inaccessible, the CMS is no longer maintainable, or the customer journey needs to change substantially, you may be looking at a redesign or rebuild decision rather than a repair ticket.
That is why diagnosis should happen before a large redesign proposal, not after it.
A repair quote should separate four kinds of work
When comparing quotes, ask the provider to make these layers visible.
Diagnosis
What will they inspect, and what evidence will they use to identify the cause?
For a performance problem, for example, Google’s current Core Web Vitals framework focuses on loading, responsiveness and visual stability through LCP, INP and CLS. Search Console’s Core Web Vitals report is based on real-user field data, while lab testing can help reproduce specific problems. Google’s Web Vitals documentation and Search Console Core Web Vitals documentation are useful references when somebody claims a site is simply “slow.”
Repair
What exactly will change? A plugin, component, form route, hosting configuration, integration, page template or application logic?
Verification
How will the provider prove the important journey works after the change?
A repair to a lead form should test more than the button. The submission should be stored or transmitted correctly, the business should receive it, the visitor should see the right confirmation, and analytics should record the action if measurement is part of the setup.
Recovery and handoff
What happens if the change causes a regression? Who owns the code, accounts and documentation afterwards?
This becomes especially important when you are taking over a site from someone else. If that is your situation, read My Web Developer Disappeared: How to Rescue an Unfinished Website before giving a new person access.
Repair vs maintenance: they are not the same purchase
Repair is reactive. Something is already broken or underperforming.
Maintenance is ongoing work intended to reduce the chance that routine updates, security issues, expired dependencies or unnoticed failures accumulate into a larger problem.
If your site is healthy but you are deciding what ongoing support should cost, use my website maintenance cost guide. If the site has an active failure, diagnose that first. A maintenance plan should not become a vague monthly fee for repeatedly patching the same unresolved problem.
Repair vs redesign: use the smallest intervention that solves the business problem
A redesign is justified when the problem is broader than one component.
For example, suppose a professional-services website gets traffic but almost no qualified enquiries. The form may work perfectly. The real issue might be that visitors cannot understand the offer, see relevant proof, know who the service is for, or decide what to do next.
That is not a “broken form” repair. It is a conversion and customer-journey problem.
Conversely, if the site already communicates the offer well and one integration has failed, redesigning the entire interface is wasteful.
A practical rule is:
- repair when the underlying system is sound and the failure is bounded;
- redesign when the customer journey or communication is the main problem;
- rebuild when the underlying implementation cannot safely or economically support what the business now needs.
If you are getting visitors but not enough customers, the existing traffic-but-no-sales guide helps separate acquisition problems from conversion problems before you pay for a visual overhaul.
Questions to ask before paying for a website repair
You do not need to understand the code. You do need to understand the agreement.
Ask:
- Can you reproduce the problem? If not, what will you do to diagnose it?
- What does the quoted amount include? Diagnosis, implementation, testing, deployment and follow-up should not be ambiguous.
- What could increase the price? Unknown third-party code, inaccessible accounts and deeper infrastructure problems should be stated as risks.
- Will you create or verify a backup before changing production? A repair should have a recovery path.
- How will you test the actual business action? “The page loads” is not enough for a booking, payment or lead workflow.
- Will I keep ownership of my domain, hosting, repository and third-party accounts? Repair should not create a new dependency on the person fixing the old dependency.
- What happens if the same issue returns? Clarify the boundary between a failed repair, a new problem and ongoing maintenance.
- Will you tell me if repairing this is no longer sensible? A trustworthy diagnosis can conclude that the current system should not receive another patch.
When a cheap fix becomes expensive
The dangerous repair is not necessarily the expensive quote. It is the cheap change that hides the symptom while leaving the failure mechanism intact.
I have seen the same pattern across websites and web products: the visible problem is often one step in a longer system. A payment is not just a button. A form is not just a field set. A deployment is not just a successful build. Ownership is not just having a password today.
That systems view is useful because it keeps the repair proportional. You do not need to rebuild everything, but you do need to understand enough of the surrounding workflow to avoid fixing the wrong layer.
What to send when asking for a repair quote
You will get a better estimate if your first message includes:
- the website URL;
- what you expected to happen;
- what actually happens;
- when you first noticed the problem;
- whether anything changed shortly before it started;
- the devices or browsers where you can reproduce it;
- screenshots or exact error messages;
- the platform, if you know it;
- whether the issue blocks enquiries, bookings, orders or payments;
- whether you control the domain, hosting and source-code accounts.
Do not send passwords in an initial enquiry. Access can be handled securely after scope and identity are clear.
Need to know whether your site needs a fix, redesign or rebuild?
If the website is losing enquiries, breaking after changes, failing on mobile, or you have inherited a build you no longer trust, the first useful step is diagnosis.
Send me the website and describe what is failing. I can help you determine whether the smallest sensible intervention is a targeted repair, a conversion-focused redesign or a controlled rebuild. If the problem is broader and you already know you need a new business website, see my web design service.
