Who Owns Your Website, Your Domain and Your Code

When somebody says they own their website they usually mean one thing. There are four: the domain name, the hosting, the code, and the accounts arranged around them. Those four live in different places, are held by different parties, under different rules. Paying for a website transfers none of them automatically.

The usual arrangement is not malicious. A small agency sets everything up on its own accounts because that is faster than waiting for you to create six logins, and because nobody asked. Years pass. It works fine, right up until the day it matters.

The day it matters is always one of three. You want to change supplier. The relationship sours. Or the agency simply stops trading, which happens quietly and without notice. Then you discover that the name your customers type, the machine your site lives on, and the entire record of where your traffic comes from all belong to somebody who is no longer answering email.

None of this is hard to fix while everybody is friendly. All of it is hard to fix afterwards. That is the whole reason to read the rest of this on a normal Tuesday rather than during an argument.

Everything else on this list is replaceable. Hosting can be rebuilt in a day from a backup. Code can be rewritten, painfully but genuinely. There is exactly one of your domain name, and it is the address on your invoices, your vans, your email signatures, your printed material and every link anyone has ever made to you. Lose it and you have lost the business's address.

Every domain record has a registrant, which is the legal owner, plus an administrative contact. Whoever controls the email address on that record can move the domain elsewhere. If that email address ends in your agency's domain rather than yours, they can move it and you cannot, whatever your invoice says.

Here is how it actually goes wrong. An agency registers the domain on its own account, with its own contact details, as a convenience during the build. Five years later they close, or the relationship ends badly. The renewal notice goes to a mailbox nobody reads any more. The domain lapses, and one morning your website and your company email stop at the same moment. Recovering a lapsed domain is possible and it is a race, and sometimes you lose it to somebody who was watching.

There is a second, subtler version. The domain is registered in your company's name, correctly, but it sits inside a reseller account you have never had a login for. You are the owner on the record with no practical way to act on it. Ownership on the record and control of the account are two different things and you want both, in your name, with your card paying for it.

Hosting is where the files and the database actually live. The question worth asking is whose account it sits in and whose card pays for it. Where the machine physically lives matters far less.

The common arrangement is a reseller plan. The agency buys one large hosting account and puts a stack of client sites on it. You do not have an account, you have a folder inside somebody else's. You cannot move without their cooperation, you cannot see who else is on that machine, and if their bill goes unpaid your site goes down for a reason that has nothing to do with you.

What you want instead is straightforward and no more expensive. An account in your company's name, paid on your company's card, where you hold the master login, and your agency is added as a user with the access they need to work. That single arrangement removes most of the risk described in this article, and any competent supplier will set it up without complaint if you ask at the start.

While you are in there, find out where the backups are kept and whether you can download one yourself without asking anybody. A backup you can only request is not a backup you own. Pull a copy down now and put it somewhere of your own, which takes a few minutes and is the cheapest insurance on this page.

In most countries the person who writes code owns the copyright in it by default, unless a contract says otherwise. Paying the invoice does not transfer that. What you usually get by default is a licence to use what was made, which is a narrower thing than ownership and behaves very differently when you want somebody else to work on it.

For a site built on a bought theme this rarely matters, because there is very little bespoke code to own. For anything custom it matters a great deal. It is the difference between handing the next developer a repository and asking them to reverse engineer a live site.

Ask for two things and understand that they are separate. A written assignment of the work produced for you, signed. And the actual source code, in a repository your company owns, that you can log into today. A contract granting you rights to code you have never seen is a promise about a filing cabinet you cannot open. Ask for the code to be pushed to your repository continuously during the project rather than handed over at the end, because handovers at the end are what get forgotten.

Here is the honest caveat that a sales conversation would skip. A supplier who builds on their own framework, or their own plugin used across every client they have, may reasonably refuse to hand that part over, and refusing does not make them dishonest. That can be a perfectly good deal. It is only a good deal if you know it is the deal, and you know precisely which pieces you would have to replace if you left. Ask them to name those pieces in writing.

This is the part that quietly does the most damage. Analytics, search console, the ad accounts, the DNS, the certificate, the service that sends your transactional email, the payment gateway, the content delivery network, the admin of the content system, the code repository, the error monitoring, and the map or booking service embedded in a page.

