Who actually owns your website?

A website is not one single object

People often talk about a website as though it were a piece of furniture delivered in one box. In practice, several parts sit together: an address, hosting, words and images, an interface, code, licences, technical accounts, and sometimes a database. Different contracts and different holders may apply to each one.

That distinction prevents two opposite mistakes. The first is assuming the business automatically owns everything as soon as the invoice is paid. The second is assuming it owns nothing because a provider still runs the server. The answer is built part by part, from the accounts and documents that actually exist.

The French government’s guide to sound intellectual-property practice makes the same distinction between content — brand assets, copy, photography, appearance — and the technical container — CMS, development, and hosting. It is a useful way to ask the questions in the right order.

• The address: domain name, holder, and registrar.
• The content: copy, photography, video, brand assets, and documents.
• The build: design, theme, custom code, CMS, and extensions.
• The operation: hosting, DNS, backups, and connected services.
• The data: forms, customers, orders, accounts, and analytics.

Start with the domain, because everything passes through it

The domain is the website’s public address, but it can also affect email and many technical settings. The first check is straightforward: which person or company is recorded as the holder, which registrar manages it, and who can open the account used to renew or transfer it?

A provider can perfectly well remain the administrative or technical contact. That role allows them to manage the domain without giving them the holder’s rights. The arrangement becomes fragile when the business does not know where the domain is registered, does not receive renewal notices, or relies on an email address it cannot control.

A sound setup does not shut the provider out; it gives each party the right role. The business is the holder, a durable company address secures the account, and the person doing the technical work receives the access they need — no more.

• The holder’s exact name and current contact details.
• Registrar and account identifier.
• A recovery email controlled by the business.
• Known renewal date and payment method.
• A written process for authorising a transfer.

A paid invoice does not describe the rights delivered

Payment proves that work was commissioned and paid for. On its own, it does not say how each creation may be copied, changed, handed to another provider, or reused elsewhere. For material protected by copyright, those uses are found in the contract, the proposal, and any relevant licences.

The French Intellectual Property Code requires a transfer of rights to be in writing and to define the rights transferred and their field of use. That does not mean a client should demand every possible right to every component. It means the uses that matter to the business should not be left implicit.

Delivery and permission to use something are also separate questions. Receiving source code does not authorise every use; holding theoretical rights without usable code, documentation, or access does not create practical independence either. With a CMS, plugin, or hosted platform, part of the system remains subject to its publisher’s licence. The contract should name those dependencies before they surface on departure day.

Being the holder without the accounts still creates dependency

A contract can be perfectly drafted and the website still impossible to recover because every account was created under a former employee’s personal inbox or the agency’s own address. Legal ownership and operational independence work together; neither replaces the other.

The safest approach is to create the structural accounts with a shared company address, then invite each contributor under their own identity. Access can then be removed cleanly without changing one password for the entire team. Two-factor authentication and recovery codes should remain under company control as well.

Do not put every password into a document sent by email. A password manager or the service’s own invitation system keeps an audit trail, limits permissions, and allows clean revocation. Infrastructure security often begins with this quiet organisational work.

• Domain, DNS, and any CDN.
• Hosting, server, storage, and backups.
• Source repository and deployment pipeline.
• CMS, shop, or application administration.
• Transactional email, payments, and external services.
• Analytics, Search Console, tag management, and consent.
• Password manager, two-factor authentication, and recovery codes.

The data must be able to leave before the contract ends

Data is more than the copy visible on the website. A shop contains customers, orders, and invoices; a business application has accounts, statuses, and history; even a simple form may hold enquiries containing personal information. An incomplete or unusable export is not a genuine handover.

The contract should say what will be returned, in which format, with which attachments, and when. It should also say what happens to copies kept by the provider and its own subcontractors. The CNIL recommends setting the conditions for returning or destroying data within the contract, not after the relationship has broken down.

The simplest test is to create an export while everything is working, then open it somewhere else. That exposes encoding problems, missing media, broken relationships between records, and absent documentation. A backup that has never been restored remains a promise.

A good contract still makes sense on the day the relationship ends

An exit clause does not need to sound hostile. It simply describes an orderly handover: notice period, assets supplied, export formats, account transfers, any assistance, its cost, and removal of access that is no longer required. A serious provider would rather have that clarity than improvise a separation.

The useful question is not “do I own everything?” but “what must the business still be able to do without this person?”. Publish, make a correction, renew the domain, restore the service, commission an improvement, export the data: each answer points to an access right or a clause that should exist.

This check belongs alongside the website quote checklist and website project brief. A few precise lines before signature cost less than reconstructing the system under pressure.

• Exact list of accounts created and the holder of each one.
• Deliverables supplied at launch and at the end of the contract.
• Third-party licences, renewals, and export limits.
• Expected rights to use, change, and hand over the work.
• Return formats for files and data.
• Timescale, cost, and scope of transfer assistance.
• Removal or revocation of access once the handover is confirmed.

If access is already missing, begin with a calm inventory

Changing every password or DNS record in a hurry can take the website offline and stop email delivery. Begin by collecting invoices, contracts, renewal messages, and service invitations. They often identify the registrar, host, connected services, and people who still have access.

Then request a written account and deliverables inventory without making accusations or assuming the legal outcome. Back up whatever is accessible before changing it. If a transfer is possible, move one service at a time and verify each handover before removing the old access.

A disagreement over rights, a domain registered under the wrong name, or a refusal to return assets should not be handled by forcing technical access. Preserve the records and correspondence, then have the contract reviewed by an appropriate professional. For a cooperative rebuild, the SEO migration plan can then organise the public-facing move.

• Inventory before changing anything.
• Back up before transferring.
• Use addresses controlled by the business.
• Test every recovered account and export.
• Remove old permissions only after validation.
• Seek legal review if ownership or return of assets is disputed.