Who owns your website? The domain, code, content and accounts explained

Your business owns its website only if its agreements give it the necessary rights and its people can access the accounts that keep the site running. Paying the invoice is not enough to answer the question. Check the domain registration, DNS, hosting, source code or builder account, content, analytics, email, integrations and customer data separately. You may control some and merely license others—and that can be perfectly workable if the arrangement is clear.

A website is several assets, not one

What we call “the website” is really a group of connected things:

The domain is the address people type.
DNS tells browsers where the site lives and tells email services where to deliver mail.
The host or website builder runs the site.
The source code, theme or platform configuration determines how it works.
The copy, photography and other media fill it with substance.
Analytics, Search Console, email and integrations connect it to the rest of the business.
Customer data may sit in forms, a store, a booking tool, a CRM or several of them at once.

Those assets can have different owners and license terms. A photographer may license the images while a hosted platform runs the site and your business controls the domain. That can work perfectly well when it is clear. The problem is finding out only when you need to leave.

Ownership, contractual rights and account control are different

These three ideas are often collapsed into one:

Legal ownership concerns rights in an asset. In the United States, copyright generally begins with the author of an original work once it is fixed. Employment, a qualifying work-made-for-hire arrangement or a written transfer can change that, according to the U.S. Copyright Office’s overview of copyright ownership.

Contractual rights are the permissions and promises in your agreement. A contract may transfer custom code, grant a broad license, reserve a developer’s reusable tools or tie the site to a subscription. “You own the website” is less useful than a clause naming the code, design, content, data and handover terms.

Practical control is whether your business can sign in, reset passwords, change billing, invite a new provider and export what matters. Strong contractual rights still leave a recovery problem if every account belongs to a former developer.

This article is general information, not legal advice. Ownership can turn on the agreement, how the work was created and the law that applies. If money, intellectual property or access is disputed, have a qualified attorney review the actual documents.

The website ownership table

Asset	Who should control it	How to verify	What to request
Domain registration	Your business, in a business-controlled registrar account	Sign in and confirm the domain, renewal method, recovery email and registered name holder details	Account access, current contact details and transfer instructions
DNS	Your business or a provider account from which you can grant and revoke access	Find where the nameservers point and who can edit DNS records	A DNS record export and an explanation of the records used for web and email
Hosting or builder	Your business as owner or primary administrator; provider as an invited user where possible	Open billing, users, plan and site settings	Admin access, billing history, backup and cancellation or migration terms
Source code or platform access	Your business should receive the rights promised in the contract and enough access to continue operating	Locate the code repository, downloadable theme or builder ownership screen	Current source, build instructions, license list and any export limitations
Content and photography	Your business should own or hold documented, continuing rights to everything published	Review the contract, original files and stock or photographer licenses	Editable originals, final files, usage licenses and attribution requirements
Analytics and Search Console	A company-controlled account should be owner or administrator	Check the users and permissions screen in each product	Owner or administrator access and removal of obsolete users after handover
Email	Your business should control the email tenant, billing and recovery methods	Sign in as administrator and identify the provider and all active users	Admin access, mailbox list, aliases, DNS records and migration support
Third-party integrations	Your business should own the vendor accounts and payment relationships	Inventory forms, CRM, booking, payments, chat, maps and automation tools	Admin access, account list, costs, data flows and a plan to rotate secret keys
Customer data	Your business should be able to access and export it, subject to contracts and applicable obligations	Submit a test form or order and trace where the record appears	A usable export, field definitions, backup details and deletion or retention process

The ideal pattern is simple: the business owns the account and invites the provider with the access needed to do the work. That keeps day-to-day management convenient without making one outside person the only route back in.

The five-minute ownership check

You do not need to change a single technical setting for this check.

Look up the domain. Enter it in ICANN Lookup. ICANN now uses RDAP for current generic-domain registration data. Note the registrar, status, nameservers and expiration date. Contact details may be nonpublic, so a redacted name is not proof that nobody owns it.
Find the registrar login. Search the company inbox, password manager and card statements for the registrar’s name. Sign in and confirm that a current company email can reset the password, renewal is on, and multifactor authentication is available. Do not edit DNS while checking.
Find the website account. Identify the host, CMS or builder. Can someone at the business reach its users, billing, backups and export settings? If the answer is “only our designer can,” write that down as an access gap.
Check Google access. In Search Console, open Settings → Users and permissions and confirm that a company account is an owner; Google defines the roles in its Search Console permissions guide. In Google Analytics, confirm that the business is an administrator using Analytics access management.
Ask for a one-page asset list. Send your provider the table above and ask them to name the account, account owner, billing owner and exit method for each row. A good provider should be able to answer without drama.

Who owns my website domain?

A domain registration is not the site, hosting or email. It is the renewable right to use an address under the registrar’s agreement. ICANN uses registrant, domain name holder and registered name holder. The holder details and registrar account should point to your business, not an agency employee.

Public lookup data is only a starting point. The registrar account shows recovery, renewal, locks and users even when public details are hidden. If a provider registered the domain, ask for it to be moved into a business-controlled account.

