What we take on
WordPress sites and WooCommerce stores that are broken, compromised, slow, or at risk of becoming any of those.
- Core, theme and plugin faults.
- Update failures and the fallout from them.
- Compromise recovery.
- Store and order-path problems.
- Access and configuration problems.
- Diagnosis where nobody yet knows what is wrong.
Specifically, the last item is a service in its own right. Finding out what is actually wrong has value even when the answer is that we are not the right people to fix it.
What we need before work can start
- Authority from someone entitled to approve work on the site.
- A way to obtain the access the work requires.
- A hosting environment that permits that access.
- Somewhere to test, or explicit acceptance of the added risk where there is nowhere.
Authority matters more than it sounds. For example, a developer who built the site years ago is not automatically entitled to approve changes to it today, and acting on the wrong instruction creates a dispute nobody needs.
What we do not take on
- Recovering data that no longer exists. If content has been destroyed and there is no usable backup, no provider can bring it back.
- Faults that belong to the host. A failed server, suspended account, or hosting outage is theirs to fix. We can help establish that and escalate.
- Third-party outages. When a payment provider or external service is down, the fix is theirs.
- Abandoned or encrypted commercial code. Replacement may be the only responsible answer.
- Rebuild-scale work presented as a repair. Some sites need rebuilding rather than fixing.
- Legal, tax, and compliance advice. Technical recommendations can be implemented, but obligations require a qualified adviser.
- Work without authority, or anything unlawful.
Why the WordPress service scope excludes those
Each exclusion exists because taking the work on would mean charging for an outcome we cannot influence. In other words, the boundary protects you as much as us.
Host faults are the clearest case. We can prove where the fault sits and give you the evidence to escalate, but we cannot fix someone else’s server. Similarly, a rebuild sold as a repair starts cheap and ends expensive, so we would rather lose the enquiry than begin one.
Repair or rebuild: how the call is made
The question is not how bad the site looks. It is whether a bounded change can restore correct behaviour without rewriting the parts around it.
A repair is usually viable when the fault is traceable, the code is standard enough to reason about, and a safe way back exists. Conversely, a rebuild is the honest answer when the site depends on abandoned commercial code, when core files have been modified so widely that no clean reference remains, or when each fix reveals another broken assumption underneath.
We give that verdict before the work starts rather than halfway through it.
What a diagnosis delivers
Diagnosis is a deliverable, not a sales step. You receive the cause where it can be established, the evidence behind it, the change that would address it, and the risks attached to that change.
Importantly, you receive those findings even when the conclusion is that the repair is not viable, or that the fault belongs to your host. That written record is yours to take elsewhere.
When something falls outside
We explain what would need to be true for it to be in scope, and where the work more properly belongs. Consequently you leave with a direction even when the answer is no.
Where to go next
If something is broken now, start with WordPress support or, for a compromise, hacked site recovery. For a store fault, see WooCommerce support. If nothing is on fire, ongoing maintenance plans and security services are the preventive lane. The WordPress troubleshooting documentation is a reasonable starting point if you would rather investigate first.