Taking over a website abandoned by its provider

No access, no repository, no documentation. The audit method I apply before saying whether to repair or rebuild.

The typical case

The provider has stopped answering. Nobody knows where the code is. The site is still running, and that is precisely the problem: as long as it runs, nothing forces anyone to act — until the day it stops.

Here is the order I work in. It never varies, because each step decides the next one.

1. Keys before code

A website is not just files. Before looking at a single line of PHP, I establish who holds what:

• the domain name, at which registrar, in whose name, and when it expires
• the name servers: who actually controls DNS
• hosting: SSH or FTP access, control panel
• certificates and their automatic renewal
• third-party accounts: payment, carriers, mail

It is the most thankless part, and the most urgent. A domain expiring while the budget is being discussed costs more than the rebuild.

2. Put it under version control immediately

If there is no repository, I take what exists and commit it the same day, before any change. The first commit is called “as found”. Its only purpose is to answer, later, the question “was it like that before?”.

Same for the database: a dated export, stored somewhere other than the server.

3. The audit, in four passes

Technical. Versions of PHP, of the CMS or framework, of the dependencies. What is no longer maintained. What prevents an upgrade.

Security. This is where the surprises are. On a recent audit, an in-house module read an identifier from the URL and injected it as-is into a delete query — with no escaping and no cast to integer. It took an employee session to exploit, so no public panic; but any account, however limited, could read the whole database. That kind of thing only shows up by reading the code.

Search engines. 302 redirects where 301s were needed, empty metadata, fully indexable subdomains duplicating the main content. These are quick fixes with immediate gains.

Performance. Response times, unresized images, missing caching.

4. Deciding: repair, extend, rebuild

The question is not “is the code beautiful”, but “can it still be changed without risk”. An ugly but healthy site gets repaired. An elegant site whose business logic nobody understands gets rebuilt.

I deliver the audit as a document a non-technical reader can follow: what is fine, what is costing money today, what will become blocking, and in which order to fix it. With the costs alongside. The client decides after that — including deciding to do nothing.

What I turn down

Taking over a site without an audit. That would mean committing to content nobody has looked at, and inheriting debt nobody has measured. It is also why the audit is free here: it protects the person receiving it as much as the person writing it.