Locked Out of Your Own Website: The Ownership Trap

The worst version of this call is not the angry one. It is the confused one.

Someone wants to move their website to a new developer. Reasonable request, ordinary Tuesday. Then it turns out the domain is registered to their old developer's personal account. The hosting is on a reseller plan in that developer's name, with eleven other clients on it. The Google Analytics was set up on an email address nobody has the password to. The site itself was built on a platform where "export" gives you a folder of nothing much.

Nobody committed fraud here. In almost every case I have seen, the developer set it all up years ago because it was faster, meant to move it across later, and never did. It only became a trap when the relationship ended.

That is what makes this worth writing about. The damage does not come from bad intent. It comes from convenience that quietly hardened into leverage.

What does it actually mean to own your website?

Ownership is not one thing. It is four, and you can hold some without the others.

Your domain name. The address itself. This is the one that matters most, because whoever controls it controls your email and your web address. Losing a website is expensive. Losing a domain that your customers, your invoices and your Google listing all point at is a different order of problem.

Your hosting. The server the site runs on. Being on someone else's account is not automatically bad, but it means your site's continued existence depends on their billing relationship, not yours.

Your code and content. The actual site. On a custom build this should be handed over or sitting in a repository you can access. On some platforms there is genuinely not much to hand over, which is a fair trade you should make knowingly rather than discover later.

Your data. Analytics, Search Console, ad accounts, the enquiry history. Years of evidence about what works. This is the one people forget until they need it, and the one that cannot be reconstructed.

You want all four in accounts with your name on them and your credit card behind them. Anything else is a favour that works until it does not.

How do people end up locked out?

Rarely through malice. Almost always through one of these.

It was faster on day one. The developer already had a registrar account and a hosting plan, so putting your site there took two minutes instead of the half hour of setting you up properly and walking you through it. Multiply by every client and you get an agency accidentally holding the keys to forty businesses.

It was framed as a service. "We handle all the technical stuff, you don't need to worry about it" is a genuinely appealing offer, and often meant kindly. The line between handling something for you and holding it away from you is invisible right up until you want to leave.

The handover never happened. Someone said the accounts would be transferred after launch. Launch happened, everyone moved on, and the transfer stayed on a list. This is the most common one by far.

Nobody wrote down who owns what. Same root cause as most project failures: the thing everyone assumed was obvious was never put in writing. We covered that pattern in why web projects blow up.

The tell is not how someone answers "do I own my website". Everyone says yes. The tell is whether they can send you the login without checking with anyone.

The ten-minute ownership audit

Do this today, whether or not anything is wrong. It is cheap when the relationship is good and expensive when it is not.

1. Look up your own domain. Search for a WHOIS lookup and enter your domain. Check the registrant. If it lists your developer, their agency, or a name you do not recognise, that is your first job. Many domains are privacy-protected, which hides the name legitimately, so if you cannot tell, go to step 2.

2. Log in to the registrar yourself. Not through anyone. Go to the registrar's site and do a password reset to your own email address. If no account exists at your email, the domain is not in your name. Registrars to check: GoDaddy, Crazy Domains, VentraIP, Namecheap, Cloudflare.

3. Confirm the domain renewal is on your card. A domain nobody is paying for expires, and expired domains get bought within minutes. Whoever's card is on it is the person the renewal notice goes to.

4. Find out where the site is hosted and whose account it sits in. Ask directly: "Is the hosting account in my business name, and can I get the login?" A good answer arrives quickly and specifically. A vague answer is an answer.

5. Ask where the code lives. For a custom build: "Which repository is my site in, and can I be added to it?" If the answer is that it only exists on one person's laptop, that is a genuine risk regardless of anyone's intentions.

6. Check you are an owner, not a user, on your data. In Google Analytics and Search Console, look at the admin or users screen. You want your email listed with owner or full permissions. Being merely a viewer means someone else can remove you.

7. Verify your business email is not tangled in it. If your email runs through the same hosting account as the website, changing one can break the other. Knowing this in advance turns a crisis into a scheduling problem.

Write the answers down in one place. That document is worth more than most of the paperwork in a web project.

What if the audit turns up something bad?

Do not lead with an accusation. Most of the time this is untidiness, not a hostage situation, and treating it as the latter turns a ten-minute admin task into a fight.

Ask for a transfer plainly and in writing: you would like the domain moved to a registrar account in your business name, the hosting either transferred or migrated, and owner access on the analytics. Give a reasonable date. Most developers will just do it, sometimes a bit sheepishly.

If you get resistance, or a fee that feels like a toll rather than an hour of work, take it seriously. Domains can be transferred with an auth code from the registrar. Hosting can be migrated to a new account without the old provider's cooperation, as long as you can get the files and database. Analytics history, unfortunately, is the one thing that genuinely cannot be recovered if you lose access, which is why step 6 is worth doing today rather than the week you decide to leave.

And if a site was built on a platform you cannot get out of, it is worth knowing that early. That is often the moment people start weighing up maintaining, renovating, or rebuilding, and it is a much better conversation to have deliberately than under pressure.

How we do it, for the sake of a comparison

Domain in your name, on your card, at a registrar you can log in to on day one. Hosting in your account. Code in a repository you own. Analytics with you as owner and us added as a user, not the reverse.

The practical effect is that you can fire us on a Tuesday and be running with someone else by Friday, and nothing about that requires our permission or our goodwill. That is not generosity. It is just what ownership means, and a studio that is confident about the work has no reason to hold anything hostage.

If you are not sure what you actually control, we will walk your setup with you and tell you what to fix, in your own words, whether or not you ever hire us.