My Web Developer Disappeared: How to Take Back Control of Your Website

The messages go unanswered for a week, then a month. The phone number rings out. Meanwhile the website keeps working, which is the strange part, and so the problem stays invisible right up until the day you need to change a price, add a page, or renew something you never knew you were paying for. Then you discover that every login, every renewal email and every password went to someone who is no longer there.

The same situation arrives by a different door when you inherit a website: you bought a business, joined a company, or took over from a colleague, and the site came with no credentials and no handover notes. Either way the job is identical. Work out what you own, get into each piece in the right order, and close the gap so it cannot reopen.

What should you do first if your web developer disappears?

Secure the domain name before anything else, because it is the one asset that can be lost permanently. Then list every account the website depends on and note who controls each one. Do not delete, cancel or rebuild anything yet. A site that is still running buys you time.

The instinct is to start with the website itself, since that is the part you can see. Resist it. A website can always be rebuilt from scratch if it has to be, at a cost. A domain that expires and is registered by someone else may never come back, and every link, every email address and every search ranking you have is tied to it.

So the first afternoon looks like this: find out when the domain expires, find out whose account it sits in, and write down every service you suspect the site uses. That list is your recovery plan. Everything after this is working through it.

Who actually owns your website?

A website is several separate assets, and each can be held by a different person. The domain is registered to a named registrant. The hosting is an account with a provider. The code and content live on that hosting. Around them sit email, analytics and search accounts. Owning one does not give you the others.

This is the part that catches many owners out. Paying invoices for years does not mean the accounts are in your name, and a developer who set things up "for convenience" in their own account was, legally and practically, the account holder. Two of these assets, the domain and the hosting, decide whether everything else is recoverable, and the rest follow once you hold those. Here is what to check and what you need for each:

How do you find out who controls your domain?

Run your domain through a public RDAP lookup, such as the one ICANN provides at lookup.icann.org. It shows the registrar, the expiry date and the nameservers. Contact that registrar, prove you are the business named as registrant, and ask for the account to be recovered or the domain transferred to you.

Since 2018 most registrant contact details are hidden in public lookups for privacy, so do not be alarmed if the owner field just says "redacted". The registrar still knows who the registrant is. What matters is whose name and organisation are on that record. If it is your business, you are the domain holder even if you have never logged in, and the registrar has a process to give you control. If it is the developer's personal name, recovery becomes a conversation with the registrar and possibly a legal one, which is why this step comes first.

Once you control the registrar account, you can move the domain anywhere you like. For generic domains such as .com, registrars must give you the transfer authorisation code within five calendar days of asking, under ICANN's transfer policy. Country domains such as .eg or .de follow their own registry rules, so check with the registry or registrar for those.

A practical tangent that saves real trouble: turn on auto-renewal the moment you have access, and change the account's contact email to an address on your own domain that you control. A common way to lose a domain is a plain missed renewal, because the reminders keep going to an inbox nobody reads anymore.

How do you get back into your hosting account?

Find out which company hosts the site, then ask them to verify you as the account holder. If the account is billed to your business, that is usually enough. If it is in the developer's name, the host can only hand it over with the developer's consent or a legal basis, so the fallback is to copy the site out instead.

Finding the host is detective work but rarely hard. Your DNS records point at a server, and a lookup of that server's address usually names the provider. Old invoices and card statements are often quicker.

If the hosting account cannot be recovered, you do not necessarily need it. As long as the site is still publicly reachable and you control the domain, the site can be rebuilt or copied onto new hosting and the domain pointed there. Some sites can be exported almost completely from the outside; others, especially anything with a database behind it, need proper access to move cleanly. This is where we usually start a rescue: establish what can be recovered from the existing server and what has to be reconstructed, then move it onto hosting the owner controls.

What if you can't log in to the website itself?

If the site runs on a common CMS such as WordPress, an administrator password can be reset from the hosting account through the database or the platform's own tools, so hosting access usually solves this. If it was custom-built, you need the source code. If it was built on a hosted builder, it lives inside whoever holds that builder account.

These three cases behave very differently, so identify which one you have before planning anything:

• A standard CMS. The easiest case. With hosting access, a new administrator account can be created or the old password reset. WordPress documents several ways to do this, including directly through the database.
• A custom-built site or web app. The live files may be enough to keep it running, but editing it properly needs the original source code and an understanding of how it is put together. Ask whether the code sits in a repository (GitHub, GitLab, Bitbucket) and whose account that repository is in.
• A hosted website builder. The site exists inside the builder's platform, under one account. If that account is the developer's, the builder's support is your route in, and you may be told the site cannot be transferred out at all, only rebuilt elsewhere.

What if you inherited a website you can't edit?

Start with the same inventory, then find out why editing is blocked. Usually it is one of three things: no admin login, a site built in code with no editing interface, or a theme or page-builder licence that lapsed with the previous owner. Each has a different fix, and only the last one is a quick purchase.

The inherited version tends to come with less hostility and more confusion. Nobody is refusing you anything. The knowledge simply left with whoever built it. Ask the previous owner or the departing colleague for three specific things rather than "all the logins": the registrar account, the hosting account, and any account the site was built in. With those three, everything else can be recovered.

Be realistic about sites that were built entirely in code. If every text change has always gone through a developer, that is how the site was designed, and the honest options are either to keep a developer on call or to move the site onto a setup you can edit yourself. Neither is wrong. It depends on how often your content changes.

Should you repair the old site, migrate it, or rebuild it?

Repair it if the site is sound and you now hold every account. Migrate it if the site is fine but the hosting or the accounts behind it are not. Rebuild it if the code is unmaintainable, the design is years out of date, or nothing beyond the content can be recovered.

Our view, for what it is worth: do not rebuild in a panic. Regaining control and redesigning the site are two separate decisions, and making them at the same time is how a rescue turns into a six-month project. Get the site stable, backed up and under accounts you own. Then decide about the design with a clear head.

Whichever you choose, protect what the site has already earned in search. If URLs change during a migration or a rebuild, each old address needs a 301 redirect to its new equivalent, or the rankings attached to those pages are lost. Our guide on how to switch web hosts without losing data or SEO walks through that sequence in detail. And if the real complaint is the hosting itself rather than the missing developer, signs it's time to leave your current web host will help you separate the two.

How do you make sure this never happens again?

Put every account in your business's name, on an email address at your own domain, with you as the primary owner and any developer added as a second user. Keep the credentials in a password manager the business controls. Ask for a short written handover whenever anyone finishes work on the site.

None of this is distrust of developers. Most are entirely reasonable, and plenty disappear for ordinary reasons, like closing a small agency or moving into a different career. The problem is a setup where one person was the single point of access. Fix the setup and a developer leaving becomes a routine handover.

The code itself is a separate question. Who legally owns the code and design of a commissioned website depends on your contract and your country. If the site matters to your business, get ownership written into the agreement before work starts. If it is already too late for that and a dispute looks likely, speak to a lawyer rather than relying on a blog post, including this one.

A short checklist worth keeping:

• Domain: registered to your business, auto-renew on, contact email on your own domain.
• Hosting: billed to the business and owned by it, developer added as a user if needed.
• Website admin: at least one administrator account in your own name.
• Code: if the site is custom, a repository the business owns, plus written ownership of the code in your contract.
• Backups: a recent copy of files and database stored somewhere outside the hosting account.
• Google accounts: you as owner in Search Console and Analytics, not only the developer.