Do not confuse moving the website with transferring the domain. You can point DNS to a new host while leaving the domain at the same registrar. If you do transfer it to another registrar, ICANN says the current registrar supplies an Auth-Code—also called an authorization, AuthInfo or transfer code—and generally must provide it within five calendar days of a request, subject to the transfer rules described in ICANN’s domain-transfer FAQ.

Treat DNS carefully because the same zone often routes both the website and company email. A rushed change can move the site and accidentally stop mail.

Do I own my website code and content?

Maybe. The invoice alone does not settle it.

For custom code, read the ownership and license clauses. Check when rights transfer, what happens to pre-existing tools, and which third-party or open-source components keep their own licenses. You need clear rights to operate, modify and move the finished site, plus the files and instructions to do it.

Content is another set of rights. Employee work, commissioned copy, customer-supplied text, stock media and original photography may have different terms. Ask for editable originals and license records, not images downloaded from the live page. Keep any signed assignment of new copy or design work with the project archive.

Customer data is different again. Ask who can see it, where it is stored, which vendors receive it, how it exports and what happens at cancellation. Privacy, retention and deletion duties depend on the data, agreements and applicable law; get professional advice where needed.

Hosted-builder lock-in, explained fairly

Wix, Squarespace and Shopify are legitimate hosted products. They bundle software, hosting, security, updates and support. For many businesses, that is a sensible trade: less maintenance in exchange for dependence on the platform.

Dependence is not the same as misconduct. It does mean “export” may not reproduce the same site elsewhere. Wix explains that Wix sites use its technology and must run on its servers, while the customer’s content remains the customer’s. Squarespace documents a WordPress-format export for certain content, but not every page type, style or feature. Shopify’s backup guidance covers exports for several kinds of store data and a downloadable theme, while noting that some settings, apps and content still require manual rebuilding.

Ask two questions: “Can I take my content and data?” and “Can I run this exact site elsewhere?” Yes to the first and no to the second can be reasonable for a straightforward site. Our template-versus-custom explanation covers when the trade starts to matter.

What to request before hiring a web provider

Get the exit terms before the entrance becomes exciting. A proposal or contract should state:

Who registers the domain, in whose account, and who pays renewals.
Who owns newly created code, copy, design and media after payment.
What is licensed rather than transferred, including themes, fonts, stock media, plugins and reusable code.
Which accounts the business will own and what access the provider will receive.
Whether you receive the source repository, design files, content export, database export and documentation.
What hosting, maintenance, software and license costs recur.
How cancellation works, how long a handover takes and whether there is an export or migration fee.
How customer data, backups and confidential credentials are handled at the end.

A fixed scope should name exclusions as clearly as deliverables. CMT’s services include the full source at launch, and its pricing approach separates the build from optional hosting and SEO. Ask any provider for that specificity in writing.

What a clean website handover should contain

A clean handover is a usable package, not a zip file with no explanation. It should include:

Domain registrar and DNS access, renewal details and a current DNS export.
Hosting or builder ownership, billing access and a recent verified backup.
Launched source code, repository access and build and deployment instructions.
CMS access, content export, original media and relevant licenses.
Analytics, Tag Manager and Search Console access for a company-controlled account.
Email provider details, administrator access, mailbox and alias lists, and mail-related DNS records.
A list of forms, payments, booking tools, CRM connections and plugins, including who pays each bill.
A customer-data export with enough field information for another provider to use it.
A private credential-transfer method and a plan to rotate passwords and secret keys.
Known issues, renewal dates and the name of the person responsible for each service.

Test the package before declaring the handover complete. A new provider should be able to build or open the site, restore a backup, submit a form and identify where the result went.

If your web developer has disappeared

Do not cancel services or start changing DNS at random. First, preserve what still works.

Secure company-controlled accounts, update recovery methods and download backups or exports. Use ICANN Lookup to find the registrar. Search email and card statements for hosting, builder and license charges. Save the contract, invoices and messages. Have an independent developer inventory the site and remaining access before choosing recovery, migration or a rebuild.

If the missing developer controls the domain or refuses access, keep the issue factual and make written requests that name the exact account or asset. The registrar or platform may have an account-recovery process, but it will ask for evidence. If contractual or intellectual-property rights are disputed, speak with qualified counsel rather than trying to force access yourself.

Move the site without breaking the business

A safe transfer has an order: inventory accounts, copy files and data, build on the new host, test forms and integrations, preserve email records, prepare redirects, switch DNS, monitor, then cancel the old service. Transfer the domain registrar only for a reason; it is separate from moving the site.

The goal is not to remove every provider from every account. It is to make sure the business can see the arrangement, authorize changes and replace a provider without losing its address, records or ability to communicate.

CMT Web puts that principle in plain terms: the domain sits in the client’s registrar account, the full source is handed over, the content belongs to the client, and managed hosting is optional and month to month. If you are unsure what you control today, ask CMT for a straight assessment. You will get an honest read whether or not a project follows.