A website is more than design and code
From the outside, a website appears to be a set of pages. Operationally it depends on a network of assets and accounts: the domain, DNS, hosting, source code, database, email delivery, analytics, forms, licences, backups, and administrator access.
The company does not need to manage every component day to day. It does need to know what exists, who legally and technically controls it, how access can be recovered, and whether the project can be handed to another qualified supplier.
This is not preparation for conflict. It is ordinary business continuity. Staff change, suppliers close, relationships end, email addresses expire, and services alter their terms. Ownership prevents a routine change from becoming a crisis.
The domain must belong to the company
The domain is the business’s digital address. It supports the website, company email, links in directories and documents, advertising, and often years of search reputation. It should therefore be registered to the company or its authorised owner—not personally to the developer who created the site.
The company should know the registrar, registered holder, contact email, expiry date, and renewal method. Ideally, it has its own account protected by multi-factor authentication. A supplier can receive technical access without being the only person able to renew or transfer the domain.
When the domain is controlled by a supplier, the company can become dependent even without bad intent. One forgotten payment, obsolete email address, or inaccessible account can interrupt the website and email together.
DNS and email are not minor details
DNS determines where the domain points, where the website runs, and which servers receive email. A careless change can take both the site and business communication offline. The company should know who manages DNS and have a recovery route.
For email, the business should control the service’s administrator account, mailbox list, and domain-authentication settings. SPF, DKIM, and DMARC are not decorative technical acronyms: they support deliverability and make misuse of the domain harder.
An external administrator can configure everything, but the company should receive access and documentation. Critical accounts should not depend on the private email address of one employee or contractor who may no longer be available.
Hosting, source code, and the ability to move
There is no single correct hosting model. What matters is knowing where the site runs, what the price includes, who pays for it, how backups work, and what happens when the cooperation ends.
For a custom-developed website, access to the source code, database, licences, and deployment process should be clear. The company does not need to work in the repository every day. A real handover to another developer must nevertheless be possible.
Closed platforms require an honest discussion of export options. Some let the company move its content but not the design or functionality. That can be an acceptable trade-off when it is understood and reflected in the price. It becomes a problem when lock-in is revealed only after the client decides to leave.
Data and accounts must be separate from the supplier
Analytics, Search Console, advertising accounts, business profiles, booking systems, mailing lists, and social channels accumulate history and data. They should be owned by the company. The supplier should receive a manager or partner role instead of creating everything inside a personal master account.
The same principle applies to photography, copy, design assets, and brand files. The business should understand which rights it obtained, where the originals are stored, and whether they can be used outside the website. Paid fonts, icons, images, plugins, and software need clear licence ownership and renewal terms.
Control does not mean that management must understand every configuration detail. It means an authorised person can recover access, appoint a new administrator, and demonstrate ownership.
Backups and documentation are part of delivery
A backup is not simply another copy on the same server. It should be created regularly, stored separately, and supported by a tested restoration process. A database-driven site needs both content and configuration. A static site needs the source, deployment setup, and any required environment variables.
The company should receive a concise handover document covering the domain and registrar, DNS, hosting, repository, analytics, forms, email services, licences, backups, responsible people, and renewal dates. It does not need to be a hundred-page manual. It needs to be current and understandable.
This protects both sides. The client knows what it owns, and the supplier does not have to reconstruct years-old settings from memory.
Access needs rules, not one shared password
Control does not mean giving administrator rights to everyone. Good access design separates roles. An owner or nominated administrator holds recovery access, editors manage content, and external suppliers receive only the permissions required for their work.
A shared password sent through email or chat is convenient only until the first incident. Individual accounts, multi-factor authentication, and regular access reviews make departures manageable without changing everything else.
At least once a year, review account owners, recovery emails, phone numbers, and payment cards. Many failures are not attacks; they happen because a critical account remained attached to someone who is no longer reachable.
Management can remain external; responsibility cannot
A company does not need to operate servers or update a website every day. A long-term technical partner can handle monitoring, backups, security, and minor changes. The scope, response times, ownership, and exit process still need to be explicit.
Professional management allows the client to ignore technical detail without losing visibility. The company is informed about critical changes, understands the cost of the next period, and knows how the service can be ended. Convenience and control are compatible.
Warning signs before signing
- The supplier refuses to register the domain to the client or says access is unnecessary.
- Hosting costs do not separate service, management, and licences, and the effect of non-payment is unclear.
- Delivery of source code, database, content, or design files is not agreed.
- Analytics, advertising, or business profiles are created inside the supplier’s personal account.
- The contract describes building the site but says nothing about ownership, licences, support, or termination.
- Questions about moving the website receive vague answers or reveal an undefined extra charge.
Control is part of professional cooperation
Some companies hesitate to ask for access because they fear appearing distrustful. Transparent ownership is the opposite: it is a normal standard of well-managed work.
A supplier can continue to provide hosting, maintenance, updates, and support while the client owns its digital assets. A long-term relationship should be sustained by quality and trust, not by the technical impossibility of leaving.
Do you know who owns your domain, hosting, and critical accounts today?
I can map the ownership, access, and dependencies around your website. You will receive a clear view of what the company controls, what is missing, and what could complicate a future change of supplier.