Analytics is the sore one, because history cannot be recreated. If the property lives inside the agency's account and access is withdrawn, the entire record of what worked, which campaigns paid off and how last year compared to this one goes with it. Starting again means being blind for a year.

Search console verification is the one that bites during a site move, because it is what lets you tell Google what has happened. It is very often verified through a record in DNS that the agency controls, which means the tool you most need during a handover is the tool you lose first.

The same problem, with the same fix, applies outside the website: the Google Business Profile, social accounts, review platforms, directory listings. Every one of them should be created in your company's name, with your agency added as a user. It costs nothing to do it this way at the start and it is a negotiation to undo later.

Start with a public lookup of your own domain. A WHOIS query on any registrar's site tells you which registrar holds it and, depending on privacy settings, who is recorded as the registrant. If the registrar is a company you have never logged into, you have your first answer already.

Then try to log in. Asking a colleague whether somebody has the login is not the same thing. Actually sign in, today, to the registrar, the hosting control panel, the content system admin, analytics and search console. A password sitting in a document is not access until somebody has used it, and plenty of the passwords in those documents stopped working years ago.

Check the level of access rather than the fact of it. Being a user is not the same as being the owner. In nearly every one of these systems there is exactly one role that can add and remove everybody else, including the person who set it up, and that role is the only one that actually protects you. Look at the user list too, and see who else is on it. Former staff and former agencies turn up on that list surprisingly often.

Then follow the money. Whose card renews the domain, the hosting, the certificate and every subscription attached to the site. And check the email address on each account, because a renewal notice going to an agency mailbox is a failure waiting for a quiet moment. Write all of this into one sheet: the service, the account holder, the login, who pays, and the renewal date. That sheet is the deliverable, and almost no business has one.

Ask in writing, plainly, and frame it as routine housekeeping rather than as an accusation, because for most suppliers that is exactly what it is. Something like a request to tidy up account ownership for your records. Most agencies will do it within the week. The ones who go quiet or start explaining why it is complicated have told you something useful, and you have learned it before you needed to know it.

Be specific about what you are asking for. The domain moved into a registrar account in your company's name. The hosting either transferred to an account you own or the site migrated to one. Owner level rights on analytics, search console and the ad accounts. The source code pushed to a repository your company controls. A signed assignment of the work. And a written handover covering credentials, how the thing is deployed, and where everything lives.

Order matters. If the site is still hosted with them, do not move the domain first, or you can end up with a name pointing at nothing. Take the code and the accounts first, get hosting sorted, move the domain last. And do all of it before the final payment on any project, because a conversation about handover is much easier when an invoice is still open.

If they refuse or simply stall, you have more standing than it feels like. Domain transfers run through a formal process at the registrar and the registry, and it turns on who is recorded as the registrant, which is why that record matters more than any email you have. Hosting can be walked away from: rebuild elsewhere from a backup and repoint the name when you are ready. Where you have genuinely little recourse is a domain registered in their name that they will not release, and that is a negotiation rather than a claim. Which is exactly why the checking comes first, on a day when nothing is wrong.

A short set of clauses costs nothing to include at the start and is very difficult to add afterwards. Put them in the next agreement you sign, with any supplier, for any digital work.

The domain is registered in the client's name, in an account held by the client. All third party accounts are created in the client's name, with the supplier added as a user. Source code lives in a repository owned by the client and is pushed to it as work happens rather than at the end. Copyright in the work is assigned to the client on final payment. And a documented handover is part of the deliverable: credentials, how it is built, how it is deployed, and what each moving part does.

Add an exit clause while you are there. What gets handed over on termination, within how many working days, and whether help with the migration is included or charged. Every one of those is uncontroversial when written at the start and impossible to agree at the end.

One last thing, about the human side of the conversation. None of this implies distrust, and it is worth saying so out loud when you raise it. A supplier who has done good work wants a clean handover, because the next client will ask them the same questions and they would rather have a good answer. Say that, and the whole discussion stops feeling like an accusation and starts sounding like what it is, which is basic company housekeeping.