Who Owns Your Website: Domain, Code, Design and the Clauses That Decide It

“We paid for it, so it is ours” is the most common belief about website ownership and it is wrong in most of Europe. Paying an invoice buys delivery of a thing. It does not, by default, transfer the rights in that thing, and the gap between those two only becomes visible at the moment you want to leave, redesign, or hand the site to a different supplier.

Ownership is not one question. It is six, and they are routinely held by different parties without anyone intending it.

The six things people mean by “the website”

Asset	Who usually holds it	What it costs you if they do
Domain name	Whoever is listed as registrant	Total leverage. Nothing else matters if this is wrong
Hosting and infrastructure accounts	Often the agency, for convenience	Migration becomes a negotiation instead of a task
Custom source code	The author, unless assigned in writing	You may hold a licence to use, not a right to modify or resell
Design source files	The designer, in their own workspace	A rebuild starts from screenshots
Content and photography	Author or stock licensor	Licences that do not travel to a new site or a new owner
Analytics, ads and customer data	Whoever created the accounts	History is lost; personal data obligations stay with you regardless

Why payment does not transfer copyright

Under European copyright doctrine the author is the initial owner of the rights, and the author is a natural person: the developer, the designer, the copywriter. There is no general European equivalent of the American “work made for hire” that vests ownership in a commissioning client automatically. Transfer requires a written assignment, and an oral or implied one is usually not enough.

Software has one important carve-out. Directive 2009/24/EC on the legal protection of computer programs provides that where a program is created by an employee in the execution of their duties, the economic rights belong to the employer unless agreed otherwise. Note the word employee. A freelance contractor is not covered by that provision, and neither, in most readings, is an agency’s relationship with its client. So an agency can own the rights in code written by its own staff and still hold them against you.

The practical consequence: without an assignment clause, what you typically have is an implied licence to use the site for the purpose it was commissioned for. That is usually enough to run the site. It is frequently not enough to have someone else modify it, to reuse the code on a second project, or to sell the business including the site as an asset.

Moral rights are the second complication. In most European jurisdictions they cannot be assigned at all, only waived to the extent local law permits. That is rarely a commercial problem, but it is why a well-drafted contract addresses attribution and modification explicitly rather than claiming to buy “all rights”.

What you cannot own, no matter what the contract says

Three categories are permanently outside any ownership clause, and a supplier promising otherwise is either careless or misleading you.

GPL-licensed code. WordPress core, and by inheritance most themes and plugins, is distributed under the GPL. You can own the custom code written for you, but you cannot obtain exclusive rights over GPL-derived work, and neither can your agency. This is worth understanding before paying a premium for “exclusive” anything built on WordPress.
Licensed components. Commercial plugins, premium themes, fonts and stock imagery are licensed, not sold. Font licences in particular are commonly tied to a domain or a pageview band, and they do not automatically follow a site to a new owner.
Third-party services. Anything running on someone else’s platform is governed by their terms, which is the same class of exposure covered by a vendor risk checklist.

A good deliverable, then, is not “we own everything”. It is an inventory: this is assigned to you, this is licensed to you and here are the terms, this is open source and here is the licence.

The domain: the one that outranks every other clause

A domain is not owned in the way property is owned. It is registered, for a term, to a named registrant. Whoever appears in that field controls it, and everything else you have is downstream of that fact.

Check the registrant, not the admin contact. Being the administrative or technical contact confers nothing. Your organisation should be the registrant.
Know that changing the registrant has a cost. Under the ICANN Transfer Policy, a change of registrant can trigger a 60-day lock on transferring the domain to another registrar. That is survivable when planned and painful when discovered mid-migration.
Country domains follow their own registry rules. The .bg and .ua zones are administered under national registry policies that differ from the gTLD framework, including on documentation and transfer procedure. Check the registry, not the reseller’s help page.
Keep renewal in your own billing. A domain lost to an unpaid renewal on a card nobody monitors is a common and entirely avoidable failure, and it interacts badly with everything in a planned domain migration.

Accounts, and the quiet accumulation of dependency

The hosting account is the obvious one. The less obvious ones accumulate over years: the DNS provider, the CDN, the certificate issuer, the transactional email service, the analytics property, Search Console, the ad accounts, the repository, the design workspace, the plugin licences.

The rule that resolves all of them is the same: the account is created under your organisation’s identity and billing, and the supplier is added as a user. This is slightly less convenient for the supplier and dramatically cheaper for you at exit. It also matters for continuity of data, because analytics history does not transfer between accounts, and a new property starts at zero regardless of how long the site has existed.

Where those accounts physically hold data is a separate question with its own consequences, covered in where your website data actually lives.

Customer data is not an ownership question at all

Personal data collected through the site sits outside the copyright discussion entirely. Under the GDPR you are almost always the controller and your agency is a processor, which requires a written processing agreement, and those obligations do not move because a contract calls the data someone’s property. Data is not owned; it is processed lawfully or unlawfully. The practical implications for what you may collect and keep are set out in what you can collect and what you cannot.

The clauses worth having, in plain terms

You do not need elaborate drafting. You need five things stated unambiguously.

Assignment on payment. Economic rights in the bespoke work assign to the client on receipt of final payment, worldwide and irrevocably, including the right to modify and to authorise others to modify. Tying assignment to payment protects both sides.
An inventory of what is not assigned. Named third-party components with their licences, and the supplier’s pre-existing reusable code, licensed to you perpetually rather than assigned.
Source deliverables defined. Not “the files” but the actual list: repository access, design source in an editable format, database export, credential handover.
Account ownership. All service accounts registered to the client, supplier granted access as a user.
Exit procedure with a deadline. What is handed over, in what format, within how many working days of a request. Without a deadline, the obligation is decorative.

These are exactly the points that separate a supplier who has done this before from one improvising, which is why they appear among the questions worth asking before you sign.

A ten-minute check on a site you already have

If the site already exists and the contract is vague, four checks tell you where you stand today.

Run a WHOIS lookup on your domain. If the registrant is not your organisation, this is the first thing to fix and it is usually fixable amicably.
Log in to the hosting account yourself. Not through the supplier. If you cannot, you do not control your hosting.
Ask for the repository URL and open it. If the answer is a zip file emailed on request, there is no version history and no realistic way for a second supplier to take over safely.
Ask who the registrant, billing owner and licence holder is for each paid component. Write the answers in one table. That table is your actual ownership position, whatever the contract says.

None of this implies bad faith. Most of these arrangements start as convenience during a launch and simply never get unwound. They become a problem only at the point of change, which is also the point when nobody has time to fix them.

The short version

Paying for a website does not transfer copyright in most of Europe: the author owns the rights and a written assignment is required. The software directive gives economic rights to employers for employee-written code, which is why an agency can legitimately hold rights against a client who paid. Ownership splits into six assets and they drift into different hands: domain, infrastructure accounts, custom code, design sources, content licences and data accounts. Some things cannot be owned at all, notably GPL-derived code and licensed fonts, plugins and imagery, so the right deliverable is an inventory rather than a blanket claim. The domain outranks everything else, and a registrant change can lock transfers for 60 days under ICANN policy. Personal data is not property; it is a controller obligation that stays with you. Five clauses cover the rest: assignment on payment, an exclusions inventory, defined source deliverables, accounts in your name, and an exit procedure with a deadline.