Websites

Who actually owns your website? The question nobody asks

Domain, content, code, access: your site is a bundle of 4 assets that can belong to different people. How to check who owns what.

By InlevenUpdated on June 24, 20268 min read
Glowing glass key resting on a translucent cube, an image of owning your website

A website isn’t an object. It’s a bundle of four separate assets (the domain name, the content, the code, and access to the services that keep it running) that can belong to different people. If even one of them is in your provider’s name instead of yours, you’re locked in without knowing it. The day you want to take your assets elsewhere, you discover that “your” site isn’t as much yours as you thought. Here’s how to check who owns what, and what to demand from a provider before it’s too late.

A “website” is really 4 separate assets

When you say “my site,” you’re actually talking about four things:

  1. The domain name, your-company.com. The address where people find you.
  2. The content, your copy, photos, videos, logos. The substance of the site.
  3. The code, the technical files (HTML, CSS, JS, database) that make the site work.
  4. The access, hosting accounts, database, third-party services (Google Analytics, forms, payments). The keys to the engine.

Each of these assets can, legally, belong to a different person. In a clean setup, all four are yours. In a less clean one, a single one is enough for the provider to keep their grip on you.

Who owns the domain name?

This is the point that surprises people most, from the owner of a small business to the IT manager at a mid-sized company who discovers that the firm’s long-standing domain was never in its name. A domain name isn’t “sold,” it’s rented, usually for one to ten years, from a registrar (OVH, Gandi, Cloudflare, GoDaddy, and so on). And it’s the person listed as the owner (the “owner” field in public whois records) who decides everything: transfer, renewal, redirection, cancellation.

Three common scenarios:

  • The domain is in your name (or your company’s). This is the good case. You can transfer it to another registrar at any time, without asking anyone’s permission.
  • The domain is in your provider’s name. As long as you stay with them, nothing looks wrong. The day you want it back, you ask for the transfer, and they refuse, charge exit fees, or stop answering.
  • The domain is with a provider’s “in-house” registrar. The worst case: no standard transfer procedure, technical dependency grafted onto commercial dependency.

Checking takes two minutes. Type whois your-company.com into any online whois tool (AFNIC offers a free one for .fr domains). The “Owner” field should show your name or your company’s. If it shows anything else, now is the time to act, not in two years.

What if you already manage your own DNS and cloud accounts?

Everything above is still a useful reminder even when you think you know. One level up, the nuance that trips up technical teams is the distinction between owner and manager. In a registrar’s or host’s console, the “owner” account (the one that legally holds the resource and can close or transfer it) is not the “admin” account that runs things day to day. A provider can happily give you comfortable admin access while keeping actual ownership. Check the role, not just the fact that you have a login.

Two more points for an IT department:

  • Delegated DNS. The domain can be in your name but its DNS servers delegated to the provider (or pointed at their infrastructure). You’re the owner, but resolution depends on them. Ideally, the DNS zone is hosted on an account you control (Cloudflare, the registrar, your own managed DNS).
  • Cloud accounts and transfer of ownership. When the infrastructure runs on AWS, GCP, or Cloudflare, the real question isn’t “do I have access?” but “are the billing account and the organization in my name?”. Migrating a project between two AWS accounts or transferring ownership of a Cloudflare organization is not trivial: better to frame it from the start than in the rush of a relationship ending.

Who owns the content and the code?

Legally, in France, you are the author of what you write and the owner of the photos you took or commissioned. For the content you supply yourself, the question is clear: it’s yours. Just ask for the contract to say so in black and white.

For the code, it’s more nuanced. There are three typical cases.

A custom site built for you. The contract must explicitly state that the source code is handed over at the end of the project or on request, and that it belongs to you. Without that clause, the provider remains the owner of their work, and you have a right to use it, not to own it.

A site built on an open-source CMS (WordPress, Astro, etc.). The CMS code doesn’t belong to you (it’s under a free license, available to everyone). The code specific to your site, theme, configuration, custom-built plugins, that part should be handed over to you.

A site on a proprietary platform (Wix, Squarespace, Webflow, or a provider’s in-house builder). You don’t own the code, you rent the use of the platform. That’s fine as long as the other assets (domain, content, access) are yours, and the platform lets you export your content if you leave.

