Most working relationships with a web developer end quietly. Someone moves on, replies get slower, and one day you notice you haven't spoken in a year. Nothing goes wrong, because nothing needs to.
The trouble starts the day something does. A renewal notice arrives, or a staff member needs an email address, or the site goes down on a Saturday. You go looking for the person who set it all up, and they aren't there.
You can find out where you stand before that day comes. And if it already has, more of this is recoverable than most people expect. Not all of it. Most of it.
What actually breaks when a developer stops answering?
Less than most people fear, and what survives is decided almost entirely by one thing: which email address owns each account. Not the contract, and not whoever paid. The address on the account is where every provider on earth sends a password reset, and that's what recovery comes down to.
Your website isn't one thing. It's six, and they usually have different owners:
- The domain: your address on the internet, rented yearly from a registrar.
- DNS: the switchboard that points your domain at your site and your email.
- Hosting: the machine your site runs on.
- The site itself: the files, the design, the content.
- Email: usually Google Workspace or Microsoft 365, sometimes bundled with hosting.
- Everything attached: analytics, Search Console, the payment processor, a booking tool.
Losing access to one of these is inconvenient. Losing the domain is a different category of problem (the kind with a deadline attached), which is why I'd chase it first and worry about the rest afterwards.
Why does the domain matter more than everything else?
Because it's the only one that can't be rebuilt. A new host can be set up in an afternoon and a site can be reconstructed from a copy of the live one, but your domain is the address printed on your van and the address every one of your email accounts depends on. There's exactly one of it in the world.
It's also the piece most likely to be sitting in somebody else's account, for a reason that isn't sinister at all. On the day the project started you didn't have a registrar account, so the person building the site registered the domain on theirs to get moving. That was the sensible choice that afternoon. Nobody revisited it, and now the renewal notice goes to an inbox you can't open.
How do I find out what I actually own?
Start with your own inbox rather than a lookup tool. Search it for the words "renewal", "invoice", "receipt" and "verify your email" going back three or four years. Whoever is being billed for something is the account holder, and the receipts will name the providers you're looking for.
Then check each of the six in turn.
Start with the domain. A public WHOIS lookup will tell you the registrar and the expiry date, but on most domains the owner's details are hidden behind privacy protection, so it won't tell you who controls it. The test that works is simpler: try a password reset at that registrar using your own email address. If the reset arrives, the account is reachable by you. If it doesn't, someone else holds it.
DNS is often at the registrar, sometimes at Cloudflare, sometimes at the host. If your developer mentioned Cloudflare, that's a separate account with a separate login.
For hosting, look for the monthly or yearly invoice. If you have never received one, you're not the account holder.
Email is the one worth slowing down on. If your address ends in your own domain, you're almost certainly on Google Workspace or Microsoft 365, and there will be an administrator account that's not the same as your day-to-day login. Find out whose it's. The administrator can read, reset, or delete every mailbox in the business.
Analytics and Search Console are the lowest stakes and still worth knowing. Access is usually granted to a personal Google account, which means it leaves when the person does.
Write down what you find, even roughly. A text file is fine, and nobody is grading it. A page of notes saying who owns what and where each account is held is worth far more than it sounds, and almost nobody has one.
What if things are registered under my developer's account?
Ask them to move it, and ask plainly rather than carefully. This is an ordinary request and any competent freelancer has handled it before. Treating it as an accusation is what makes the conversation difficult, and there's usually nothing to accuse anyone of.
What actually helps:
- Open your own accounts first. You can't receive a domain without somewhere to receive it. Create your own registrar account before you ask for anything to be moved.
- Use an email address on your own domain, and one that outlives any single employee. An address
like
admin@yourbusiness.comsurvives staff changes in a way that a personal Gmail doesn't. - Expect it to take a few weeks. Domain transfers involve a code from the current registrar and a lock period that commonly runs sixty days after any change to the registered owner. This is normal and isn't your developer stalling.
- Agree who pays for renewals from now on. Moving the domain doesn't by itself move the card it renews on, and this is the detail that gets forgotten and causes the next problem.
What if they've already stopped answering?
Work in the order of what is recoverable. Start with the domain. It's the only piece with a clock on it, and the clock doesn't care whose fault any of this was.
If the domain has expired, there's a clock running and it has stages. For a short grace period after expiry you can usually renew at the ordinary price. After that it enters a redemption period where recovery still works but carries a fee, often somewhere between eighty and two hundred dollars. After that it's deleted and released, and expired domains with real traffic are bought within seconds by services that exist to do exactly that. Call the registrar. Do not wait for it to drop with a plan to buy it back.
If the domain has not expired, contact the registrar directly and ask what proof of ownership they accept. Registrars deal with this constantly. Invoices, the business registration, and control of the website itself all help.
Email comes next, because it's what everything else resets through. If your domain is the tenant on Google Workspace or Microsoft 365, both providers have a documented process for proving domain ownership and recovering administrator access. It usually involves adding a record to your DNS, which is why control of DNS is worth chasing early.
Hosting and the site are often the easiest. If nobody can get into the hosting account, rebuilding on a new host from a copy of the live site is frequently faster than proving ownership to a support desk. The site is public; it can be copied.
Analytics history is usually lost. Accept that one quickly. You can verify a new property today and start collecting again, but the old data stays in an account you can't open, and I have never seen an hour spent chasing it pay for itself.
What should a proper handover include?
A document that lets someone who has never met your developer get back into everything without asking them. That's the entire test, and most handover documents fail it because they list what exists instead of how to recover it.
A good one records, for each account:
- What it's and which provider it's with.
- Which email address owns it. This is the field that decides everything.
- Whether ownership has actually been transferred to you, or is still just intended.
- When it renews, and whose card it renews on.
- Where the password is kept, in a note like "in the shared 1Password vault" or "reset via admin@yourbusiness.com".
It should not contain passwords. A document with live credentials in it's a liability that gets forwarded and left in inboxes, and it goes stale the first time anyone changes anything. Where the credential lives stays true for years. The credential itself doesn't.
How do I set this up so it never becomes a problem?
Decide ownership at the start of the next project, when it costs nothing, rather than at the end, when it costs a negotiation. Three things settle most of it.
Everything is registered in your business's name, from day one. Even when your developer is the one typing, the account is yours and the email on it's yours. Good freelancers prefer this; it means they are never holding something they would rather not hold.
They get access, not ownership. Every serious provider supports adding someone to an account without handing over the account. Delegated access can be removed cleanly the day the relationship ends, and removing it is a two-minute job rather than a conversation.
Renewals go on your card and to an address you monitor. The most common way a business loses its domain isn't a dispute. It's a renewal notice sitting unread in the inbox of someone who stopped working on the account two years ago.
What should I do this week?
Spend twenty minutes finding out who holds your domain, and if it isn't you, ask for it. Everything else on this page can wait; that one can't, because it's the only piece with an expiry date attached and the only one that can't be rebuilt.
If your developer is still answering their emails, this is a short and completely ordinary conversation. That's the best time to have it, and it's the reason to have it now rather than on the Saturday when something breaks.
Everkey keeps this record for freelancers who look after other people's domains and accounts. It stores no passwords, only who owns what and how to get back in.