Who owns my website when I pay an agency to build it?

Three things get confused under one word. They transfer by different mechanisms and they fail separately: the copyright in the code, design and copy; the domain name; and the hosting, analytics, DNS and repository accounts.

The copyright line is the one that surprises people. "Work made for hire" has two branches: work prepared by an employee within the scope of employment, and work specially ordered or commissioned that falls into one of nine enumerated categories — a contribution to a collective work, part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, or an atlas.

A website does not fit cleanly into any of them — and that is the honest phrasing, because the second branch also requires a signed written agreement, and agencies do argue that a site is a "compilation" or an "audiovisual work". If the argument ever matters to you, it matters in front of a lawyer, not in a proposal.

So an agency that is not your employee is the author of what it makes, and paying an invoice is not a transfer. A transfer of copyright ownership has to be in writing and signed by the owner. The practical test for your own contract: search it for the word "assign". "You own your website" in a proposal is marketing. An assignment clause naming the deliverables and signed by the agency is the thing that moves the copyright.

Ask for all three by name, in writing, before the build starts. An agency that will give you the first and not the third has given you a site you cannot deploy.

A domain is not owned by whoever built the site. It is held by the registered name holder on record at the registrar, and ICANN is explicit that the registrant is entitled to the contact data on the registration and to move the registration to another registrar.

Two mechanics to know before you need them, both governed by the ICANN Transfer Policy, which all accredited registrars have been required to comply with since 1 December 2016.

First, you are entitled to the code that moves it. The policy requires a registrar to provide facilities for the Registered Name Holder to generate and manage their own AuthInfo code and to remove the clientTransferProhibited status. A registrar that will not give you an auth code is not enforcing a rule, it is breaking one.

Second, three sixty-day windows, and the third is optional. The policy names them as grounds on which a transfer must or may be denied: the first sixty days of initial registration, the first sixty days after a registrar transfer, and a sixty-day lock following a Change of Registrant. The policy states that third one applies where "the Registered Name Holder did not opt out of the 60-day inter-registrar transfer lock prior to the Change of Registrant request." So it is declinable, in advance, and only in advance — which means the moment to think about it is when ownership is being corrected, not afterwards.

The consequence is operational rather than legal: a domain you discover you do not control is a domain you cannot move this week. Check the registrant field while nothing is wrong.

It depends entirely on which of the three records the agency holds, and nothing about the answer is decided at the moment you stop paying. It was decided when you signed.

The site goes dark. The agency owns the hosting account and the domain. Stopping payment stops the hosting invoice, and the site and email stop with it. There is nothing to re-register, because the domain was never yours. Recovery is a negotiation.

Or the site stays up and you cannot change it. You hold the domain, the agency holds the codebase and the repository. The site serves until something breaks, and then nobody can fix it.

Or you get an export you cannot use. A "copy of your site" from a proprietary builder is often a zip of rendered HTML, not the source. It is evidence the site existed, not a site.

Or everything is in your accounts and you change a DNS record. This is the whole objective, and it is a contract term, not a favor.

Two things to put in the contract rather than hope for. A termination clause that names the handover: source code, database dump, DNS access, and a written assignment effective on final payment. And ownership of the analytics and Search Console properties, because a site that moves without its measurement history arrives with no baseline to be judged against.

If you do leave and the site is rebuilt elsewhere, the URLs are the thing to protect. Google’s guidance on site moves with URL changes is that old addresses should redirect to their new equivalents — which is also why "we will just rebuild it" is a plan that needs the old URL list in hand before the old site disappears.

This is how the statute and the policies read; it is not legal advice, and a contract question is a question for a lawyer.