Who Owns Your Website? Domains, Hosting, and Accounts Explained

TL;DR: Website ownership splits into five layers, and you own your website only when your own business holds all five: the domain registrant record, the DNS zone, the hosting account, the connected services such as analytics and forms, and the intellectual property in the design files and custom code. Paying an invoice creates none of them.

• Layer 1 is the domain registration, held at an ICANN-accredited registrar such as Cloudflare, GoDaddy or Namecheap.
• Layer 2 is the DNS zone, which decides where the domain points and often sits at a different company from the registrar.
• Layer 3 is the hosting account that serves the pages, including whichever plan the site runs on.
• Layer 4 is the connected services: Google Analytics 4, Google Search Console, form notifications, transactional email and any booking or payment tool.
• Layer 5 is intellectual property, meaning the design source files and custom code, governed by contract wording rather than by a login.

What does it actually mean to own a website?

Owning a website means your business is the named account holder on every asset the live site depends on, rather than the party paying for them. Ownership is an account-and-contract question, not a technical one.

A business can hold four of the five layers and still be exposed by the fifth. On the client projects I lead, the first document I produce is a one-page ownership map naming the account holder for each layer, written before any build work starts. If nobody at your company can name all five holders, start there, and use my website project checklist for what to gather before a build begins.

Why is the domain registrant record the asset that matters most?

The domain registrant record matters most because it sits above everything else: whoever is listed as registrant can repoint the domain, and repointing the domain moves both the website and the company email. Why domain and DNS entries belong at the top of a delivery checklist is covered in my post on the Webflow handoff package; what follows is the registrar policy layer underneath it.

ICANN's Transfer Policy adds a practical trap. Since 1 December 2016, registrars must impose a lock preventing transfer to another registrar for 60 days following a change to a registrant's information, covering registrant name, registrant organization, registrant email and the administrative email where no registrant email exists. Registrars may offer an opt-out, but ICANN does not require them to.

The failure mode I see most often on rescue projects is a domain whose registrant email is an agency address that no longer receives mail. Renewal notices and transfer approvals then go to a mailbox nobody reads, and the business discovers it when the site goes dark. If you are correcting a registrant record and changing registrars in the same project, request the registrar transfer first and change the registrant details afterwards, so the 60-day lock does not strand you mid-migration.

How long do I have to recover an expired domain?

An expired generic top-level domain is not lost instantly, but the recovery windows set by ICANN's Expired Registration Recovery Policy are short, and each one is either optional or fee-bearing. Registrars must send at least two renewal reminders before expiry, roughly one month and roughly one week beforehand, which is exactly why a stale registrant email is so damaging.

Recovery window	Length	Who must provide it, and under what
Auto Renew Grace Period after expiry	1 to 45 days	Optional. ICANN states a registrar "may offer" it (ICANN registrant guidance)
Redemption Grace Period after deletion	30 days	Mandatory for all gTLD registries except sponsored gTLD registries (ERRP 3.1)
DNS interruption before deletion	At least the last 8 consecutive days	Mandatory for registrars (ERRP 2.2.3)

The rule I give clients on top of those windows is to set a calendar reminder 60 days before the domain expiry date, owned by a named person rather than a shared inbox, because the ICANN-mandated reminders land in whichever mailbox the registrant record names, and that is the field most likely to be out of date.

Does paying the hosting bill make you the owner?

Paying the hosting bill does not make you the owner of the hosting account, because billing and account ownership are configured separately on every major platform. An invoice proves who paid; the account record proves who controls the site.

Webflow is the clearest example of that gap, and I have covered how its billing and ownership arrangements differ in my guides to Webflow client handoff and transferring a Webflow site to a client. What I see agencies get wrong is treating a paid invoice as a handover. If your business needs the site under its own account rather than just the bill in its name, put the account transfer in the contract with a date attached.

Which accounts should be in your name before launch?

Every account a website depends on should be created under a business-controlled email address, ideally a shared alias such as domains@yourcompany.com rather than one employee's inbox. The rule I apply on every build is that the client creates the account and invites me, never the reverse.

Asset	Who should hold the account	What breaks if they do not
Domain registrar and registrant record	Client	Website and email can be repointed by someone else
DNS zone	Client	Traffic can be redirected without the client's consent
Hosting account	Client, or agency with a written transfer date	Site goes offline if the agency relationship ends
Analytics and Search Console	Client	Historical traffic data is lost and cannot be recreated
Form notifications and transactional email	Client	Leads keep arriving in an inbox nobody monitors
Design source files and custom code	Client, by written assignment	Rebuilds and redesigns start from zero

Checking who currently holds each of those takes about ten minutes. Public domain lookups will not settle it alone, because registrant contact details are redacted in most public results for privacy reasons, so the first check is a login rather than a search.

• Log in to the registrar account and read the registrant contact directly. If nobody at your company can log in, that is the answer.
• Run a lookup at ICANN Lookup to confirm which registrar holds the domain and when it expires, then compare it to the account you just opened.
• Check the nameservers: whoever controls the account they belong to controls the DNS zone, and it is frequently a different company from the registrar.
• Open the hosting account and confirm which organisation the site sits under, and separately who the billing contact is, because those two can differ.
• Open each analytics property's admin settings and confirm a business email address has administrator access, not viewer access.

What should the ownership clause in your contract say?

An ownership clause should name each asset explicitly and state when title passes, because a contract that only says "the client owns the website" leaves design files, custom code and third-party accounts undefined. Payment alone does not assign intellectual property in most jurisdictions, which is why the clause below sits alongside the deliverables list rather than in boilerplate.

• An explicit assignment of design files and custom code to the client, effective on final payment.
• A named list of accounts that must be in the client's name at launch, matching the ownership map above.
• A stated date or trigger for hosting account transfer, if the agency holds it during the build.
• A carve-out naming anything the agency retains, such as reusable component libraries or licensed third-party assets.
• A clause requiring the registrant contact on the domain to be a client-controlled address, not a project manager's inbox.

How agencies structure all of this when a third-party developer is involved is covered in my white label Webflow workflow guide.

What can you do if your developer will not hand over the domain?

If a developer or agency will not hand over a domain, the first route is the registrar rather than a lawyer, because the registrar holds the account and is bound by ICANN policy. Establishing that your business is the registered name holder is what unlocks everything else.

One provision is worth knowing first. ICANN's Transfer Policy states that a registrar must not refuse to remove a ClientTransferProhibited status or release an AuthInfo code to the registered name holder solely because of a payment dispute between that holder and the registrar. Read the scope carefully: it constrains a registrar over its own billing and does not settle a dispute between a business and its developer. Where a contractor is the registered name holder and will not cooperate, ICANN's Uniform Domain Name Dispute Resolution Policy covers abusive registrations such as cybersquatting rather than ordinary commercial disagreements, so a contract claim is usually the correct route.

Want your ownership map checked before your next launch?

If you are not sure who currently holds your domain, DNS, hosting and analytics accounts, book a 15-minute call and I will walk through your five layers on the call and name the ones that are exposed. You leave with a straight recommendation on what to move first and a fixed price if you want me to run the migration.