My developer disappeared. How to get your website, code and accounts back

Your emails are not being answered. The phone goes to voicemail. Somewhere out there is a website with your business on it, and you are no longer certain you can get into any part of it. If your developer disappeared without ever handing anything over, and you are reading this at eleven at night with a growing sense that something valuable is slipping away, start here.

Almost all of it can usually be recovered, and the order matters: the domain first, then hosting and a backup in your own hands, then the code, then the accounts, then your data. The domain comes first because it is the only piece with a deadline attached. Everything else will wait for you. A domain that expires will not.

Your developer disappeared: what you can usually recover

The word "website" hides half a dozen separate things, each held by a different company, each recovered a different way. Knowing which is which is most of the battle.

Step 1: The domain, because it is the only thing with a clock on it

A WHOIS lookup tells you three things that decide your next hour: which registrar holds the domain, when it expires, and whose name and email are on it. Read the expiry date first.

1. If it is registered in your name or your email address, you are in better shape than you think. Go to that registrar, use the password reset, and take control today. Then turn on the transfer lock and auto-renewal.
2. If it is registered to your developer or their company, write to them, once, in plain terms: you are asking them to remove the transfer lock and send you the authorisation code (also called an EPP or auth code) so the domain can move to an account in your name. Date it, give a reasonable deadline, and keep a copy. Written requests matter later.
3. If nothing comes back, go to the registrar itself rather than the person who sold it to you. Resellers are not accountable to anyone in particular, but the accredited registrar behind them is, and they handle this kind of dispute regularly. Have your evidence ready: company registration, invoices that show you paid for the domain, your trading history under that name, and the emails you sent.
4. If the expiry date is close, renew it anyway, even while the ownership question is unresolved, and even if it feels wrong to pay. Most registrars will accept a renewal payment for a domain from anyone holding the details. This is the cheapest insurance in this entire guide.

If the date has already passed, do not assume it is gone. There is normally a grace period in which you can simply renew, then a costlier redemption period where recovery still works but with an added fee, and only after that does the name drop and become available to anyone in the world. The gap between those stages is measured in weeks, so this is the part of the guide to act on today rather than at the weekend.

One thing that catches people out: a domain cannot be transferred to a new registrar within 60 days of being registered or of a previous transfer, and some registrars apply a similar hold after the registrant details change. That delays the move, not your control. You can still renew it and still point it wherever you like in the meantime.

Step 2: Hosting, DNS, and a backup in your own hands

Follow the money. Somewhere in your statements is a recurring charge to a hosting company, and that name is worth more than any amount of guessing. If your developer paid for it, the nameservers in your WHOIS result usually point at either the host or a DNS provider such as Cloudflare, which gives you the next door to knock on.

Contact that company's support team, explain that you are the business the site belongs to and that you have lost contact with the person who set it up, and ask what they need to establish that. They handle this constantly. Company documents, matching invoices and consistent contact history are the usual currency.

The moment you have access, take a full backup: every file and the database, downloaded to your own computer and one other place you control. Not a backup that lives in the same account you have just been given, which does you no good on the day that account is closed. Do this before you change a single setting.

• If you have hosting but cannot get into the site itself, a WordPress dashboard with no password you know, the host's own control panel can usually solve it: their database tool can add a new administrator account directly. Take the backup first. If that sentence makes you nervous, this is the sensible moment to put a technical person on it rather than experiment on a live site.
• Write down every DNS record before you change anything. Your email almost certainly depends on records in the same place as your website. Moving a site without carrying its mail records across is how a recovery turns into a second emergency at eleven the next morning.
• Once you control DNS, you control the address. That is the point at which nobody can take your site away from you, whatever else is unresolved, because you decide where the name points.

Step 3: The code, and the part that is sometimes genuinely lost

Search your email for an invitation to a code repository: GitHub, GitLab and Bitbucket all send one, and it is often sitting in an inbox from two years ago. If you find it and the account is still active, you have the code and its whole history.

If not, the backup you just took may already contain it. For most small business sites, a WordPress build, an ordinary PHP site, a set of static pages, the files on the server are the site. There is nothing else to find.

It is harder for anything built with a modern toolchain, and for mobile apps. What sits on the server is the compiled output, not the readable source it was made from. If that source lived only on one laptop and was never pushed anywhere, it can be genuinely unrecoverable. That is the honest worst case in this guide, and it is worth knowing what it actually costs you: not the website, which keeps running, but the ability to change it cheaply. A rebuild that starts from a working site everybody understands is a far better position than a blank page, because every decision has already been made and proven in public. That is the job our redesigns and website rescues page describes. Our guide to what a website costs and what moves the price covers what that rebuild would realistically involve.

