When a website is failing, the instinct is to start fixing things. Disable a plugin, clear a cache, restore a backup, try a different host. Sometimes one of those works and the problem goes away. More often the symptom moves, the site half-works, and three days later nobody can describe what changed or why.
A diagnostic is the alternative: a structured investigation that establishes what is actually wrong before anything is changed. It is charged as its own piece of work, and the reasons for that are worth explaining, because it is the part clients most often want to skip.
Why the diagnostic comes first
Debugging by trial and error is expensive in three ways. It takes longer than investigation, because each attempt requires waiting to see whether the symptom recurs. It obscures the original state, so by the time someone competent looks properly, the evidence has been disturbed. And it fixes symptoms rather than causes, which means the same failure returns in a different form.
Charging for the diagnostic separately also removes a conflict of interest. If the investigation were free and only the repair were billable, there would be an incentive to find expensive problems. When the diagnostic is paid for regardless of what you decide to do next, the finding can simply be the finding — including “this is a twenty-minute fix” or “this site should be replaced rather than repaired”.
You keep the report either way. If you take it to another developer, or handle it in-house, that is a legitimate outcome.
Step one: stabilise and preserve
Before anything is examined, a complete backup is taken: files and database, stored somewhere independent of the host. This matters more than it sounds. Investigation sometimes disturbs things, hosts sometimes act unilaterally when a site is compromised, and having a known state to return to converts a crisis into an inconvenience.
If the site is actively down, serving malware, or leaking data, stabilising comes before investigating. That might mean putting up a holding page, taking a compromised site offline, or rotating credentials immediately. A site actively harming its visitors does not get to stay up while we read code.
Where the site is merely broken or slow rather than dangerous, it stays exactly as it is. A site reproducing its own fault is the most useful evidence available.
Step two: establish what changed
Almost every sudden failure has a trigger, and finding it collapses the search space enormously. So the first questions are chronological: when did it start, what happened around that time, what was updated, who had access, and was anything installed or removed?
These are cross-checked against evidence rather than memory, because memory is unreliable under stress. File modification times, plugin and core update records, hosting control panel logs, deployment history and server logs all carry timestamps. Frequently the client’s account of events and the timestamps disagree, and the timestamps are usually right.
A gradual decline is different — no trigger, just slow deterioration. That points toward growth: a database that has outgrown its indexes, a log table nobody truncates, a catalogue that has quadrupled since launch.
Step three: read the actual code and configuration
This is the part that cannot be shortcut and is the reason a diagnostic takes real time.
The theme is reviewed for custom code, particularly business logic that should have been in a plugin. The plugin list is reviewed for abandoned extensions, overlapping functionality and anything modified in place. Core files are checked for modification. Configuration is reviewed: PHP version and limits, database settings, caching layers, and whether a staging environment exists at all.
Two findings recur so often they are almost expected. The first is business logic buried in a theme’s functions file, meaning the site’s functionality is one design change away from disappearing. The second is a plugin that was modified directly rather than extended, so its updates have been suppressed for years and it is carrying known vulnerabilities.
Step four: the database and the logs
Slow sites usually have a database explanation. Query profiling shows which queries run on each page, how long they take, and whether they are using indexes. A category page taking eight seconds is rarely mysterious once you can see the query behind it.
The database is also checked for the things that accumulate quietly: expired transients, post revisions numbering in the tens of thousands, log tables nobody prunes, orphaned metadata from plugins removed years ago. None of these is a fault exactly, and collectively they can double a query’s cost.
Error logs are read properly rather than skimmed. PHP notices and warnings that nobody has looked at for two years are frequently pointing directly at the problem. Where logs have been disabled — a surprisingly common state — enabling them and waiting for the fault to recur is sometimes the fastest honest route.
Step five: security assessment
Even when the presenting problem is not a compromise, security is assessed, because an insecure site is a problem you have whether or not it has been exploited yet.
This covers installed components against known vulnerabilities, user accounts and their privilege levels, file permissions, whether administrative endpoints are exposed, and whether file integrity shows unexpected modifications.
Where a site has been compromised, the investigation extends to finding the entry point. This is not always possible: logs rotate, and by the time many sites reach us the evidence has gone. Where that is the case we say so plainly rather than inventing a narrative. What can always be done is closing the likely routes — patching, rotating credentials, reviewing accounts, removing unused access — so that whatever the route was, it is no longer open.
Step six: the report
The output is a written report, and it is written to be useful to someone who is not us.
Every finding is described with the evidence for it, the impact it has, and what fixing it involves. Findings are ranked by severity: critical means the site is down, insecure or losing money right now; high means working but degraded; medium means real problems not yet visibly costing you; low means worth doing when something else is already being changed.
Each item carries an estimate. Where a finding is a matter of judgement rather than fact — a plugin that is working but abandoned, a hosting arrangement that is adequate but constraining — that is stated as judgement rather than presented as an emergency.
Crucially, the report includes the option we would take. Not a list of everything possible, but a recommendation: fix these three things now, plan these two for next quarter, and consider replacing this component within a year.
When the answer is “replace it”
Sometimes the honest conclusion is that repair is not economic. A site built on an unsupported framework, dependent on abandoned components, with business logic tangled through a theme, can reach a point where every fix costs more than it should and introduces two new risks.
That conclusion has to be argued rather than asserted, because “you need a rebuild” is exactly what a client expects a developer to say. So the report shows the arithmetic: what the accumulated repairs would cost, what the ongoing maintenance burden looks like, what replacement would cost, and where the lines cross.
Often they cross further out than expected, and the recommendation is to keep the site running for another eighteen months while planning a replacement properly, rather than starting an emergency rebuild under pressure. Rebuilds started in a panic are how sites end up with the same problems in newer code.
What we need from you
Administrator access to the site, hosting control panel or server access, and DNS access if the fault involves mail or certificates. Alongside that, the honest chronology: what changed, who has access, what has already been tried. Anything already attempted is useful information rather than an embarrassment — knowing that restoring a backup did not help tells us something specific.
When the work is finished, we will tell you which credentials to rotate. Any access granted for a diagnostic should be revoked or changed afterwards as a matter of routine, regardless of who was given it.
