Websites A fast site is care made visible: Core Web Vitals explained
Why a site's speed reveals the care put into it. Google's Core Web Vitals thresholds (LCP, INP, CLS) and how Inleven actually holds them.
Domain, content, code, access: your site is a bundle of 4 assets that can belong to different people. How to check who owns what.
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.
When you say “my site,” you’re actually talking about four things:
your-company.com. The address where people find you.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.
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:
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.
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:
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.

The least visible trap, and yet the most frequent. Four accounts to keep an eye on.
[email protected], and so on). Same thing: account in your company’s name, provider with delegated access.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.
A quick little investigation:
whois on your domain. Note the owner.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.
Before starting with a new provider, ask in writing (an email will do):
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, an initial 12-month commitment to fund the custom work, then a cancellable month-to-month plan. It’s the reading we wish we’d had when we started.
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.
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.
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.
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.