Skip to content

Who owns your website — and what to do if the person who built it stops answering?

Most people meet this question at the worst possible moment: the person who built the site has gone quiet, something needs changing, and nobody knows where anything lives. This guide is written for that moment first, and for the moment before it second — because almost everything that goes wrong here is decided by arrangements made before anyone thought to ask.

Updated:

In short

  • A website is not one thing you own. It is four: the domain, the code and design, the content, and the accounts everything runs in. They can each be held by a different party.
  • Start with the domain. It is the only piece that can be lost permanently, and losing it means losing your email as well.
  • Look at the public domain record first: it is free, and it often answers the question outright, because the registrant organisation is frequently published. If it comes back redacted, that proves nothing either way — then what settles it is who can log into the registrar account.
  • If your developer has stopped replying, work in this order: domain, then accounts, then a copy of the site. The site itself is the easiest part to recover.
  • “You will own the website” almost never means you own every part of it. The normal arrangement is that work made for you is assigned, and reusable components are licensed. Ask which is which before you sign.
  • The protection that works is not a promise that your supplier will still be here. It is standard technology, accounts in your name, and a contract that says what happens on the way out.

What exactly do you own when you own a website?

A website is four separately owned things: the domain name, the code and design, the content, and the accounts the site runs inside. Each can belong to a different party, and in a bad arrangement they usually do. When someone says “you own your website”, the useful follow-up is: which of these four, and evidenced how?

This split explains why two people can both be telling the truth in an argument about ownership. A developer who says "the site is yours, I just host it" and a client who says "I cannot get my site" are describing different rows of that table. Being specific about which row is in dispute usually resolves it faster than talking about ownership in the abstract.

The four parts of a website and who typically holds each one
PartWhat it isWho often ends up holding itWhat happens if you do not
The domainYour address, rented yearly from a registrarSometimes the agency's own registrar accountYou cannot move, and if it lapses you can lose it and your email with it
The code and designThe files the site is made ofThe builder, until a contract says otherwiseYou can be quoted a fee to receive what you paid for, or told it stays where it is
The contentYour text and photographsUsually you, if you wrote or took themStock images and commissioned photos carry their own licences that may not travel
The accountsHosting, DNS, analytics, search console, emailWhoever set them up, using their own email addressYou cannot grant access to a new supplier, or see your own data
The four parts of a website and who typically holds each one — The domain is first in this table on purpose: it is the only row where a delay can cost you something you cannot rebuild.

How do you check what you actually control today?

You can establish this yourself in about twenty minutes, without asking anyone and without spending anything. The test is not what the paperwork says but what you can log into. Work through the four parts in order and write down, for each one, whether you hold the login or somebody else does.

  1. 1 Look up the public record for your domain. What it shows depends on the ending. For .com and .net it names the registrar, and often the registrant organisation too — if that field carries an agency's name, your question is already answered. For .pl it names the registrar but not you. For .de the public whois service names nobody at all: you have to use DENIC's web lookup or ask whoever manages the domain. Where fields come back redacted, that is not evidence either way.
  2. 2 Try to log in to that registrar with your own email address, or use its password-reset. If the reset email does not arrive at an address you read, the account is not yours in the way that counts.
  3. 3 Check who controls DNS — the setting that decides where the domain points. It may be at the registrar or somewhere else entirely, and whoever holds it can move your site and your email.
  4. 4 Log in to the hosting account. If you have never seen it, ask for it in writing now, while relations are good, rather than at the moment you need it.
  5. 5 Check the analytics and search console properties. Both let you add yourself as an owner, and being an owner of your own measurement data is worth the five minutes.
  6. 6 Ask for a copy of the source files and note the answer. You are not necessarily entitled to them — that depends on your contract — but the way the question is received tells you a lot.

Checked against the source:

Your developer has stopped answering. What should you do this week?

Deal with the domain first, the accounts second, and the site itself last — which is the reverse of how it feels. The site is the part that panics you and the part that is easiest to reconstruct. The domain is the part you can lose for good, and the deadline is its renewal date, not the argument you are having.

