Notes
Who owns your website? Go asset by asset.
Almost every ownership dispute starts the same way: everyone assumed "the website" was a single object with a single owner. It never is.
Ask a business owner who owns their website and you usually get a confident answer. Ask them who the domain is registered to, which account the DNS is served from, and where the source code lives, and the confidence tends to go. Those are three different answers, they can be three different companies, and the first one is the one that decides everything else.
This is not usually malice. It is what happens when one party thinks in terms of a deliverable and the other thinks in terms of accounts. You bought a website. They built one, on infrastructure they already had, using logins they already held, because that was the fastest way to get you live. Nobody lied. The ownership question simply never came up in a form specific enough to answer.
So make it specific. Below is every asset that makes up what you call your website, what it actually controls, and the exact way to check who holds it. Work through it in order. It takes about an hour and you will know more about your own web presence than most owners ever do.
The one test that settles it
Before the list, the test that cuts through every argument about this: can you remove their access without asking them?
If you can log into an account and delete their user, you own that asset. If you have a login but they are the account owner, you have access, which is a different and much weaker thing. Access can be revoked by the person who granted it. Ownership cannot. An agency saying "you have full access to everything" is answering a question you did not ask.
The assets, in order of how much damage losing them does
| Asset | What it actually controls | How to check |
|---|---|---|
| Domain registration | Everything. Whoever controls the domain controls where the site resolves and where your email is delivered. This is the root of the tree. | Look up your domain on a public WHOIS or RDAP service and read the registrar. Then log into that registrar directly and confirm the account is in your name and your billing. |
| DNS | Where each hostname points, and every email record. DNS can live somewhere other than your registrar, which surprises people. | Check your domain’s nameservers. Whichever service they point at is where DNS is really managed. Confirm you can log in there and see the records. |
| Hosting or server | Whether the site is on, and whether you can move it. Also whether you are one late invoice away from it being off. | Identify the account the hosting is billed to. If the invoice goes to your developer and not to you, the account is theirs. |
| Source code | Whether anyone else can ever work on the site. Without the code, a redesign is a rebuild. | Ask which repository holds it and confirm your organisation owns that repository, not just that you were added to it. |
| CMS or admin login | Day-to-day content, and whether you can change a phone number without opening a ticket. | Log in and check your own role. If you are not the top-level administrator, you are a guest on your own site. |
| Analytics | Your traffic history. It does not transfer with the site and it cannot be reconstructed. | Open the property’s admin settings and read the account it belongs to. Years of data have been lost this way. |
| Google Business Profile | Your local search presence, reviews and map listing. Often more commercially valuable than the site. | Check the profile’s owner and managers. An agency should be a manager, never the owner. |
| Every conversation your business has. Frequently tied to the same DNS someone else controls. | Confirm who administers the mail service and who controls the MX records pointing at it. | |
| Third-party keys | Payments, maps, mail delivery, anything the site calls out to. Each one is a separate account with a separate owner. | List every integration and identify whose account each key was issued from. |
Start with the domain, always
If you only do one item on that list, do the first one. The domain is the root asset, and control of it is the thing that makes every other problem either annoying or fatal.
Lose the code and you can rebuild the site. Lose the hosting and you can move it somewhere else. Lose the domain and your customers cannot find you, your email stops arriving, and the search rankings you spent years earning are attached to an address you no longer hold. There is no technical fix for it. It becomes a legal problem, and legal problems are slow.
A registration in your own account, with your own billing, is not a favour to ask for. It costs about the price of a sandwich per year and it is the difference between a dispute and a catastrophe.
The part where a lawyer matters and we do not
Everything above is operational. Who holds which account is a question of fact, and you can establish it yourself this afternoon.
Copyright in the code and design is a separate question and a legal one. In the United States, work created by someone who is not your employee generally belongs to whoever created it unless there is a written assignment, and paying an invoice is not by itself an assignment. What that means for your specific contract is a question for an actual attorney, and anyone who answers it confidently in a blog post, including this one, is guessing about your situation.
The practical consequence is simple enough to act on: get the assignment in writing at the start, when everyone is friendly and it costs nothing, rather than at the end, when it is the only leverage either side has left.
What good looks like
- The domain is registered in an account you opened, billed to your card.
- DNS is somewhere you can log into and edit today.
- Hosting is billed to you, and you can add or remove collaborators.
- The source code sits in a repository your business owns, with your developer added as a collaborator rather than the other way round.
- You are the top-level administrator on the CMS, the analytics property and the business profile.
- A written agreement assigns you the copyright in the work.
- None of this required a conversation, because it was set up this way from the first day.
That last point is the whole thing. Accounts opened in your name at the start are a fact. A promise to transfer them at the end is a promise, and you find out which one you have on the worst possible day.
Questions
Does paying for a website mean I own it?
Not automatically, and the two halves of the question have different answers. The accounts, which is to say the domain, hosting, analytics and everything else, are owned by whoever the account is registered to, regardless of who paid. The copyright in the code and design usually stays with whoever created it unless a written agreement assigns it to you. Paying an invoice is evidence of a transaction, not a transfer of ownership.
My agency says I have full access. Is that the same as owning it?
No. Access means they have let you in and can let you back out. Ownership means you can remove them. The practical test is whether you are able to delete their user account without asking anyone. If you cannot, you have access.
What is the single most important asset to control?
The domain registration. Everything else can be rebuilt or moved. Losing the domain takes down your site and your email at the same time and turns a technical problem into a legal one.
Should my agency own my Google Business Profile?
No. They should be added as a manager, which lets them do the work, while ownership stays with the business. Your reviews and local presence live there and it is often worth more commercially than the website.
How long does it take to audit all of this?
About an hour if you have the logins, and finding out that you do not have them is itself the result. Work down the list in order and write the answers somewhere permanent.