Who owns your website? The domain, code and accounts checklist

You paid the invoice, so the website is yours. That is usually true, and it is not the same as being able to prove it, move it, or get into it on a Sunday when something has gone wrong. The gap between those two things is where a genuinely alarming number of small businesses discover, at the worst possible moment, that the answer to who owns my website is more complicated than they assumed.

Seven things should be in your business's name. Every one of them can be checked in the next twenty minutes, most of them without asking anybody. Print this, work down it, and where the answer is no, fix it while the relationship with whoever built the site is still perfectly friendly. That is the entire point of doing this today rather than during an emergency.

Who owns your website: the seven things, and how to check each one today

1. The domain. Look yourself up in a WHOIS search (lookup.icann.org, or any registrar's free tool). It shows which company holds the registration, when it expires, and whose details are attached. You want your business named, an email address you control, and a renewal date comfortably in the future. Check: five minutes, no permission needed. This is the one that matters most, because whoever controls the domain controls where your name points.
2. The hosting. Find where the site actually lives, which is usually easiest by looking through the last year of card and bank statements for a recurring charge from a hosting company. Then confirm the account is in your business's name with a login you hold. Check: ten minutes. If the only person who can reach the server is your developer, you cannot move, back up or restore without them.
3. The code. Ask for the repository, and make sure it sits in an organisation account owned by your business with the supplier invited into it, rather than in their personal account with you invited into theirs. If there is no repository, ask for a complete export. Check: one email. Paying for work does not by itself transfer copyright in most countries, which is why the written assignment in the last section matters.
4. The content system. Whether that is WordPress, a hosted platform or something custom, you want an administrator account of your own that can create and remove other administrators, including the supplier's. Check: log in and look at the list of users. An admin list you cannot change is not really an admin account.
5. The content itself. Your words, your images, your product data, your customer records, exportable in a form you could hand to somebody else. Check: try to export something. If there is no export, that is the finding. Photography is worth a separate question, because the licence may sit with the photographer rather than with you.
6. Analytics and Search Console. Your history of traffic and search performance is genuinely valuable and cannot be recreated. You want to be an owner rather than a viewer, so that access outlives the relationship. Check: open the account and look at your own permission level.
7. The connected services. Email, the payment provider, the booking tool, the CDN, the certificate, transactional email, SMS, ad accounts, app store listings, social profiles. Check: write the list. Most businesses have never written it down, and the writing is the exercise: an account nobody has listed is an account nobody will remember to recover.

When the answer is no

Finding something in somebody else's name is common and usually innocent. Developers register domains for clients because it is quicker, agencies open hosting accounts on their own billing because it is tidier, and nobody intends it as a hold over you. Ask, plainly and in writing, and most people transfer it within the week.

• For the domain, ask them to remove the transfer lock and send you the authorisation code (also called an EPP or auth code) so it can move to an account in your name. If they will not, or cannot be found, go to the registrar named in your WHOIS result rather than the reseller who sold it: registrars have a dispute process for exactly this, and evidence that the business is yours is normally what they need.
• For hosting and platform accounts, ask for the account to be transferred or for an owner-level login. Where the account is genuinely theirs and shared with other clients, the honest fix is moving your site onto an account of your own, which is a small job and worth doing.
• For the code, ask for a repository transfer or an export. A supplier who will not hand over code you have paid for is telling you something important about how the relationship ends.
• If the response is a demand for money to release your own domain or accounts, stop negotiating alone and take advice. That behaviour escalates, and a clear letter from someone who does this professionally usually ends it quickly.

Where a system has been inherited and nobody can say what is where, that assessment is exactly what adopting software we did not build begins with. If the person who built your site has stopped answering entirely, this becomes a different and more urgent job with its own order of operations. Our guide to recovering a website when a developer disappears covers it step by step, and taking over a codebase covers the planned version where you are simply changing suppliers.

Putting it in the contract, in plain words

For the next project, this is a short paragraph rather than a legal battle, and any reasonable supplier will agree to it without blinking. The substance you want, in whatever wording your lawyer prefers:

• Intellectual property in the work transfers to your company on payment, explicitly assigned rather than merely licensed to you. Paying an invoice is not on its own an assignment in most countries.
• All accounts are opened in your company's name, with the supplier added as a user you can remove: domain, hosting, DNS, content system, analytics, and any third-party service bought for the project.
• The code lives in a repository your company owns, throughout the project rather than at the end of it.
• Handover is defined and tied to the final payment: credentials, documentation, a walkthrough, and a demonstration that your team can make a change. Tie it to the deliverable, not to a date.
• Nothing is held back as a bargaining chip. State plainly what happens on termination, including that you keep the domain, the content and the code regardless of how the relationship ends.

This is general information rather than legal advice, and it is worth an hour of a solicitor's time on a project of any size. What it is not is an insult to your supplier. It is the paperwork that lets two parties stay on good terms when something goes wrong, which is the only time any of it is ever read.

Not for you if

The reason to do this on an ordinary Tuesday is simple. Every one of these checks is easy while everyone is friendly, and every one of them is hard once somebody has stopped replying to emails. Twenty minutes now buys you the ability to walk away from any supplier, at any time, with everything that is yours. That is worth having even if you never use it, and especially if you never have to.