Who owns a website after development? The answer should be written before the project begins. In a typical client project, the business should control the domain, hosting, content, data, business accounts, analytics, and appropriate access to the delivered code or platform. Copyright, third-party licenses, and reusable developer tools may have separate terms.
This guide is a practical handover checklist, not legal advice. For a large or regulated project, have the contract reviewed by a qualified legal professional in the relevant jurisdiction.
Ownership, access, and licenses are different
These terms are often mixed together:
- Ownership concerns the legal rights to an asset, such as original copy or custom code, subject to the agreement and applicable law.
- Account control means the business can administer billing, recovery, users, and settings. You can control a hosting account without owning the provider’s software.
- Access is permission to use or manage an asset. A developer can have repository access without owning the repository.
- A license grants defined use rights without transferring the underlying copyright. Fonts, stock media, themes, plugins, and open-source packages commonly work this way.
- Possession of a copy is not necessarily ownership. Downloading a source archive does not by itself assign copyright or transfer a third-party license.
Ask the agreement to address each important asset explicitly. “Full ownership” is too broad when the website includes client materials, original supplier work, open-source packages, provider platforms, and licensed media.
Use an asset-by-asset ownership matrix
| Asset | Preferred business control | Contract or handover question |
|---|---|---|
| Domain | Business registrar account, recovery, billing | Who is the legal registrant and who can transfer it? |
| Hosting/cloud | Business organization or transferable account | Can the site and data be exported and redeployed? |
| Original code | Rights and source access defined in writing | What is assigned, licensed, reused, or excluded? |
| CMS/site builder | Business administrator access | Is the site portable, and what ends if a plan is cancelled? |
| Copy and original media | Rights cleared for the business | Were writers, photographers, and subcontractors covered? |
| Stock media/fonts | License recorded | Is use limited by domain, traffic, seats, or distribution? |
| Themes/plugins | Client-owned or documented supplier license | Who renews, and what fails or loses updates after expiry? |
| Analytics/search accounts | Business-owned property with supplier access | Can the business add/remove users and retain history? |
| Customer and order data | Business-controlled export and access | Where is it stored, retained, backed up, and deleted? |
| Design source files | Delivery requirement stated | Are editable sources included or only exported images? |
| Documentation/backups | Current copy available to business | Has recovery been tested, and can another provider use it? |
Domain ownership
The domain should normally be registered in an account controlled by the business, with accurate registrant details, recovery email, multi-factor authentication, and documented renewal responsibility.
A developer can help configure DNS, but that does not require permanent ownership. If the domain is currently inside a developer or agency account, agree how it can be transferred and whether provider lock periods apply.
Hosting, cloud, and deployment accounts
The business should know where the website runs, what the plan costs, who can log in, how billing works, and how the site can be moved. For cloud platforms, record projects, organizations, roles, environment variables, deployment settings, and spending controls.
Do not share passwords in a document. Use provider roles, a password manager, and an access-removal process.
Source code and repository
The contract should explain whether the client receives a repository, source archive, compiled build, custom theme, custom plugin, database schema, or platform configuration. It should also identify reusable libraries, open-source dependencies, and licensed components that are not exclusively transferred.
Receiving code is not enough. The handover should include the current branch or release, setup instructions, deployment process, environment requirements, and known limitations.
Content, design, and media
Clarify ownership or license for copy, translations, logos, photographs, video, illustrations, fonts, icons, stock assets, templates, and design files. A stock image license or premium font may allow use without allowing unrestricted redistribution.
The client should receive approved final content and understand where editable source files exist.
WordPress themes and plugin licenses
For WordPress, ask whether themes and plugins are free, client-owned, developer-licensed, or agency-licensed. Record renewal dates and what happens when a license ends. The site may keep working but lose updates, support, templates, or cloud features.
A developer license is not automatically wrong, but the dependency must be visible and a transfer or replacement plan should exist.
Analytics, Search Console, tags, and advertising
The business should own or have administrator access to:
- Google Analytics and Tag Manager.
- Google Search Console and Bing Webmaster Tools.
- Advertising pixels and conversion accounts.
- Consent-management and cookie tools.
- Call tracking, CRM, email marketing, and form-routing services.
Ask the developer to document what events are tracked and verify that old personal or test accounts are removed.
Business email and transactional messages
Record the provider, administrator, domains, DNS records, sender identities, recovery methods, and billing. Website forms and ecommerce messages may use separate SMTP or transactional-email providers that also need client-controlled access.
Customer data and privacy
The client should understand where enquiries, orders, accounts, uploads, and logs are stored; who can access them; how long they are retained; and how they are exported or deleted. Agreements with hosting, analytics, payment, CRM, and email providers may carry separate privacy obligations.
Remove unnecessary developer access after the warranty or maintenance role ends.
Backups and recovery
A handover is incomplete if nobody knows whether backups can be restored. Document backup location, frequency, retention, encryption where relevant, account owner, and the last restore test.
Also record how to roll back a failed deployment and who is responsible for recovery.
Put the transfer terms in the contract
The agreement should identify pre-existing supplier materials, new project work, client materials, open-source dependencies, and third-party services. For each category, state whether rights are assigned, licensed, or excluded; when any transfer takes effect; and what happens if the project ends before completion.
Also record:
- Whether final payment, acceptance, or another event triggers delivery or rights transfer.
- The client’s right to modify the delivered work or appoint another supplier.
- Confidentiality and permitted portfolio use of the client’s name, screenshots, or results.
- Responsibility for obtaining rights from employees, subcontractors, writers, and photographers.
- Any geographic, duration, seat, domain, traffic, or redistribution restriction.
- The export and handover obligations on termination.
Specific legal wording depends on the jurisdiction and contract. The operational goal is simpler: the business should understand what it can use, change, move, renew, and give to a replacement provider.
Transfer access securely
Do not send one shared password spreadsheet. Create named user accounts, enable multi-factor authentication, use provider roles, and store recovery information in a business-controlled password manager. Transfer ownership or billing first, verify the client’s administrator access, and only then reduce or remove supplier privileges according to the support agreement.
For secrets such as API keys and deployment tokens, rotate credentials that were shared broadly or stored in temporary channels. Confirm that former staging sites, test users, local database copies, and old deployment integrations are removed or retained only for a documented reason.
Use a staged handover instead of one final email
Handover should begin during the project:
- Kickoff: create the account register and establish client-owned domain, hosting, analytics, repository, and provider organizations where practical.
- Development: grant the supplier scoped access; document dependencies, licenses, environments, and key decisions as they are introduced.
- Pre-launch: verify administrator access, backup, deployment, DNS, email, analytics, payment, redirects, and recovery ownership.
- Training: demonstrate routine content editing, user management, form or order handling, updates covered by the agreement, and how to request support.
- Acceptance: deliver the agreed source, content, exports, documentation, known-issue list, and current credential/access register.
- Closeout: rotate secrets where needed and remove access that is not covered by active maintenance.
This approach exposes account problems before the launch or final payment becomes urgent.
Test whether the handover is actually usable
A client representative should be able to log in through the normal recovery route, update agreed content, receive a form or complete a test order, view analytics, locate backups, and identify how production is deployed. The business does not need to become its own developer, but it should be able to operate the promised editing workflow and appoint qualified help.
Ask a person who did not build the website to follow the documentation. Missing prerequisites and assumed knowledge appear quickly. Record any privileged step that still depends on the supplier and decide whether that is an intentional support service or an incomplete handover.
Understand platform limits before choosing convenience
Hosted builders and software-as-a-service platforms can be appropriate, but account ownership does not mean the underlying platform can be exported as source code. Some systems export content only; others provide limited templates or no portable application at all. Record what can be exported, in which format, and what stops working when the subscription ends.
The same applies to developer-owned multisite hosting or unlimited plugin licenses. Lower shared cost may be useful, but the exit path, migration responsibility, renewal effect, and replacement cost must be known before relying on it.
Plan for the provider becoming unavailable
The continuity test is practical: can another qualified person locate the current code, identify production, restore data, renew the domain, manage DNS, understand integrations, and contact critical providers? If not, document the missing piece while the relationship is healthy.
For an operationally important website, keep an emergency contact list, recent restore-tested backup, deployment instructions, provider billing visibility, and a record of expiring certificates or licenses. A recovery drill can be limited and controlled; it does not require taking production offline.
Final handover checklist
- Domain registrar and DNS access.
- Hosting or cloud access and billing.
- Repository, source files, database, and deployment notes.
- CMS administrator and editorial roles.
- Content, design, media, and license inventory.
- Analytics, Search Console, tags, CRM, and email providers.
- Payment, shipping, maps, booking, and API accounts.
- Backup status, restore instructions, and monitoring.
- Known issues, warranty period, maintenance terms, and emergency contact process.
Use the questions to ask a web developer before selecting a provider and the website quotation request template to make ownership part of the original scope.
Frequently asked questions
Does paying for a website automatically transfer copyright?
Not in every contract or jurisdiction. The agreement should state what is assigned, licensed, reused, open source, or controlled by a third party.
Should the developer keep administrator access?
Only when needed for an active support role. Use individual accounts, least privilege, multi-factor authentication, and a process for removing access.
Who should own Google Search Console?
The business should control the verified property and grant appropriate access to developers or SEO providers.
What if a premium plugin uses the developer’s license?
Document the dependency, renewal and support effect, and a transfer or replacement option. Do not discover it only after updates stop.