One thing worth saying plainly: silence is usually not malice. Illness, a new full-time job, a business that quietly stopped trading — these account for most disappearances, and they are also why persistence with the registrar works better than escalation with the person.

  1. 1 Find the renewal date of the domain and put it in your calendar. If it is close, this is the only urgent item on the list.
  2. 2 Contact the registrar directly, not the developer. Registrars deal with lost access routinely and will tell you what proof of identity they need. This is a support request, not a legal dispute.
  3. 3 If the domain is registered to the developer rather than to you, ask in writing for a transfer and the authorisation code. Keep it factual and short; a written request also creates the record you would need later.
  4. 4 Save the site as it stands today: every page, the images at full size, and any text you would hate to rewrite. Everything visible on a public website can be copied by you right now.
  5. 5 Set up your own accounts for the things you do not control — hosting can be new, analytics can be a fresh property — rather than waiting for handover of the old ones.
  6. 6 Only then think about rebuilding. With the content saved and the domain safe, a small site is days of work, not a catastrophe.
  7. 7 If money is owed to the developer, expect that to come up, and take advice before withholding it. An unpaid invoice can be the reason your files are being held, and in many contracts that is legitimate.

Why does “you will own the website” almost never mean all of it?

Because a site built for you is not written from nothing. It sits on frameworks, components and design systems the studio reuses on every project, plus third-party fonts, plugins and photographs licensed from someone else. The normal arrangement — and a fair one — is that work created specifically for you is assigned to you, while reusable parts are licensed to you for use in that site. A supplier who promises you own literally everything is either being loose with words or is about to hand you something they cannot legally hand over.

The question that separates a fair arrangement from a trap is not "do I own it" but "can I take this site to another developer and keep operating it". If reusable components are licensed to you permanently for use in that site, the answer is yes and the arrangement is fine. If the licence ends when the relationship ends, or the site only runs on the supplier's own system, that is lock-in whatever the contract calls it.

  • Assigned to you: the design made for your brand, the text written for you, the code written for your specific site.
  • Licensed to you, not assigned: the studio's reusable components and tooling. A fair licence is permanent and lets you keep using and developing that site, including with a different developer.
  • Owned by third parties: fonts, stock photography, plugins and services. These come with their own terms, and subscriptions attached to them become yours to renew after handover.
  • Conditional in almost every contract: the transfer usually happens on final payment, not before. Until then the work is not yours to publish, and that is standard rather than sinister.

What should you agree in writing before you pay anyone?

Six things, and all of them fit in a short paragraph of a normal contract. None of this requires a lawyer to ask for, and a supplier's reaction to being asked is itself informative — these are ordinary questions with ordinary answers.

Notice what is not on this list: guarantees that the supplier will still be trading in three years. Nobody can give you one, and the ones who try are substituting reassurance for structure. What actually protects you is the six points above plus one more that is not contractual at all — that the site is built on widely-used technology a different developer can pick up without ceremony.

  • Whose name the domain is registered in, and who holds the registrar account. If the supplier registers it for you, state that it is registered in your name.
  • What is assigned to you and what is licensed, and that the licence is permanent and survives the end of the relationship.
  • What happens at handover: which accounts and files pass to you, when, and whether any fee applies. Vague wording here is where later arguments live.
  • Whether hosting is included, and what happens to the site if you stop paying for it. Included hosting is convenient and is also a tie; that is fine as long as you know the notice period.
  • Whether the supplier's credit appears in the footer, and on what terms it can be removed.
  • What the supplier may publish about the work. Most studio contracts, ours included, take a portfolio licence to your name, logo, screenshots and live address by default, with an opt-out you have to exercise in writing within a set window. That is normal, and it is also the one clause in this list written in the supplier's favour — which is exactly why it belongs on a list like this.

How does Soul Design handle this, including where we come off worse?

Our contract follows the structure described above rather than the marketing version of it, so here it is in plain terms, with the parts that are inconvenient for us included. If you want to read the whole thing before talking to us, ask and we will send the template.

