What can actually go missing from a website?
People say “my website” as if it were one object. In practice it is a chain. The domain name is the address visitors type. The DNS records tell the internet which server answers for that address. The hosting is the place where the site runs. The code is the source from which the site is built and updated. Around all of it sit accounts: the registrar, the hosting panel, the code repository, Search Console and analytics.
Every link has a login, and every login has an owner. The site is yours only when you can reach each of them without asking anyone for permission. When you cannot, losing the site does not need a hack. It takes a closed company, a forgotten password, an unpaid invoice or a quarrel with whoever holds the login.
Who is the legal holder of a domain name?
The holder is the registrant: the person or company recorded with the registrar that registered the name. ICANN, the body that coordinates the domain system, describes the registrant's side of the deal in its page Registrants' Benefits and Responsibilities: you take sole responsibility for the registration and use of the name, you give accurate contact data and you keep it up to date. Those duties fall on whoever is listed, not on whoever paid the invoice or built the site.
This is the risk with a domain that a developer registers “for convenience” in their own account. The registrar sees the developer as the holder and takes instructions from the developer, not from you. The renewal reminders go to the developer's e-mail address too.
Why is moving a domain slow when it is not in your name?
To move a domain to another registrar, its holder asks the current registrar for an authorisation code, often called an AuthInfo or EPP code. ICANN's FAQs for Registrants: Transferring Your Domain Name say that the code helps identify the holder and prevent unauthorised transfers, and that the registrar must provide it within five calendar days of the request. It is given to the registered holder only. If that is not you, your first step is a request to the person who is.
There is a second delay to know about. The same FAQ says a domain generally cannot be transferred to another registrar within 60 days of a change to the registrant's name, although some registrars let you opt out of that lock. A registrar may also refuse a transfer within 60 days of the initial registration. A handover done in a hurry after a falling-out can therefore leave the site tied to the old arrangement for two months. Done at the start of a project, the same change is a routine step.
Why does control of DNS matter as much as the domain?
DNS records decide where the address points, and Cloudflare's documentation on custom domains for Pages shows how much hangs on them. To serve a site on a bare domain such as example.com, the domain has to be added as a zone in the Cloudflare account and its nameservers pointed to Cloudflare. For a subdomain, a CNAME record at your DNS provider points to the project. If someone adds that record before attaching the domain in the Pages dashboard, the documentation warns, the address fails to resolve and returns a 522 error.
Read it the other way round: whoever controls the DNS account can repoint your address within minutes. “The domain is in my name” is therefore only half the answer. Ask also where the nameservers are and whose account manages them.
Where do hosting and the code fit in?
Hosting is the account that runs the site and receives the invoice. If a developer keeps several clients on one account, your site is just a folder in their setup. Ask for an account in your name, even when the developer sets it up and looks after it day to day.
The code usually lives in a repository, and on many projects the repository also publishes the site. On the Fedenko project, for example, every push to the main branch is published to the hosting automatically through GitHub Actions. When publishing is attached to the repository, the repository is the control panel: whoever owns it decides what goes live. The owner, not only a collaborator, should be you.
Why should you own the Search Console and analytics accounts?
Google's help page Verify your site ownership explains the mechanism. A verified owner has the highest permission level. Verification lasts only as long as Search Console can find the verification token. If an HTML verification file is deleted, verification ends, and a DNS record used for verification has to stay in place. If every verified owner loses access, all users lose access to the property.
The practical lesson: the first verified owner should be you, with the developer added as an additional owner or user and removed when the work ends. The search data of your site builds up in that account, and a site that moves into a new, empty property starts reading from zero. The SEO, analytics and Google setup service creates these accounts in your name for this reason.
How can you check your own situation in fifteen minutes?
- Log in to the registrar with your own e-mail. If you cannot, find out who can and whose name is in the registrant record.
- Note the renewal date and the e-mail address that receives the reminder.
- Find where DNS is managed and who holds that login.
- Ask for the name on the hosting account and on its invoices.
- Ask who owns the code repository and whether it is also what publishes the site.
- Open Search Console and analytics and check that you are an owner, not a guest.
- Check that the e-mail behind these logins is one you control and that it is not a mailbox on the site's own domain. If the domain lapses, so does the mailbox, and password resets stop working.
- Turn on two-step verification on each account and keep the recovery codes yourself.
What keeps a domain from lapsing?
A domain is registered for a period, and it stops working when that period ends without a renewal. ICANN's registrant page lists the routine duties that prevent this: reply to the registrar's enquiries within 15 days, keep your account details current and, if you use automatic renewal, keep your payment details current too. None of it is difficult, but all of it assumes that the registrar's messages reach a person who actually reads them.
That is why the contact e-mail on the registrar account should be a shared business address, not the personal mailbox of one employee or of the developer. When that person leaves, the reminders should not leave with them. Put the renewal date in a calendar that more than one person sees, and check the expiry date of the payment card at the same time.
What should a handover note contain?
Whenever a developer builds or takes over your site, ask for a one-page handover note and keep it with your company papers. It does not need to be long. It needs to be complete.
- Every account, with its login address, the name it is registered under and the e-mail that receives its messages.
- The registrar, the name of the registrant and the renewal date of the domain.
- Where DNS is managed and which records matter, including those used to verify Search Console or e-mail.
- The hosting account, how the site is published and where the code is stored.
- Who has access today, at which level, and who is to be removed when the work ends.
- Where the recovery codes and the devices for two-step verification are kept.
The note matters most on the day something breaks. A site that goes offline on a Friday evening is far easier to restore when the person who has to act can find the right login in a few minutes instead of searching old messages.
What do I do on my own projects?
I put two rules in writing: the price is fixed in the contract, and the domain, hosting, code and every access are in your name. That is why handover is the last of the four steps on the business website page: the site goes live on a domain and hosting in your name, and you receive the code and every access. On Oskar, the dolphinarium redesign that is still in progress, the plan is to launch on the client's own domain once the client approves the finished site.
What if the site is already in someone else's name?
- Ask in writing for a list of every account connected to the site, with the name behind each one.
- Start with the domain, because it is the slow one. Ask the registrant to unlock it and send the authorisation code, or to change the registrant to you, and allow for the 60-day lock.
- Then take over DNS, hosting and the repository, in that order.
- Rebuild or redesign only after that. A redesign on borrowed accounts just moves the problem to the next site.
- If the person is unreachable, go to the registrar's support. ICANN's page on registrants' rights says you are entitled to clear information about the registrar's support and dispute channels.