Who Owns My Website? The Domain, Code and Accounts Checklist Before You Hire a Studio

It's a common story. The previous agency has stopped replying, or the relationship ended badly, and the company wants a new website. Then work starts, and it turns out nobody there can log in to their own domain. The hosting account is in the agency's name. The code isn't available. The analytics history belongs to someone else's account.

They thought they owned their website. Legally and practically, they didn't.

This is avoidable, and it's cheap to avoid before you sign. Here's what owning a website actually means, and the checklist I'd give anyone hiring a studio, including mine.

Owning a website means owning six things

1. The domain

The single most important asset. Whoever is listed as the registrant controls it, and with it your email and your search history. It should be registered in your company's name, at a registrar where you hold the login.

2. The code

For a custom website or software, the source code should sit in a repository your company owns, such as a GitHub organisation in your name, with the studio added as a collaborator. Not a zip file on request; a live repository you can open today.

3. The hosting account

The account that serves the site to visitors. If it's in the agency's name, they can switch it off. It should be your account, with your payment method, and the studio given access.

4. The CMS

Where your team edits content. Your company should own the account and pay for any plan directly, so content doesn't disappear when a supplier relationship ends.

5. Analytics and Search Console

Years of data about what your buyers search for and which pages bring enquiries. Your company should own the Google Analytics property and the Search Console property, with the studio added as a user. Recreating them later means starting your history from zero.

6. Design files and assets

Figma files, logo source files, photography, fonts and their licences. Without them, every future change starts with recreating what you already paid for.

How lock-in actually happens

It's rarely malicious. More often, it's convenience:

• the agency registers the domain "to save time" and never transfers it;
• the site goes on the agency's hosting account because they already have one;
• the analytics property sits in the agency's account with everyone else's;
• the code lives on the developer's laptop;
• a proprietary page builder means the site only runs on that one platform.

Each step makes sense on the day. Together they leave you unable to change supplier without starting over.

The site builder question

Platforms like Wix and Squarespace are a slightly different case. You own your content and usually your domain, but the website itself runs on the platform and can't be moved anywhere else. That isn't wrong; it's the deal. Just know it: leaving means rebuilding, taking your text, images and domain with you.

A custom site built on a standard stack, such as Next.js, can be moved to any host and continued by any competent developer.

What to put in the contract

Before you sign with any studio or freelancer, ask for these in writing:

1. Rights: all rights to code, design and content transfer to the client on final payment.
2. Accounts: domain, hosting, CMS, analytics and Search Console are opened in the client's name from the start, or transferred at handover.
3. Repository: source code in a repository the client owns.
4. Licences: fonts, images and paid components licensed in the client's name, or listed with their terms.
5. Documentation: enough for another developer to take over.
6. Exit: what happens to hosting, data and access if the relationship ends.

A good studio will agree to all six without hesitation. If one of them is a sticking point, ask why.

The handover checklist

At the end of the project, check each item yourself, logged in as your company:

• Domain registrar: our company is the registrant, and we hold the login.
• DNS: we can see and edit the records.
• Hosting: the account is ours, billed to us.
• Code: the repository is in our organisation.
• CMS: we're the account owner.
• Analytics and Search Console: we're the owner.
• Design files, logo files, fonts and photos: delivered and organised.
• Documentation and a walkthrough of how to edit content.

If you don't own your site today

Don't panic, and don't start with a lawyer. Most of it can be recovered with a polite, specific request.

1. Start with the domain. Log in to the registrar if you can, or look up the registrar and ask the current registrant to transfer the domain to an account in your company's name. Once you control the domain, you control your email and where the site points.
2. Ask for the rest in one list. Code repository, hosting, CMS, analytics, Search Console, design files. Send a short, written request with a date. Most suppliers comply quickly when the request is clear.
3. Check your contract and invoices. If you paid for the work and the contract mentions transfer of rights, quote it. If the contract says nothing, ownership can be less clear, which is exactly why it belongs in the next contract.
4. Secure your data first. Even if the code takes longer, export what you can now: content from the CMS, form submissions, analytics reports.
5. Plan the next site with a clean setup. Accounts in your name from day one, the supplier invited as a user, never the other way round.

If the old site has to be replaced while some of this is still unresolved, the content and URLs can usually be recovered from the live site itself, so a redesign doesn't have to wait for the previous supplier.

How I handle it

Every project at Unlockd ends with the code, domain, hosting, database, analytics and design files in the client's name, handed over with documentation and a recorded walkthrough. No licence fees and no lock-in: you can keep working with me, move to another developer or bring it in-house. That applies to websites and to custom software alike, and it's part of why I prefer a fixed price: the scope, the price and what you receive at the end are all written down before anything starts.

If you're unsure who controls your current site, the paid audit is a good moment to find out, before you need to change anything in a hurry.