Who is your website tied to?
The question isn't who built it, nor who paid for it. It's who can get to it tomorrow morning — and to which part.
A website rarely becomes someone else's by anyone deciding so. Far more often it drifts there quietly over the years. At the start the developer registers the domain, because that's quicker. The hosting sits in their account, because the rate is better there. There's no separate admin login, because nobody needed one.
Each step was a convenience decision, and mostly with no bad intent behind it. The result is still that a business's most important online asset lives inside another person's credentials.
You can run the six questions below on your own site. None of them requires expertise.
- domain — your name on the internet
- hosting — where the files live
- admin — where it can be edited
- content — the text and the images
four separate keys
One — whose name is the domain in?
This matters most, because it is the hardest to get back. A domain isn't a technical detail but your company's name on the internet. If it is registered to someone else, the business cannot take its own name with it.
Checking is simple: the registrar's records show who the owner is. The administrative contact may well be the developer — the owner may not.
Two — where does the renewal notice arrive?
Domains and hosting renew annually, and a notice goes out beforehand. If that notice doesn't reach your mailbox, then the renewal isn't your decision — at best somebody handles it on your behalf, at worst nobody does.
Three — can you log in to your own site's admin?
Not that you need to use it daily. The point is whether a login in your own name exists, and works. Try it. If the only way to get a change made is to write to somebody, that isn't access but a service — which is fine, as long as that person is reachable.
Four — can you export the content?
The text, the images, the product data, the subscribers. These are your assets, not the system's that happens to store them. Most systems have an export; if yours doesn't, that's worth knowing before you need it.
Five — what happens if the developer is away for a month?
It doesn't take an accident: a holiday or another project is enough. The question is whether life on the site can stop for that long. If a price change or an opening-hours update waits a month, that is a business risk, not a technical one.
Six — can anyone else look inside?
The least obvious one, and yet it decides the rest. If you asked another professional tomorrow, could they look without having to request permission from the original developer? If not, you can't even get a second opinion on your own system.
Together these six questions measure one thing: whether the arrangement can be handed over. If it can, the relationship continues because it suits both sides. If it can't, it continues because there is no alternative — and those are very different things.
What to do if something isn't with you
First: not in anger. In most cases this is the residue of a convenience decision from years ago that nobody has thought about since.
Ask in writing, itemised: transfer of the domain into your own name, the hosting login, administrative access, and an export of the content. Handing these over is a normal part of the work, not a favour.
If the request stalls or drags, that is an answer in itself. It is then worth reconsidering how much further to invest in the same arrangement — and on how an inherited system can be taken over, there's a separate account.
Why this is a rule for me too
I don't take on work I couldn't maintain afterwards — but the same holds in reverse. What I build has to be handed over: the domain in the client's name, the credentials with them, the content exportable. If a solution needs me called in for every small change, then I designed it badly.
Questions on this topic
Whose name should the domain be in?
The business's, or the owner's. A domain isn't a technical detail but the company's name on the internet: if it is registered to someone else, the company cannot take its own name with it. The administrative contact may be the developer; the owner may not.
What should I ask a developer for at the end of a job?
Administrative access to the website, the hosting login, the domain control panel, and a copy of the source files. If the system runs on a template or a page builder, the licence details too. Handing these over is a normal part of the work, not a favour.
Is it a problem if the developer runs the hosting?
Not in itself, and it is often more convenient. The difference is whether you can end it. If you have your own login and the content can be exported at any time, the arrangement is convenience. If you don't, it is dependency.
What should I do if it turns out I don't hold the access?
Ask for it, in writing, without heat. In most cases there is no bad intent behind it, only convenience from years ago. If the request stalls, that is an answer in itself — and from then on it is worth reconsidering how much further to invest in that arrangement.