Guides

Who really owns your website?

Paying for a website does not automatically mean controlling its domain, hosting, code, licences, data and accounts. Real ownership is tested when you can manage, recover and transfer every element without relying on one person.

The short answer

A website is genuinely under the company’s control when the domain and external services are registered to the client, primary access and recovery do not depend on the provider, code rights and licences are declared, data and content can be exported and the contract defines an exit path. The technician must be able to work without becoming the owner of the infrastructure.

Gian Luca Partengo
Web developer since 1995 · bespoke websites · Updated 18 August 2026

Paying for the website is not enough: you need four proofs

An invoice proves an economic relationship. On its own, it does not prove who can renew the domain, enter the hosting account, use the code or recover the data.

01The business is the registrant or contracting party for essential services
02It controls primary access, recovery and billing
03It knows the rights, licences and limits of the materials used
04It can export and transfer the project through a defined process

Registration, control, contractual clarity and exit must exist together.

Ownership, technical control and portability are not the same thing

A contract may recognise a right without providing the access needed to exercise it. Conversely, knowing a password does not automatically confer rights over code or content.

RIGHTS

Title and licences

They establish who may use, modify, reproduce or transfer code, photographs, fonts, copy and other materials.

ACCESS

Operational control

It covers administrator accounts, DNS, hosting, repositories, backups, authentication factors and recovery processes.

COSTS

Contractual relationship

The party that pays and receives invoices can see renewals, deadlines and conditions. Opaque reselling hides price and continuity.

EXIT

Real portability

It tests whether data, configurations and assets can move to another environment without rebuilding everything or waiting for favours.

The rule

A website is not genuinely independent if the client can use it only while the provider retains personal accounts, shared licences or undocumented information.

The domain should not belong to the agency or developer

The domain name supports the website, email, reputation and often the verification of other services. Losing control can block far more than the homepage.

PRECISION MATTERS

A domain is registered and renewed

It is not property bought forever. The registrant enters into a contract with a registrar and maintains the right to use it by complying with the terms and renewals.

For a business, the registrant, contact details, registrar account, payment and recovery should remain under its control. The technician receives only the access they need.

Correct registrant

The named party should be the business or legitimate holder, with current, verifiable details even when public WHOIS records mask them.

Registrar account

The primary email, password, second factor and recovery should not belong exclusively to the provider or a former employee.

Renewal and billing

Expiry, payment method and notices should reach the client. Automatic renewal does not replace checking the contact details.

Possible transfer

Domain status, locks, authorisation code and process should be known before an emergency, not discovered during a dispute.

Hosting, DNS and email: whoever controls the infrastructure controls continuity

Even with the domain correctly registered, a shared hosting account or unreachable DNS zone can prevent migration, restoration and email management.

01

Hosting

The contract, plan, payment and client area should belong to the client. The technician joins through a separate role when the provider supports it.

02

DNS

Web records, email, verifications and external services depend on the DNS zone. The business must know where it lives and who can change it.

03

Email

Mailboxes, aliases, forwarding, SPF, DKIM and DMARC are not minor website details. A bad migration can interrupt business email.

04

Billing

The client sees the real cost, renewals and deadlines without relying on a resold fee that hides the provider and conditions.

05

Backups

Clarify what they contain, how long they remain, who can download them and whether restoration has actually been tested.

06

Recovery

Recovery email and phone, second factor and emergency codes should remain available to the business without sharing personal passwords.

Code, CMSs and licences: “it is online” does not mean “it is yours”

Software is protected by copyright and may be assigned, licensed or assembled from parts under different terms. The contract must describe the technical reality.

Element	What it means	Evidence to retain	Exit test
Bespoke code	Rights to use, modify, receive, reuse or hold exclusively depend on the contract and applicable law.	Contract, scope, repository and documentation of delivered components.	A new technician understands what they may use and which files are available.
CMS and open source	The business uses the software under its licence; it does not own the project or its roadmap.	Versions, licences, installed components and exportable configuration.	The website can move without depending on the developer’s personal account.
Commercial themes and plugins	Updates, support, allowed sites and transfer follow the purchased licence.	Invoice, licensee, key, account and current terms.	The licence remains valid or a declared replacement cost exists.
Builders and SaaS	The website operates inside the service and export may be partial or not functionally equivalent.	Account, plan, billing, available exports and termination terms.	Useful content and data leave in a reusable format, or the limitation is knowingly accepted.
Published copy	Files on the server may not match source files, builds, repositories and project materials.	Inventory of source, dependencies, build and publishing environment.	The project can be rebuilt and published without the old provider’s machine.

Writing “the client owns the website” is not enough