The point to remember: being unable to retrieve your content in a reusable format (Markdown, HTML, CSV, SQL database, and so on) is the real marker of lock-in. Not owning the code itself.

Four glass objects in a row (globe, document, code braces, key), an image of the four assets of a website

What about hosting, email, and analytics access?

The least visible trap, and yet the most frequent. Four accounts to keep an eye on.

  • The hosting account (OVH, Cloudflare, Netlify, Vercel, and so on). If it’s opened in the provider’s name, they can cut off your site in two clicks. Ask for it to be opened in your name, with your credentials, and have the provider added as a collaborator.
  • The mailboxes tied to the domain (contact@your-company.com, and so on). Same thing: account in your company’s name, provider with delegated access.
  • Google Analytics or equivalent. The history of your traffic is valuable. The account should be in your company’s name, with you as administrator.
  • Third-party services, forms, booking calendar, Stripe payments, and so on. All these accounts should be in your company’s name. The provider is a guest, not the owner.

A good rule: if your provider shut down tomorrow, could you recover every key to the site in less than a day? If the answer is “no,” something needs to be put in order now.

How to check in 5 minutes?

A quick little investigation:

  1. Run a whois on your domain. Note the owner.
  2. Open your last hosting invoice. Whose name is on it?
  3. Log in to your hosting account. Do you have administrator access, or only “editor”?
  4. Ask yourself: if I wanted to export all my site’s content this week, would I know how?
  5. Do you have, somewhere on your computer, in an email, or in a drive, a copy of the contract with your provider and the list of access credentials?

If you get stuck on one of these steps, it’s a signal, not a catastrophe. A serious provider sorts it out without difficulty: domain put in your name, access transferred, contract clarified. Reluctance is, in itself, an answer.

The right questions to ask before signing

Before starting with a new provider, ask in writing (an email will do):

  • Will the domain name be in my name (or my company’s)?
  • Does the contract specify that the content and any custom code belong to me?
  • Which host will the site sit on, and will the account be in my name?
  • The day I decide to leave, what exactly is the procedure to recover my domain, my content, and my code, and are there any exit fees?

Good providers answer fast and clearly, because they’ve heard the question before and it works in their favor. The others talk around it. That’s precisely the information you were looking for.

These questions apply whatever the format, subscription, one-off package, freelancer, or agency. The trap isn’t about how you’re billed: a site paid for in one shot can leave you just as locked in if the domain stays in the provider’s name, and a subscription can perfectly let you walk away with everything. If you want to dig into the subscription format specifically, it’s right here. To place the real cost ranges by format, the article on pricing fills in the picture.

On our side, at Inleven, we wanted to make these commitments explicit and public. The Guarantees page lists in black and white who owns what: domain, content, and code are yours from day one, and you walk away with the whole thing, no exit fee, no penalty. It’s also what our offer spells out: a first year that funds the custom work, in 12 payments or one, then 180 €/year all included. It’s the reading we wish we’d had when we started.

Frequently asked questions

Can my provider keep my domain name if I stop working with them?

If they're the registered owner (the "owner" field in whois records), then yes, they hold legal control of it. That's exactly why it's worth checking right now that the domain is registered in your name or your company's. If it is, you can transfer it to another registrar whenever you want, without their consent.

Is having admin access the same as being the owner?

No, and it's the costliest confusion there is. An "admin" account runs things day to day; an "owner" account holds the resource and is the only one that can transfer it, close it, or change billing. You can have very broad admin access while owning nothing at all. Check the exact role, not just the fact that you have a login.

If my site is on Wix, Squarespace, or Webflow, am I locked in?

Not necessarily. You don't own the code on those platforms, but that's fine as long as the domain, content, and access are in your name, and the platform lets you export your content in a reusable format. The real marker of lock-in isn't the absence of code, it's the inability to retrieve your data.

What should I actually ask for before signing, so I can reclaim my assets later?

Ask in writing for the domain to be in your name, for the contract to spell out ownership of the content and any custom code, for hosting and third-party accounts to be opened under your company (with the provider added as a collaborator), and for the exact procedure to recover the domain, content, and code the day you leave, exit fees included. A serious provider puts all of this in writing without flinching.

Have a project?

A 15-minute call is enough to get started. Nothing to sign.