Who Actually Owns Your Website?
Most business owners assume they own their website because they paid for it. Ownership is five separate things, and it is common to hold none of them. Here is how to find out where you stand.
Published
Nobody asks this question until the day it matters, and by then the answer is expensive. The developer stops responding. The agency gets acquired. The nephew who built it graduates and moves. Prices go up and you want to leave.
That is the moment business owners discover that paying for a website and owning one are different things. Ownership is not a single item — it is five, they are held separately, and it is entirely possible to have paid for a site every month for six years and control none of them.
The five things, and who usually holds them
The domain name. This is the one that matters most and the one most often held by someone else. If your domain is registered in your web person's account, they control your web address and your email — and if the relationship ends badly, or they simply vanish, you are dealing with a registrar's dispute process rather than a business decision. It is also the single most common cause of a total outage, because renewal notices go to an address nobody reads: see what actually happens when a website goes down. Your domain should be registered in an account you control, with your email, your credit card, and your recovery method.
The DNS. Slightly separate from the domain: the settings that point your address at your website and your email. Whoever controls DNS can redirect either. It usually sits wherever the domain sits, which is why the first item matters twice.
The code. The actual files that make up the site. On a page-builder platform there is no meaningful answer — the site exists only inside that vendor's system and cannot leave, which is a permanent rental. On a custom build, the question is whether you have the repository and whether it is complete enough to hand to a different developer and have them continue.
The content. Your text, photos, video. If a photographer or copywriter was involved, check what the contract actually licensed. Photography in particular is often licensed for a specific use rather than transferred, and businesses discover this when they try to reuse images on a new site.
The accounts. Google Business Profile, Google Analytics, Search Console, the form endpoint, the hosting. Each is a separate login and each is commonly created by the vendor under their own account for convenience. Analytics history in particular is not portable — lose the account and you lose years of data you cannot reconstruct.
What a hostage situation looks like
It is rarely dramatic and almost never involves anyone saying the word hostage. It looks like this: you want to make a change, the vendor is slow, you get a quote from someone else, and the new developer asks for access. Then the questions start. Where is the domain registered? Who has the repository? Is there a repository? What is the hosting login?
And the answers are: nobody knows, the previous developer, unclear, and an email address at a company that no longer exists.
At that point your options are to pay whatever the incumbent asks, or to rebuild from scratch and rebuild your search equity along with it. Neither is a negotiation you entered voluntarily. The leverage was established years earlier, in a decision nobody thought of as a decision.
The uncomfortable part is that this usually is not malice. Most web people set things up under their own accounts because it is faster, and then never got around to transferring anything. The outcome is the same either way.
The audit, which takes about twenty minutes
Go to any WHOIS lookup and enter your domain. See what registrar it sits with, then confirm you can actually log into that registrar and see the domain in your own account. Not that someone told you it is yours — that you can log in right now.
Then work down the list. Can you log into your hosting? Do you have the repository, or at minimum a current export of the site files? Are you the owner — not a manager, the owner — of your Google Business Profile, Analytics, and Search Console? Where do contact form submissions actually go, and who controls that endpoint? Do you have written confirmation of what you own from whoever built the site?
Anything you cannot personally verify, you do not control. That is not cynicism, it is just the practical definition. If regaining access would require someone else's cooperation, then that access is theirs and it is on loan.
Fixing it before you need to
Every one of these is straightforward to correct while the relationship is good and nearly impossible once it is not. Move the domain into your own registrar account. Get added as owner on every Google property. Get a copy of the site files or repository access in writing. Confirm in writing what happens to all of it if you part ways.
A competent vendor will do all of this without friction, because they know it costs them nothing and it is the professional arrangement. A vendor who becomes evasive when you ask to hold your own domain has told you something more useful than anything on their website.
This is the arrangement we build with by default: clients hold the Git repository for their site outright — every file, every change, full history — so leaving means leaving with the asset rather than with nothing. The terms are stated openly on our pricing page rather than buried in an agreement, because it is one of the few contract questions where vagueness is always in the vendor's favor.
None of this means you should manage your own website. Most business owners should not, and outsourcing the work entirely is a reasonable and often correct decision. The distinction is between delegating the work and surrendering the asset. You can hand someone the keys to the building without signing over the deed — and if you are about to hire someone, these are the questions to ask first.