The clause must distinguish external accounts, project-specific code, pre-existing components, open-source software, commercial licences, assets and the published copy.

To understand how themes, plugins and external roadmaps create dependency, also read the real cost of WordPress.

Copy, photographs, fonts and design files carry different rights

Saving a file does not mean owning its rights. Origin, licence, author and reuse permissions should follow the asset throughout the website’s life.

Copy

State who supplies it, who writes it and which rights are granted. Copying someone else’s pages does not create ownership.

Original photography

Author, releases, subjects, locations and permitted uses should be documented, especially for campaigns and reuse.

Stock images

They are normally licensed, not sold as absolute property. The account and purchase evidence should belong to the client.

Fonts

Desktop, webfont, app and page-view licences may have different terms. Having the file does not prove authorised use.

Logo and identity

Final files, working files, fonts, licensed elements and limits on modification or trademark registration should be distinguished.

Source files

PSD, AI, Figma, RAW and editing files are not automatically the same as published JPEG, SVG or video assets. Delivery must be agreed.

Data is not something to “own” without distinguishing roles and rights

Databases, enquiries, orders and statistics may contain personal data, business data, logs and third-party information. Commercial ownership and data protection are not the same question.

PRIVACY

People retain rights over their personal data

The business may act as controller and determine purposes and means; providers and technicians may act as processors or authorised persons depending on the circumstances.

The contract, privacy notice, security measures and termination process should establish access, return, deletion and retention. Simply saying “the data belongs to the client” is not enough.

Declared roles

Controller, processors, sub-processors and authorised people should reflect what actually happens, not labels added later.

Instructions and security

Anyone processing data for the client should follow documented instructions, limit access and assist with applicable obligations.

Useful export

A file exists only when it is readable, complete, documented and importable. Screenshots and PDFs do not always replace databases or structured formats.

Return and deletion

At termination, the choices required by the contract and law must be applied, including copies, backups, retention duties and evidence of the outcome.

This guide provides technical and organisational criteria, not legal advice. Roles, lawful bases and duties should be reviewed against the actual processing.

The invisible accounts that decide whether the website is really yours

A website can keep running while essential tools belong to personal emails or agency accounts. The problem appears when someone changes, a figure needs verification or access must be revoked.

01

Search Console

The business should retain at least one verified owner and know which tokens remain active. The technician can be added with the role they need.

02

Google Business Profile

The business owner remains primary owner; agencies and consultants operate as managers or authorised representatives.

03

Privacy and iubenda

The account, plan, invoices and documents should belong to the client. The technician configures integrations and services without owning the policies.

04

Plausible and analytics

The client can own the team, subscription and billing; owner, administrator and collaborator are separate, revocable roles.

05

Payments

The gateway, bank, verification, revenue, refunds and commercial obligations should belong to the business, not pass through the developer’s account.

06

APIs and email services

Keys, limits, verified domains, reputation and billing should be inventoried. Technical keys can be rotated without losing the account.

Inviting is better than sharing

When a platform offers roles, the client remains owner and invites the technician through a personal account. At the end, that access is revoked without changing ownership, card or billing.

The GLP method: the client owns the services from day one

This is not a newly introduced process. It is the method Gian Luca Partengo has used throughout his web career: no external service is placed in the technician’s name to retain the client.

ETHICAL PRINCIPLE

The client stays for the service, not because they are trapped

Domain, hosting, iubenda, Plausible, gateways, stock images and every other third-party purchase are registered directly by the client using their own details, payment method and billing information.

Gian Luca accesses them only as a technician when needed. Created code, software components, deliverables and rights are instead described separately in the contract and under the applicable licences.

01
The client registers
They use a business email, current contact details and recovery systems controlled by the organisation.
02
The client pays
They enter their own payment method and see the provider’s price, renewal, deadlines and conditions directly.
03
The client receives the invoice
The economic relationship with the external service remains transparent and is not hidden inside an undifferentiated fee.
04
GLP joins as technician
Where roles or collaborators exist, access is separate, personal, limited and revocable without sharing the primary password.
05
The client stays in control
They retain primary access, recovery systems, two-factor authentication, emergency codes, contracts and receipts without depending on the technician.
06
The client can revoke
At the end of the relationship they do not need to request account transfers: they remove technical access and retain services, invoices and recovery.

Nothing to hand back

There is no final handover for third-party accounts and purchases: they already belong to the client. This is the difference between technical support and artificial dependency.

Practical case: the website was paid for, but the business cannot move it

A composite, realistic scenario built from recurring industry problems. It does not describe one client or a specific dispute.

