Do You Own Your Website? Three Questions

Ownership is three things, not one

Most arguments about this are two people discussing different questions. There are three, they are separable, and you can own any one of them without the others.

The domain name. The build: the code, the structure, the logic that makes it work. And the relationship: who holds the customer records, and whose name is on the payment account.

Work through them in that order. They get more expensive to fix as you go down.

One: whose name is on the domain?

Your domain should be registered in an account you can log into, in your name, with your email address as the admin contact.

If somebody set it up for you and it lives in their account, you do not have a supplier. You have a dependency who can take your website, your email and every link anyone has ever shared off the internet by not answering a message.

The check takes two minutes: try to log in to the registrar yourself. If you cannot, you do not control it. This is the cheapest item on the list to put right and by some distance the most expensive to ignore.

Two: if you left tomorrow, what could you take?

On a hosted site builder you are licensing a platform. Your words and pictures are yours, and most builders will let you export them in some form. The build is a different matter: the templates, the layout, the logic and the integrations exist inside that product, and they stop existing when you leave it.

That is not a scandal. It is what the deal says, and for a great many businesses it is a fair one.

The useful test is not "can I export my text". It is this: if that platform doubled its price next month, or closed, how long until you were trading normally again? If the honest answer is measured in weeks rather than days, you are renting. Which is fine, as long as you know.

Three: who does the customer belong to?

Two things to check, and both tend to surprise people.

Whose name is on the payment account. If a platform takes the money and pays you out, they hold the relationship with the customer and you hold a balance with them. If the account is in your name and the money lands in your bank, that is yours.

And where the customer list actually lives. If your customer records exist only inside a booking product, your customer list is a feature of somebody else’s software. Both are recoverable. Neither is recoverable quickly, and you will want them precisely when you are already having a bad month.

When none of this matters

If your website is a brochure, who you are, what you do and how to ring you, then the build is not carrying much. Rebuilding it somewhere else is a weekend. Renting is the right answer and anybody telling you otherwise is selling you something.

Put plainly: most businesses do not need to own their website. They need to own the part of it that takes money and holds customers.

When it matters a great deal

It changes the moment a system starts holding things that are expensive to recreate. A diary with real bookings in it. A customer list with history attached. Payment records. Anything carrying a compliance obligation, where being unable to produce a record is itself the problem.

Those are not design assets. They are business records, and who holds them is a commercial question rather than a technical one.

What owned actually looks like

• +The domain registered in your name, in an account you can log into today
• +The code in your possession, in a repository you control
• +Hosting and the payment account in your name and billed to you
• +Customer data you can export in a format something else can read, not a PDF
• +A written handover, so that owning it survives the person who built it

If you have all five, the question of who owns the website never comes up again, because the answer is obvious to everyone including you.