How Not to Lose Access to Your Own Website: Domain, Hosting, Code Rights

Three things that are supposed to be yours

Every website has three separate assets, and mixing them up causes most of the trouble. The domain is the name. Hosting is the place where files and the database live. The code is the site itself, the result of the work.

They sit in different places, with different providers, and they get lost independently. You can keep the domain and lose the code. You can have the code and no access to the database with your orders in it. So "access to the website" is not one line in a notebook.

In practice the domain is what surfaces most often. It is the cheapest piece and therefore the least visible: the contractor bought it on their own account for pocket money so they wouldn't have to deal with your registration, and everyone forgot about it. Three years later you part ways, and your company name stays with them.

The domain must be registered to you. Not "administered", registered

A domain has an owner, and that owner is a record in the registrar's database. For a company it lists the organisation name and tax details; for an individual, their name and ID data. Someone who merely has a login to the control panel is not the owner, but they can still do whatever they like with the domain: point it somewhere else, transfer it, let it lapse.

Checking takes a minute. Open any whois service, enter your domain and look at the organisation and registrar fields. Private owners are usually hidden, but companies are visible - if the name there isn't yours, the question is settled. The domain is not yours.

Step two is logging into the registrar account with your own credentials. Not "the contractor showed me their screen", but you, with your own email. If no such account exists, the domain lives inside someone else's account alongside other clients' domains.

A word on email. The domain's contact address is your recovery channel. If it points to something like studio@, every renewal notice and every password reset link goes to someone else. Switch it to a company mailbox that you or your accountant can get into.

• Look up whois and check the owner and the expiry date
• Log into the registrar account with your login, not someone else's
• Set the contact address to your own mailbox, a work one rather than a personal one
• Turn on auto-renewal and attach the company card
• Put a calendar reminder a month before expiry - auto-renewal breaks when the card expires

The story that repeats every year

The domain wasn't renewed. The site went down, and so did email on that domain, because the MX records live there too. The business owner finds out from a customer who couldn't send a message.

Then the race starts. A domain isn't released the moment it expires: there is a window when you can still buy it back, more expensively and through the registrar. Miss that window and the name goes free, where automated buyers grab it precisely because it had traffic. Getting it back then means paying their price.

The protection is boring: auto-renewal, a valid card, a calendar reminder. There is no technical magic here.

Hosting: account in your name, backups outside the account

Register hosting to yourself and pay from the company account. This isn't control for its own sake, it's about who the provider will actually talk to when data needs restoring. Support deals with the account holder, not with whoever shouts loudest in chat.

Give the contractor separate access. Decent providers support this out of the box: an extra user or a key with the permissions needed, which you can revoke in one click. The "one shared password for everyone" setup works until the first person leaves somebody's team.

Backups deserve their own paragraph, and almost everyone fools themselves here. The provider's automatic backup lives on the same account as the site. If the account is suspended for non-payment, or you lose access to it, the backups go with it. So once a month at minimum, pull a copy out: an archive of files and a database dump into cloud storage or onto a drive in the office.

And check that the copy actually works. A downloaded archive nobody has ever restored is not a backup, it's a hope. Spinning the site up from a copy on a test subdomain costs a couple of hours and removes a very unpleasant class of risk.

Code: who owns it by default, and how to make it yours

Here comes the unpleasant surprise. In many jurisdictions the exclusive rights to software stay with the author or their employer by default. Paying for the work does not transfer rights on its own. You need wording in the contract stating that exclusive rights pass to the client, ideally with a handover document recording exactly what was transferred.

If the contract says nothing about this, you paid for a working website but not for the right to change it, move it, or have another team extend it. In practice this almost never reaches a courtroom, but the contractor has leverage, and in a conflict they use it.

Spell out source code separately. A built site sitting on hosting is the output of a build process, awkward and expensive to work from. What you need is the repository: source code, the dependency file, database migrations, configs. For a React project the gap between "we have the repository" and "we only have the dist folder" is enormous. In the second case the next developer will almost certainly start over.

The repository should live in your organisation on GitHub or GitLab, with the developers as members of it. That is free and takes twenty minutes. Then when the team changes you remove people from the organisation and the code stays where it is.

Ask about third-party components directly: which paid themes, fonts, plugins or libraries are in use, and whose name the licences are in. A template bought on the contractor's account is just as much of a dependency as a domain in their name.

• A contract clause transferring exclusive rights to the developed code to the client
• A source repository inside your organisation, with you as owner
• Deployment instructions: how to bring the project up from scratch on an empty server
• A list of paid components and licences, registered to you
• Database access and a dump of the latest version

What gets forgotten, even though it matters more than the code

Code can be written again. Accumulated data cannot.

Analytics. Tracking accounts are often created under the agency's login. Lose access and you lose the whole history: seasonality, conversions, traffic sources going back years. Create the property on your own account and give the contractor guest access.

Email on the domain. If company mail is tied to the site's domain, losing the domain kills your correspondence. Check whose name the mail service account is in.

The payment module on an online store. The agreement with the payment provider and the keys should be in your company's name, otherwise customer money technically doesn't pass through you.

The SSL certificate. Usually this is a free Let's Encrypt certificate that renews automatically and needs no attention. But if someone once bought a paid certificate, find out which account it sits on.

DNS records. Sometimes the domain is yours while the DNS zone is managed by a third-party service on someone else's account. Formally the domain is yours; in practice somebody else controls it.

Handover checklist: what to ask for on launch day

Not a year later, not "when we need it", but on the day you sign off the project, while everyone is still in a good mood. Collect it all into one document and keep it somewhere more than one person can find it: with your accountant, in a safe, in a company password manager.

Go through every item by hand. "They sent me the login" and "I logged in" are different states. The most common discovery during such a check: the password works, but signing in requires an SMS code sent to a number you've never seen.

• Registrar account: your login, your company as owner, auto-renewal on
• Hosting or server: account in your name, paid from your account, root access or SSH key held by you
• Access to the site admin panel and the database, with a dump downloaded
• A link to the repository where you own the organisation
• Instructions for deploying the project on a new server
• Analytics properties created under your account
• Logins for third-party services: email, payment module, SMS gateway, CDN
• The contract clause transferring exclusive rights to the code, with the handover signed
• Two-factor authentication tied to your phone, not someone else's

When a thorough audit isn't worth it

If you're building a simple landing page on a website builder in a few days, half the list above doesn't apply. There is no source code in any meaningful sense, no database of your own, and nowhere to move anyway - you're paying for the platform. It's enough that the builder account and the domain are in your name. That's it.

If the project is a test that will live three months and nobody will miss it, don't spend time on repositories and licences. The risk is small and the cost of protection exceeds the loss.

But if the site holds a customer database, orders, user accounts, payment or inventory integrations, work through the whole list. And the longer the site has been running, the more expensive losing it becomes: not because of the design, but because of the accumulated data and search rankings.

A decent contractor takes these questions calmly, because it makes their life easier too: if the client holds every credential, nobody wakes them at night asking them to restore something. If a request to hand over the domain or the repository turns into explanations about "it's more convenient this way" and "we're working together anyway" - that is your answer. That contractor is keeping you on a hook deliberately.

At EFIMOV DEV we hand over access at the delivery stage and state it in the contract, and we write the transfer of code rights out plainly rather than by implication. Starting price ranges for landing pages, company sites, stores, bots and support are published on our site; the exact quote comes after the brief, once it's clear what needs to be moved and maintained.