01
The relationship ends
The business wants to change provider after years of regular payments and asks for access, materials and a handover timetable.
02
The domain is in the agency account
The client does not know the registrar, recovery email or transfer process and never receives renewal notices directly.
03
Hosting contains many clients
There is no separate control panel. Database, mail, backups and configuration must be extracted without exposing other businesses’ data.
04
Theme and plugins use agency licences
The website can be copied, but updates and support end. Some functions require new licences or a rebuild.
05
Marketing accounts are personal
Search Console, the Google profile, analytics and email tools are linked to people who no longer work on the project.
06
Migration becomes recovery
Before improving the website, the team must reconstruct inventory, rights, access and data. Cost and risk come from dependency, not technology alone.

Checklist: is your website really under control?

Every element needs administrative or technical evidence and an exit test. A generic answer such as “the agency handles everything” is not evidence.

Element	What to verify	Concrete test
Domain	Registrant, registrar, renewal, recovery and domain status.	Enter the account and locate the transfer process and authorisation code.
Hosting	Account holder, plan, invoices, panel, expiry and support.	Invite a technician or prepare an independent environment without shared accounts.
DNS	Provider, nameservers, web and mail records and verifications.	Export or document the zone and identify who may change it.
Email	Mailboxes, aliases, archives, SPF, DKIM, DMARC and recovery.	Migrate a sample mailbox or document export and restoration.
Code	Rights, published files, source, repository, build and dependencies.	Rebuild and publish the project in a clean environment.
Licences	Licensee, covered sites, renewals, keys and transferability.	Verify what remains active after removing the agency account.
Content and assets	Authors, releases, fonts, stock, final files and agreed source files.	Collect materials and licence evidence outside the provider’s computer.
Data and backups	Privacy roles, formats, frequency, retention, copies and deletion.	Export a sample and test a readable, complete restoration.
Search and analytics	Owners, users, tokens, teams, events and billing.	Add and remove a collaborator without losing ownership.
Payments and APIs	Account holder, bank, keys, webhooks, domains and logs.	Rotate a technical key and confirm the client retains the account.

Do not run destructive tests on production. Transfers, key rotation and restoration need backups, planning and a rollback path.

What the contract should say before work starts

Trust does not replace a precise description. The contract should prevent conflict while people, tools and goals are still aligned.

Third-party services

Who registers, pays, receives invoices and accepts terms for domain, hosting, privacy, analytics, stock, payments and APIs.

Access and roles

Which accounts remain with the client, which permissions the technician receives and how they are protected, checked and revoked.

Code and components

Rights to use and modify, any source delivery, pre-existing components, open source and commercial licences.

Deliverables

Published files, materials, exports, documentation and credentials included or excluded from the agreed scope.

Data and privacy

Applicable roles, instructions, sub-providers, security, assistance, return, deletion and retention.

Backups and continuity

Who creates copies, what they contain, retention, restoration, cost and service limitations.

Termination

Notice, handover work, timings, formats, costs, access revocation and treatment of remaining copies.

Support

Responsibilities, hours, response times, exclusions and dependencies on external suppliers.

FUNDAMENTAL DISTINCTION

External accounts and code are not the same thing

Third-party accounts can belong to the client from the outset; code rights and deliverables must be governed separately. Mixing the two creates vague promises and avoidable disputes.

Eight signs that the client may be trapped

One sign does not prove wrongdoing, but it requires a documented answer. The more signs combine, the higher the operational risk.

DOMAIN

You do not know the registrant

The provider renews everything but does not show the account, details or transfer process.

HOSTING

There is no separate control panel

The website lives in a shared account and nobody explains how to extract the environment, email and backups.

ACCESS

One password controls everything

Personal accounts and shared passwords replace roles, two-factor authentication and traceable revocation.

LICENCES

Updates depend on the agency

Themes, plugins or services stop updating when the fee ends, with no declared continuity cost.

CODE

Nobody distinguishes source from the live website

There is no inventory, repository, build process or boundary between client and provider components.

DATA

Export happens only on request

Format, completeness, timing and costs are unknown and restoration has never been tested.

INVOICES

Services are one undifferentiated fee

The client does not know the suppliers, prices, renewals, conditions and consequences of termination.

EXIT

“We will deal with it when needed”

There is no notice period, timetable, responsibility, format or cost for handing over to a new technician.

Ten questions to ask before commissioning a website

The answers should be understandable to a non-developer. A serious professional can explain the model without hiding behind jargon.

