Skip to main content
All articles/Who owns your website, its domain, hosting and code
Engineering Guide4 min read•

Who owns your website, its domain, hosting and code

A checklist to confirm your company, not an agency or former employee, controls the domain, hosting, code, admin accounts and services behind your website.

Bunch of keys on a carabiner hanging from a dark pegboard

Most companies assume their website belongs to them because they paid for it. Then the agency closes, a freelancer stops answering, or an employee who set everything up leaves, and it turns out the domain is registered to that person, the hosting account is in their name, and nobody at the company has a password for anything. The site keeps running, until the card on the hosting account expires.

The short answer#

A website is not one thing you own. It is a set of accounts: the domain registration, the DNS, the hosting or cloud account, the code repository, the content management system, email for the domain, and services such as analytics, Search Console, payment providers and the SSL certificate. Your company controls the website only if it is the registered holder or the account owner of each of these, with at least two people inside the company able to log in, and credentials stored in a company password manager rather than in one person's head. Check each item on the list below. Where something is registered to an agency or an individual, have it transferred while the relationship is still friendly, because recovering it later is slow and sometimes impossible.

The accounts that make up a website#

Domain

The domain holder is the registered owner of the name. For .lv domains the register is NIC.LV. Look up who is listed as holder and which registrar manages it. If the holder is an agency or a private person, the domain is theirs until it is transferred.

DNS

DNS decides where the domain points: the website, email, and verification records for services like Google. It is often managed at the registrar, at a service such as Cloudflare, or at the hosting company. Whoever controls DNS can move the website or stop email.

Hosting or cloud account

The server, the database and the backups live here. Check who the account holder is, whose card pays for it, and whether backups exist outside that account.

Code

For a custom site or shop, the source code usually lives in a Git repository on GitHub, GitLab or similar. Your company should own the organisation or account that holds it. For WordPress sites, the theme and any custom plugins are code too, and so are the licences for paid plugins.

The admin panel

The CMS or shop admin should have named accounts for people at your company, with at least one administrator who is not the developer.

Email on the domain

If company email runs on the domain, losing control of DNS or the mail account means losing email. Make sure the mail service account is the company's.

Third-party services

Google Analytics, Google Search Console, Google Business Profile, Meta and advertising accounts, cookie consent services, payment providers, delivery integrations, and any API keys used by the site. Each should be owned by a company account, with the developer added as a user rather than as the owner.

Checklist#

For each item, write down the owner, the account email, who can log in, and where the credentials are stored.

  1. Domain holder and registrar.
  2. DNS provider.
  3. Hosting or cloud account holder and billing card.
  4. Backups: where they are and when a restore was last tested.
  5. Code repository owner.
  6. CMS or shop administrator accounts.
  7. Paid theme and plugin licences.
  8. Email service account.
  9. Analytics, Search Console and Business Profile owners.
  10. Advertising and social accounts.
  11. Payment provider and delivery service accounts.
  12. API keys and where they are configured.

Anything with "agency", "developer" or a private email address in the owner column is a risk.

Getting access transferred#

Ask for transfers while you are still on good terms. For each account, the provider has a standard process: a domain holder change, adding your company as owner of a Google property, transferring a repository to your organisation, or changing the account email on hosting. Have your own accounts ready first so there is somewhere to transfer to. Do not accept a shared login as a substitute for ownership.

Put the transfer obligation into contracts for new work: all accounts are opened in the company's name from the start, and the developer receives user access that can be removed.

If the developer is no longer reachable#

Recovery is possible for most items but takes time. Domain registries and providers have procedures for proving the company's right to an account, usually with company documents. Code may have to be recovered from the running server if there is no repository access. The companion article on taking over a project from a developer who left describes what to request and in which order. Once access is recovered, remove people who no longer work with you, as covered in the access offboarding checklist.

Nevo takes over existing codebases and projects from previous developers. The codebase takeover page explains how that work starts.

Sources#