Who Owns My Website? Lock-in and Access to Code, Domain and Hosting

Who owns your website? In principle you do, as the client paying for it, but in practice that depends entirely on what has been set out in the contract and whose name the accounts are registered under. A website is not a single asset but a collection of separate parts, and each of them can end up with a different party or in a different account. In this article you will read which parts exist, where lock-in arises, and exactly what you need to secure in order to stay free to move, renew or switch supplier.

This is deliberately a level-headed, practical story. Not because most agencies have bad intentions, but because ownership that no one explicitly arranges often ends up in the wrong name by accident. And you only notice that at the worst possible moment: when you want to leave. If you want the broader picture around a professional build, read our guide to having a B2B website built; ownership is a fixed part of that.

What does “owning your website” actually mean?

Owning your website means that you can, without the permission of a third party, access every part needed to keep the site running, to change it or to move it. So it is not a question with a single answer. A website consists of at least five separate layers, and ownership needs to be looked at layer by layer:

• The domain name. The address where you are found, plus the associated DNS settings.
• The source code and the design files. The HTML, CSS and any custom code, or the project file in a platform such as Webflow or WordPress.
• The content and the CMS structure. Your texts, images, pages and the way they are put together.
• The hosting. The servers or the platform subscription on which the site is live.
• The connected accounts. Analytics, Search Console, email, form and marketing tools, paid plugins or licenses.

The catch is that these layers are independent of each other. You can own the source code but have no access to the hosting. Or have the domain in your name, while the CMS content sits in an account only the agency can reach. True ownership means you control all five, or can at least access them without obstruction.

Which part is most important to secure?

Start with the domain name, because that is the part where lock-in hurts hardest and, at the same time, is easiest to avoid. A domain has a registered holder (the registrant), and that holder is legally the owner, not whoever manages it. If your agency registers the domain “just for you” in its own name or in its own registrar account, you are stuck there. When moving, you need their cooperation for the transfer code, and without that cooperation you are going nowhere.

The rule is simple: the domain is in your company’s name, in a registrar account your company holds the login details for. Letting your agency manage it is fine, but as registered holder and account owner it is your organization that appears. The same principle applies to your most important measurement data. Put Google Analytics and Search Console on an account owned by your company and give the agency access as a user, not the other way around. If the work moves, you do not lose your history. That is exactly what makes the difference during a later website migration without ranking loss.

Where does the lock-in sit per platform?

Lock-in is not a property of a bad platform, but of poorly arranged access. The form it takes does differ per type of build, however, and it is fair to name those differences without declaring one choice the winner.

With an open CMS such as WordPress you in theory have everything in hand: it is your codebase, your database, your files, running on hosting you can choose yourself. The lock-in there does not sit in the platform but in the accounts around it. Who has the admin login, whose hosting account is it on, and who owns the licenses for the paid plugins and the theme? Without those things you own a site you cannot move.

With a visual platform such as Webflow you get ease of use and hosted infrastructure, but ownership is divided differently. You can export the front-end code (on the subscriptions intended for that), but that export does not include the CMS content, the forms or the hosting functionality; those stay tied to the platform. The practical “ownership question” here is mainly: does the project sit in a workspace in your company’s name, so that you can hand over management without rebuilding the entire site?

With custom or headless you usually have the most control over the code, but you depend on good documentation and access to the repository and the separate services. Without the Git repository, the environment variables and a readable handover, expensive custom code is still a black box. If you are considering decoupling the separate layers, our explanation of how a headless CMS works helps you see where ownership and dependency exactly lie.

So the conclusion is not “choose platform X to avoid lock-in”. It is: on every platform your access, not the technology, determines whether you are free. Which option fits best depends on your team, your growth plans and how often you want to be able to make changes yourself. That is also how we look at website development in a platform-independent way: the right tool for your specific case.

What needs to be in the contract?

Set out ownership and access in writing before the first invoice, because negotiating afterwards about something you have already paid for puts you in a weak position. A good agreement does not have to be long, but it covers these points:

1. Ownership of the delivered work. Make it explicit that the source code, the design files and the content become your property after payment (transfer of usage rights), and not merely “licensed”.
2. Accounts in your name. Domain, hosting, CMS, analytics and paid tools are on accounts owned by your company. The agency works as a user with access, not as an owner.
3. An exit clause. What do you get when the collaboration ends, in what form, and within what timeframe? Think of an export of the content, the complete codebase, a database dump and a list of all accounts and licenses.
4. Documentation and handover. Agree that a concise technical handover will be provided: where everything is, how you deploy, which services are connected.
5. No hostage-taking in a dispute. Set out that you keep access to your live site and your data, even if there is a discussion over an invoice.

An agency that thinks along with you has no problem with this. Clear agreements about ownership are precisely a sign of trust, and that is what a good B2B relationship runs on. Besides external ownership, also arrange internally who manages the site: good website governance sets out who within your own company owns the site. It is the same logic that determines whether visitors believe you: see building trust on your B2B website.

How do you get your ownership back if it went wrong?

If you are already stuck, start with a calm inventory rather than a conflict. Make a list of the five layers and find out, per layer, whose name and which account each one sits under. Often it is not so bad and it is a matter of having access transferred, or of getting yourself added as owner to an account.

For the domain you request the transfer code (the auth code or EPP code) and move it to a registrar in your company’s name. For analytics and Search Console you have yourself added as administrator while you still get cooperation. For the content the rule is: even if you cannot export the old site, you can usually still retrieve the texts and images to rebuild them elsewhere. And if a move inevitably becomes a new build, plan it properly right away, so you do not lose your positions. A well-thought-out website redesign process takes exactly that continuity into account.

The most valuable thing you can lose is not the code, which can be rebuilt, but your domain and your accumulated measurement data. Protect those two first and the rest follows.

The short summary

Owning your website means you can access five parts without obstruction: the domain, the source code and design files, the CMS content, the hosting and all connected accounts. Lock-in rarely arises from bad faith, but from access that ends up in the agency’s name by accident. Put your domain and your analytics first on accounts owned by your own company, set out ownership and an exit clause in writing before you start, and arrange a clean handover. Do that, and you stay free to grow, renew or switch, without it ever becoming a fight.

Want to be sure that your new or existing site is entirely yours, with agreements that lock you in nowhere? Book your free intake and we will walk through your ownership and your options together.