Two things we do commit to in writing, because you should not have to take them on trust: any domain we register for you is registered in your name, not ours; and on full and final payment we hand over the delivered files and the accounts we opened for you, at no extra charge. Ask for both in the contract — from us, and from anyone else you are considering.

  • Rights in the work made for you — the design, the copy we wrote, your site's own code — transfer to you on full and final payment. Before that payment they are not yours to publish, which is standard.
  • Our reusable components stay ours, and you get a worldwide licence to use them as part of your site, for as long as the site exists. It is not exclusive and not yours to pass on separately, and you cannot lift those components out into another project — but nothing in it stops another developer from running and working on your site for you. It lasts from the moment the final payment clears; the one thing that revokes it is publishing the work before paying and then not paying.
  • Third-party licences — fonts, images, services — are obtained valid at handover. Renewing them afterwards is yours, and we give no warranty that any of them is perpetual, transferable to someone else, or free of further charge. The same caution applies to anything produced with AI tools: we can only pass on the rights we actually hold in it.
  • Where we come off worse, one: our contract allows a discreet “Designed by” credit in the footer, and removing it can carry a one-off fee. Ask about it before signing rather than after.
  • Where we come off worse, two: hosting is included in our care plans, so if you stop the plan you have to move the site elsewhere inside a migration window that runs from the end date — a separate period from the notice you give to cancel, set out in the agreement. Helping with that move is chargeable work like any other. It is a tie, however friendly, and you should count it as one.
  • Where we come off worse, three: if you go quiet, silence counts against you. Past the feedback window in the agreement a stage is treated as approved and invoiced, so the project keeps moving whether or not you looked. It keeps schedules honest; it also means an unread email can cost you a revision round.
  • Where we come off worse, four: the founding-client rate is conditional. It is granted in exchange for a short testimonial and permission to publish a case study, and if you decline after delivery the regular rate applies to the balance. That is in the agreement, and it is worth knowing before the discount does its work on you.
  • Where we come off worse, five: the deposit is not fully refundable. If you cancel mid-project we keep it only up to the work actually done and the costs already committed, and refund the rest — but “only up to” is doing real work in that sentence.
  • Where we come off worse, six: we are a new studio — the four sites in our portfolio are ours and our partners', not a decade of client work, and we started trading in 2026. If continuity matters more to you than anything else, an established agency is a reasonable thing to prefer, and we would rather you weighed that now than later.

Everything you might be wondering.

How do I find out who owns my domain name?
What a public lookup shows depends on the ending: for .com and .net it names the registrar and often the registrant organisation too, for .pl the registrar but not you, and for .de the public whois names nobody at all — there you need DENIC's web lookup. Where an organisation is shown and it is an agency, you have your answer. Many records are redacted instead, and that proves nothing either way. What settles it is who can log into the registrar account, so try a password reset to your own email address.
My web designer has disappeared. Can I lose my website?
The site itself, almost never — everything on a public page can be copied by you today. The domain, yes: if nobody renews it, it can lapse and be taken. Find the renewal date first, then contact the registrar directly, who will have a documented process for a registrant who has lost access.
Do I own the code if I paid for the website?
It depends on what you signed. In a normal contract the work made specifically for you is assigned to you on final payment, while reusable components and third-party parts are licensed. If your contract says nothing about assignment, the default in most of Europe is that copyright stays with the author.
The agency wants a fee to hand over my files. Is that allowed?
Often, yes — many contracts make handover conditional on full payment and allow a reasonable charge for the work of transferring accounts. Check whether that fee was actually agreed in writing and whether anything is genuinely unpaid before treating it as a dispute. If you bought as a consumer rather than as a business, a charge that was never agreed may not hold up in Germany or Poland.
Should the domain be registered in my name or my agency's?
Yours. There is no benefit to you in any other arrangement, and it removes the single worst failure mode in this whole topic. If an agency prefers to hold it, ask why, and treat a vague answer as an answer.
What happens to my website if I stop paying a monthly plan?
That depends entirely on what the plan covers. If it is maintenance, the site keeps running and stops being looked after. If hosting is included in the plan, the site goes offline unless you move it, so check the notice period before you sign rather than at the point you want to leave.
Can another developer take over a site somebody else built?
If it is built on widely-used technology and you hold the accounts, routinely. Where it gets difficult is a site running on a private system belonging to the previous supplier, or one where nobody can access the hosting. Both of those are decided long before the handover.
Is a contract really necessary for a small website?
For a small site the contract does not need to be long, but the six points in this guide should be written down somewhere. Most disputes in this field are not about bad faith; they are about two people who never wrote down what they each assumed.

Sources

  • ICANN — Registration Data Policy ↗ — The policy in force since 21 August 2025 for .com, .net and other generic endings, replacing the Interim Registration Data Policy, which ran until 20 August 2025. It sets which registration fields are published and which may be redacted. Country-code endings such as .pl and .de are outside it and follow NASK and DENIC instead.
  • ICANN — Registrants’ Benefits and Responsibilities ↗ — What a registrant is entitled to expect from an accredited registrar. ICANN publishes this as a plain-language summary of the registrar agreement, not as a procedure for recovering a lost account.
  • Soul Design — what a website really costs — The money side of the same decision, including what a site costs to keep over three years.

Stuck with a site you cannot get into?

Tell us what you can and cannot log into. We will tell you what we would do first — and if it is something you can do yourself in an afternoon, we will say that instead.

Ask us

Written by Soul Design — a small web studio in Wrocław, Poland, building sites for small businesses in English, Polish, German and Russian.

← Back to the guides