01
Who will hold the domain and hosting accounts?
Ask who creates the accounts, who pays, who receives invoices and which details are used for recovery.
02
Can I invite you as a technician?
Check whether the provider offers collaborators or separate roles instead of sharing the primary password.
03
What code will be built and which rights will I have?
Distinguish project-specific code, libraries, pre-existing components, open source, licences and files actually delivered.
04
Which external services will be required?
Obtain an inventory of subscriptions, account holders, renewals, processed data and consequences if a service ends.
05
Who owns the images, fonts and content?
Ask about origin, licences, releases, final files, agreed source files and reuse permissions.
06
How are data and configurations exported?
Format, frequency, completeness and restoration should be verifiable before termination.
07
Who will own Google and analytics accounts?
The business should retain ownership and recovery; the provider receives a necessary, revocable role.
08
What happens when the relationship ends?
Ask about work, notice, timing, cost, revocation, formats, handover support and deletion of remaining copies.
09
Can I appoint another technician?
The answer should distinguish freedom of choice, code rights and real licence limits without vague threats.
10
How will everything be documented?
The contract, inventory, password manager, invoices, licences and processes should have clear owners and updates.

To assess skills, method and quotation, also read how to choose who builds your website.

Primary sources and official documentation

The sources distinguish registrants, account roles, technical collaboration, software, personal data and portability. The GLP method is an operational and commercial choice declared by Gian Luca Partengo.

ICANN — Information for domain name registrants
Definition of registrant, relationship with the registrar and rights concerning management, renewal, transfer and restoration.

Open source
Google Search Console — Owners, users and permissions
Differences between verified owner, delegated owner, full user and restricted user, including adding and removing access.

Open source
Google Business Profile — Ownership and representative guidelines
The business owner should understand and retain control of the profile; providers act as authorised representatives and managers.

Open source
SiteGround — Accessing websites as a collaborator
Separate technician access to Site Tools or Site Admin without using the owner’s primary Client Area credentials.

Open source
Plausible — Teams, guests and roles
Owner, admin, editor, billing and viewer separate ownership, management, billing and viewing for businesses, agencies and freelancers.

Open source
European Union — Directive 2009/24/EC on software
Protection of computer programs, authors and rightsholders, exclusive rights, licences and acts necessary for lawful use of software.

Open source
European Union — General Data Protection Regulation
Controller and processor roles, contracts, instructions, security and return or deletion of data after services end.

Open source
European Commission — Data Act and cloud switching
Measures on contractual transparency, barriers to provider switching, export and portability across data processing services.

Open source

Sources checked on 18 August 2026. Rules, interfaces, licences and service terms can change and should be checked against the actual contract and configuration.

Frequently asked questions about website ownership

Direct answers about domains, hosting, code, WordPress, accounts, data, licences, invoices and changing provider.

If I paid for the website, do I automatically own it?

Not necessarily every component. The invoice proves payment, but rights over code, licences, accounts, domain, assets and deliverables depend on registrations, terms and contract. They must be assessed separately.

Who should be the domain registrant?

The business or party entitled to use it, with the registrar account, contacts, renewal and recovery under its control. The technician can receive access for configuration without becoming the registrant.

Should the client purchase the hosting?

It is the most transparent choice: the contract, invoices, renewals and client area remain with the business, while the professional joins as collaborator. Other models require an explicit separation and exit process.

Does the client need to know every password?

The client should control the business’s primary accounts, recovery and administrator credentials. Personal passwords should not be shared: where possible, give the technician a separate account with the minimum necessary privileges.

Do WordPress and plugins belong to the client?

WordPress is used under its open-source licence; themes and plugins follow their own licences. The client can own directly purchased accounts and licences, but does not control the vendors’ roadmaps.

Must source code always be delivered?

It depends on the contract, project type and applicable rights. The contract should distinguish the published copy, source, repository, documentation, pre-existing components and licences rather than rely on generic wording.

Do stock images become the client’s property?

They are normally licensed under specific terms, not assigned as absolute property. The purchase, account and licence evidence should be attributable to the client and intended use.

Does the data collected by the website belong to the client?

Business data and personal data must be distinguished. The business may act as controller, but data subjects retain rights and providers have legal and contractual duties. Export and termination should be governed explicitly.

Who should own Search Console and Google Business Profile?

The business should retain ownership and recovery. Technicians and agencies can be added through separate, revocable roles without sharing the primary account.

What happens to accounts when the relationship with GLP ends?

External services do not need transferring: they were created, paid and billed directly to the client. The client retains everything and can remove GLP’s technical access.

How can I check an existing website?

Build an inventory of domain, hosting, DNS, email, code, licences, content, data, backups and external accounts. For each, identify the holder, access, billing, recovery, export and exit process.

Can a lock-in-free website still have ongoing maintenance?

Yes. A client can entrust management and support to a professional while retaining account ownership and the freedom to revoke access. Service continuity and artificial dependency are different things.