The site is down and the person who built it is gone.
Here is how to stop the bleeding first.

Triage first, diagnosis second

When a site is down and generating no sales, the instinct to fix everything at once is understandable, and usually the wrong move. The first hour should rule out the boring causes, because they are common and fast to fix. An expired domain. A lapsed hosting payment. An SSL certificate that quietly ran out. A plugin update that broke on its own schedule. A surprising share of “the developer disappeared and now the site is down” cases turn out to be one of these, not a deep code problem.

What an actual audit looks for

If the obvious causes are ruled out, the next step is reading the code and the server itself. What changed right before the outage. What the error logs actually say. Whether the problem sits in the application code, a database, a third-party integration, or the server configuration. For a site of normal size, this is usually a matter of days, not weeks. It ends with a written list of what is broken, ranked by what is actually costing money versus what is just untidy.

Fixing without starting over

Most sites that break after a developer leaves do not need a rewrite. They need the specific broken part fixed, and the rest of the system left alone. A rewrite throws away everything that already worked, and replaces a known outage with months of new risk. Rebuilding only makes sense where the audit genuinely shows it is cheaper than fixing what exists. That is a decision made with real numbers, not a default answer.

Why “nobody understands the code” is fixable

A site with no documentation feels unrecoverable, but the code itself almost always explains what it does, if someone reads it carefully. Database structure. How pages are generated. What each integration is for. All of this is discoverable without the original developer, just slower than it would be with their notes. Once the outage is resolved, the real fix is writing down what was found, so the next person does not start from zero again.

Getting past “one person away from another outage”

Once the site is back up, fix the setup that let one person’s disappearance take the whole business offline. Hosting and domain access the business controls directly. A second person who can at least check whether the site is alive. Documentation of how the system is built. None of this prevents every future problem. It does turn the next outage into an hour of inconvenience, instead of a crisis with nobody able to log in.