“Do I own my website?” sounds like a simple question, but the answer is almost never a flat yes or no. Ownership actually splits into four separate layers: your domain, your hosting, your source code and your content. You can easily own one layer and rent another, and that is exactly where the trouble starts. Anyone who begins with a cheap builder or a platform like Wix often only discovers at the moment they try to switch that the site is not technically theirs. In this cluster under our guide to commissioning a custom website we explain, layer by layer, what you own, where the lock-in hides, and the four things you demand up front so you are never stuck.
What does website ownership actually mean?
Website ownership is not one thing you either have or do not have. It is four layers you can own or rent independently of each other:
- Domain: the name, for example yourcompany.com. This is a yearly registration with a registrar, not a purchase. You hold it as long as you keep renewing.
- Hosting: the server where the site runs. Almost always a rental relationship, and that is fine as long as you can walk away from it.
- Source code: the actual files the site is made of. This is the layer where ownership matters most and goes wrong most often.
- Content: your text, images, blog posts, product data. Legally usually yours, but practically worthless if you cannot export it.
The tipping point almost always sits in the source code. With a custom website you receive that code as your property and you can switch supplier tomorrow. With a closed builder you effectively rent all four layers at once, packaged as a single subscription. You do not notice the difference on day one, but you do on the day you want to leave.
Do I own my site if I pay an agency to build it?
This is the most expensive misconception in the market: paying for the build does not automatically give you the code as property. Under Dutch copyright law, and similar law across most of the EU, the copyright on software sits with the maker by default, not the client, unless it is transferred in writing. Plenty of agencies know this and keep the source code on their own GitHub account. You get access to the live site and a login to the CMS, but not the underlying files.
The effect: as long as everything goes well, you notice nothing. But the day you want to leave, have a feature built by someone else, or the agency goes under, you are left empty-handed. You have a working website you cannot move, because you never received the building blocks.
So ask explicitly for code ownership before the start, fixed in the contract. At TopDevs that is standard and it is not a negotiating point. For the deeper legal side of this theme we wrote a separate explainer on code ownership and vendor lock-in.
Who owns my website on Wix or Squarespace?
With a builder like Wix or Squarespace the split is hard. You own your content and, if you registered it yourself, your domain. The code and the platform stay with the builder. That is not a hidden clause, it is their business model: you rent the whole structure by the month.
The pain sits in the export. Squarespace offers an XML export that carries text and some structure over to WordPress, but no design, no functionality, no exact layout. Wix offers even less: there is no export of your site as a working website, only loose content you have to move by hand. In practice, leaving a builder means rebuilding, not relocating.
| What you own | Wix | Squarespace | Custom (Git in your account) |
|---|---|---|---|
| Domain | Yes, if you registered it | Yes, if you registered it | Yes, own registrar account |
| Content (text, images) | Yes, legally | Yes, legally | Yes |
| Content export elsewhere | Limited, move by hand | XML export, no design | Full, in open formats |
| Source code | No | No | Yes, as property |
| Switch without rebuilding | No | No | Yes |
What is vendor lock-in and how does it arise with websites?
Vendor lock-in means switching to another party becomes so expensive or technically complicated that you are stuck in practice. With websites that lock-in stacks up from three common choices:
- The source code is not on your account. The agency owns the repository. When you leave, the code leaves with them.
- The domain sits in the agency’s account. This one is sneaky: the domain is legally yours, but if it lives in the builder’s registrar account you need their cooperation to move it. Some parties charge for that or make you wait weeks.
- The content only lives in a closed editor. No export, no database access, no plain text files. You can do nothing with it outside that one platform.
The more of these layers you own yourself, the lighter the lock-in. The difference between platforms is large here. An open system like WordPress gives you your database and files; a headless setup gives you content in clean, reusable formats. We put those options side by side in WordPress vs custom vs headless. According to the HTTP Archive Web Almanac, a large share of the web runs on WordPress, precisely because you keep your own data and code there in principle.
What exactly should you own? The checklist
Ownership is not a feeling, it is a list you can tick off. These are the items you demand up front and verify on delivery. Not “would be nice”, but the minimum standard.
| What you demand | Why it matters | How you verify it |
|---|---|---|
| Git repository on your account | Proof of code ownership, basis for migration | Log in to GitHub or GitLab, do you see the repo as owner? |
| Domain in your registrar account | You can move without the agency’s permission | Log in to the registrar in your own name |
| Full content export | Text and images are reusable outside the platform | Ask for an export file and open it |
| Hosting under your control or transferable | No hostage-taking of the live site | Access to the hosting panel or a transferable contract |
| All credentials in your name | DNS, analytics, mail services stay yours | A password vault with every login on delivery |
| Handover document or README | Someone else can understand and run the site | Read it: would a stranger developer get it? |
At TopDevs you get this list as standard: a Git repository under your own account with all source code, the domain in your registrar account, a README with deployment instructions, all credentials in your control and a handover session. If you leave later, any other developer can carry on without us. That is the definition of no lock-in.
Which red flags point to lock-in before you sign?
You do not need to be a lawyer to spot the signals. These phrases and situations are warnings that you are about to get stuck:
- “The code stays with us, you get a usage licence.” That is renting, not owning. Ask why.
- “We’ll handle the domain for you, no need to worry about it.” Fine as a service, but insist it lands in your account, not the agency’s.
- “Exporting is possible, but that’s a separate project with extra costs.” Ownership that costs money to retrieve is not full ownership.
- A proprietary, closed CMS or framework that only they maintain. It sounds clever, but no one else can work on it. Always ask: which standard, open stack do you build on?
- No written agreement on what you get when you leave. If it is not on paper, it does not exist in a dispute.
A good partner answers the question “what do I get if I want to leave” within five minutes, without dodging. A party that talks around it would rather hold on to you than serve you well. That is the sharpest litmus test there is.
What is the difference between renting hosting and owning your site?
There is a stubborn misunderstanding here: people think they own their site because they pay for hosting. But renting hosting is normal and not a problem. Almost everyone rents server space from a host, whether that is TransIP, Hetzner, Vercel or Cloudflare. The question is not whether you rent, but whether you can leave.
Ownership sits in the source code and the portability, not in the server. If you have your code in a Git repository and your content in open formats, hosting is a commodity you move in a day. The application sits separate from the infrastructure. If you do not have that, your hosting is a hostage situation: stop paying and the site goes offline, with nothing in your hands to put it back up elsewhere.
For the technical side of fast, portable sites, the web.dev guide to Core Web Vitals is a good standard to ask about, and for how Google judges sites, Google Search Central is the source. A site you own, you can keep improving on those points with whoever you like.
How do you get your website back if you are already stuck?
If you are already trapped, there is almost always a way out, in a fixed order:
- Domain first. Move the domain to your own registrar account. This is the most important layer and often just a matter of requesting a transfer code. If it will not work through your builder, the registrar or, in the worst case, the relevant domain authority can help.
- Secure the content. Copy all the text, download all the images, export whatever is exportable. Do this before you cancel any subscription anywhere.
- Assess the source code. If you have no repository, rebuilding is usually cheaper and faster than negotiating to pry loose code that lives on a closed platform.
- Rebuild on an open foundation. Choose a custom approach or an open platform where ownership is arranged from day one, so you never go through this again.
For a builder site (Wix, Squarespace), count on a real rebuild, not a relocation. That sounds like a loss, but it is a one-off correction after which you are free for good. For the trade-off between platforms and what it costs, read WordPress vs custom vs headless.
How do our cases prove that ownership works?
Ownership is not a promise on a slide, it is what you receive on delivery. Two examples where this became concrete:
- De Bungelaer. For this website and webdesign case we delivered the full source code in a repository under the client’s own control, plus the domain and all credentials. The company can have the site developed further by any developer.
- Quantum Life. For this platform with a custom interface, code ownership was a hard requirement from the discovery phase. Everything sits in the client’s name, including the deployment instructions.
The common thread: one team that designs and builds, then hands you everything you need to carry on without that team. That is exactly where the difference between renting and owning becomes visible. Want to compare the visual and build side, see our webdesign service.
What is the first step?
- Step 1: inventory your four layers. Where does your domain sit, who holds your hosting, does a repository exist, and can you export your content? Write down per layer whether you own it or rent it.
- Step 2: claim your domain back if it is not yet on your account. This is the fastest and most important win, often sorted in a day.
- Step 3: lock down ownership for your next project. Demand a Git repository under your account and a handover document, in the contract.
Book a call if you want to look together at whether you really own your site and how to get it back. No sales pressure, just an honest picture. For the broader context, see our guide to commissioning a custom website.