Step 4: The accounts and keys nobody thinks about until later

The website is the visible part. Behind it is a scattering of accounts that were opened on your behalf, often in somebody else's name, each of which will eventually need a password reset by a person who is no longer answering.

• Analytics. If nobody on your side is an administrator, the platform can help, but only once you prove you own the site, through a verification file, a tag on the page, or a DNS record. Now that you control DNS, that is far easier than it was last week.
• Search Console. Verify it yourself with a DNS record. Do this early: it is also where you will see if anything has gone wrong with the site's presence in search while all this was going on.
• Your business listing on Google or elsewhere. Request access through the listing itself. The current owner gets a window to respond, and if they do not, you escalate to support with your evidence.
• Payment, email and messaging services. Payment providers are usually already in your business name, because the money has to land somewhere. Transactional email, SMS and similar services often are not.
• App store accounts. Apps can be moved between developer accounts without losing reviews or users, but the process needs both sides to cooperate and both accounts to be in good standing. An app sitting in someone else's account is genuinely harder to move than a website, so raise this one early rather than last.
• Everything else with a login. Advertising accounts, the CDN, the certificate provider, form and booking services, review platforms, social profiles, the stock photo subscription nobody remembers buying.

When the dust settles, change every password, generate new keys for every service, and remove the old accounts and collaborators. Keys left in old code are a real exposure, particularly the ones that can take payments or send email as you.

Step 5: Your data, and what to do if the site is already gone

Export the things that are yours and irreplaceable: customer and order records, form submissions, the mailing list, invoices, uploaded documents. Get them into a format and a place you control, then test that a backup actually restores. A backup nobody has ever restored is a hope, not a backup.

If the site is already offline, the Wayback Machine has probably been quietly photographing it for years. Search your address there and you will often find usable snapshots going back a long way. Be clear about what that gives you: pages, text and images. It does not give you a database, an order history, customer logins or anything a form ever collected. It is enough to rebuild the front of the shop, not the business behind it.

Your material also exists in more places than you expect. The brochure, the PDF price list, the photographs on the photographer's own drive, the product descriptions in your supplier's catalogue, the posts on your social profiles. Recovery is often assembly rather than archaeology.

When a lawyer helps, and when they will not

• For access, usually not first. The registrar and hosting dispute processes exist precisely for this and are faster and cheaper than a letter from a solicitor. Exhaust those before paying anyone by the hour.
• For money, often yes. If you paid for work that was never delivered, put a written demand in first. If the payment was recent, your card provider may still allow a chargeback, and those windows have hard limits, so check the date rather than assuming. After that, a small claims process is designed for exactly this size of problem and does not need a solicitor in most places.
• When someone is actively holding your property to extract more money, stop negotiating alone and take advice. That behaviour tends to escalate, and a clear letter from someone who does this professionally often ends it.

The honest note: legal action is usually slower and more expensive than rebuilding, and it will not put your website back this week. Use it to recover money. Rarely use it to recover access, because there is almost always a faster technical route to the same place.

What this teaches, in one page

When the immediate crisis is over, and it will be, an afternoon spent on the following makes this impossible to repeat.

• Every account in your business's name, with the supplier added as a user you can remove: the domain, the hosting, the DNS, the content system, analytics, and everything with a login. Our guide to website cost covers what you should own at the end of a project in more detail.
• An account register. One document listing every account, who holds it, what it costs, when it renews, and which card it is on. Reviewed twice a year. It is dull, and it is the whole difference between a bad afternoon and a bad quarter.
• The code somewhere you control, even if you never look at it. A repository owned by your business, with your supplier invited into it, costs nothing and removes the worst case entirely.
• A written agreement that says the work, the code and the accounts are yours on payment. This is the piece that makes every other conversation short.
• A support arrangement with response times in it. A supplier who has agreed in writing when they will answer is a supplier who cannot quietly become unreachable. Our support SLAs and response times page sets out what that should say.

Not for you if

The order, one more time

1. WHOIS lookup. Find the registrar, the expiry date and the nameservers.
2. Secure the domain: reset it, request it, or renew it. Whatever else happens, do not let it expire.
3. Find the host through your bank statements, get in, and take a full backup you keep yourself.
4. Find the code, in a repository or in that backup, and accept early if the editable source is gone.
5. Recover the accounts, prove ownership through DNS where you can, then change every password and key.
6. Export your data and test that it restores.
7. Write down who holds what, so this can never happen to you twice.

Almost nobody loses everything. What people lose is time, and a good deal of sleep, working out which door to knock on first. That is the part this guide is meant to shorten. If the system you have recovered now needs somebody to look after it, taking on software we did not build is a normal piece of work rather than an unusual favour.