Who owns your website?

Most company owners answer this question confidently: they do. Then it turns out the domain runs in the name of the previous developer, the hosting is paid for by his nephew on his own card, and the Analytics account was set up by a former marketer who left two years ago.

This isn't a theoretical problem. It comes to light at the worst possible moment: when switching providers, in a dispute, or when something urgently needs changing and nobody can log in.

The short version

• Four things belong here: the domain, the hosting, the accounts and the source code. Each can end up in the wrong hands separately.
• With the domain what matters isn't who paid for it, but who is listed as the registered owner.
• Copyright stays with the creator by default. The client gets a licence to use the work if the contract sets that out.
• A "turnkey" solution often also means the key stays with the developer.
• Where you stand can be checked in ten minutes. Worth doing before you need it.

Four things that can be lost

1. The domain

The domain is the most important, because it is the address. Lose it and everything else becomes unusable too: the website, the company email, the contact details on your business cards and vehicles.

There are three roles with a domain, and they aren't the same thing:

• The owner (registrant). The registered holder of the domain. This has to name your company, with the company's details.
• The administrative contact. The person who handles the paperwork. This can be the developer or the provider; there's nothing wrong with that.
• The registrar. The provider the domain is managed with.

The common mistake is that the developer or the agency ends up in the owner field too. In that case the domain isn't legally yours, regardless of who pays the annual fee.

2. The hosting

With hosting the question is whose name the contract is in and whose card the fee comes off. If your site runs in the developer's own account, in a subdirectory of a larger package, then you have no independent access and moving out isn't a simple operation.

This isn't necessarily ill will, it's often just convenience. The consequence is the same either way.

3. The accounts

This is the most frequently forgotten category:

• Google Analytics and Search Console
• Google Business Profile (the listing on maps)
• company profiles on social platforms
• the newsletter system
• the payment provider
• the domain registrar account
• the admin interface for the company email

For each one the question is the same: is there an access tied to the company's own email address, with owner-level permission? Not editor, not invited: owner.

The Google Business Profile deserves separate attention. If you can't get into it, you can't change the opening hours and you can't reply to reviews.

4. The source code and the licence

This is where most of the misunderstanding lives, because the legal default isn't what many people assume.

Copyright arises with and stays with the creator by default. The client acquires the right to use the work by the parties agreeing on it. If the contract says nothing about the licence, that can become a dispute later.

So it's worth setting out in the contract:

• What you may use the finished work for. Typically for an unlimited period, within the scope of your own business activity.
• Whether you may modify it. This becomes important if you move to another developer.
• Whether it's transferable. It matters when selling or restructuring a company.

This isn't a question of mistrust. A clean contract protects both parties and prevents the situation where, years later, somebody has to recall a verbal agreement.

The "turnkey" trap

There's a business model that is entirely legal and still causes an unpleasant surprise: the provider bundles the development, the hosting, the domain and the maintenance together at an attractive monthly fee, but keeps everything in their own name.

While the relationship is good, that's convenient. When it ends, it turns out you didn't take the site with you, you only cancelled the rental.

We're not saying avoid packages like that, because for many companies they're a good solution. We're saying know what you're buying. The single question that settles it:

If I gave notice tomorrow, what could I take with me?

A ten-minute check

You can do this now, while reading.

1. Look up the domain details. Enter your domain on a public domain lookup service and check the owner's name. Your company should be the one listed.
2. Find the hosting invoice. Whose name is it in? Which email address does it go to?
3. Log into Search Console. If you can't, that in itself is an answer.
4. Check the Google Business Profile. Do you have owner access?
5. Review the social platforms. Is there an owner on the company profile besides you, and can anyone who no longer works with you be removed?
6. Dig out the contract. Does it cover the licence to use the work?

If you can't answer one of them, that's not a problem. The problem is finding out when it's urgent.

A handover list

If your site is being built now, or you're switching providers now, make this list part of the agreement. These are worth receiving at the end of the work:

• Access to the domain registrar account, or confirmation that the owner is your company
• Access to the hosting and its admin interface
• An export of the database and files, or a description of how to request it
• Owner-level permission on every connected account
• The contract or clause setting out the licence
• Short documentation of what sits where and how it works
• A list of the external services used, with their fees

The second-to-last point is the rarest and one of the most valuable. A one-page description of which system runs where, in whose name, and what does what, will repay itself years later.

What to do if it turns out it isn't yours

Don't panic, and don't open with tension. In most cases it isn't deliberate, it simply worked out that way.

Ask politely. "I'd like to tidy up our records; could we transfer the domain into the company's name?" Most professionals will help with this.

Deal with them one at a time. The domain first, then the hosting, then the accounts. The domain is the most important.

Write down what's been sorted. A simple table: which item, in whose name, tied to which email address, when it expires.

If the relationship has already broken down and you get no reply, then with the domain the registrar can tell you what procedure exists. It's worth getting legal help at that point, because the procedure depends on documentation.

Frequently asked questions

Whose is the domain if I pay the fee?

• It isn't the payment that decides, it's who is listed as the registered owner in the domain details. It happens that the company pays the invoice while the developer's name sits in the owner field.

Who owns the website's source code?

• Copyright arises with the creator by default. The client acquires a licence if the parties agree on it, which is why it's worth setting out in the contract the scope of use and whether the work may be modified.

How do I check whose name my domain is in?

• Enter your domain on a public domain lookup service and check the registered owner's details. Your company should be the one listed there.

What should I do if the previous developer can't be reached?

• With the domain, the registrar can advise on the possible procedure. With hosting and accounts, the provider's support is the first step. In a dispute it's worth getting legal help.

Why is it better for the subscriptions to be in my own name?

• Because that way every access and all the data stays with you, and you can move on at any time. It isn't a defence against the provider, it's a condition of normal operation.

What does owner-level permission on an account mean?

• The level from which others can be added and removed, and which can't be revoked from outside. Editor permission isn't enough, because the owner can withdraw it at any time.

In summary

Ownership of a website isn't one question but four: the domain, the hosting, the accounts and the licence. All four have to be sorted separately, and all four can be sorted in a few hours while nothing is wrong.

That's why with us the subscriptions and tools a project needs are set up in the client's own name. It isn't a small-print clause, it's the basis of how we work: that way all the data and every access stays with the client.

Note

This piece is for information only and does not constitute legal advice. On contractual or disputed questions a lawyer can give a formal opinion.