Website Ownership Explained: Domains, Hosting, Code, and Admin Access

What Website Ownership Actually Includes

People often say they own their website when they mean one of three different things: they paid for it, they can log in to it, or they hold the legal rights to its parts. These are not the same. Payment does not automatically give you account control, and account control does not settle who holds intellectual property. Separating them early prevents most handover disputes.

It helps to think in layers. The domain is your address. DNS decides where that address sends visitors and email. Hosting runs the site. Code and content are what the host serves. The CMS, analytics and third-party tools sit on top. Control can be strong in one layer and missing in another.

Domain Ownership, Registrars and DNS

Domain ownership is decided at the registrar, the company where the domain is registered. What matters is whose account holds it and whose contact details are listed as registrant. If an agency registered the domain under its own account, you may be using a domain you cannot renew, transfer or protect. Check the registrar account email, the registrant name, the expiry date, whether auto-renew is on, and whether a transfer lock is enabled.

DNS is a separate control point. Your DNS records may live at the registrar, at a hosting company or at a service such as a CDN. Whoever manages them can redirect your website and your email. Export or screenshot the full record set before any change, including MX and TXT records used for email delivery and domain verification. Losing these during a move is a common cause of email problems.

The safest arrangement is for the business to hold the registrar account with a role-based or shared company email address rather than one person's inbox, with two-factor authentication enabled and the agency added as a delegate where the registrar allows it.

Hosting and Server Access

Hosting can be the client's own account, an agency-managed account or a reseller arrangement. Each has tradeoffs. An account in your name gives you control and direct billing, but you carry responsibility for updates and incidents unless a maintenance arrangement covers them. An agency-managed server can be simpler to operate, but you depend on the agency to export data or move the site. Neither is wrong, provided the terms are written down and you know how to request a full copy of files, database and backups.

Ask what sits on the server beyond the website itself: scheduled jobs, environment variables, SSL arrangements, email sending and staging copies. These details are rarely in a handover note unless someone asks.

Website Source Code Ownership, Repositories and Licences

Website source code ownership is partly a practical question and partly a legal one. Practically, you want the code in a repository your business controls, with history, deployment instructions and a list of dependencies. Legally, who holds copyright, and on what terms, depends on your contract and on the licences of what was used. A custom theme, an open-source framework, a paid plugin and a stock font can each carry different terms. Some licences are per site, some are tied to the agency's account, and some renew annually.

NextGen Fusion cannot answer your legal position for you, and neither can a checklist. If code rights matter to your business, have a qualified professional review the contract and the licence list. What a project team can do is make the facts clear: which parts are bespoke, which are third-party, and which licence keys are registered to whom.

CMS, Analytics and Other Accounts

Check that at least one administrator account belongs to the business, not just to the developer. Distinguish owner-level access from editor access. Analytics, search console, tag management, advertising pixels, CRM integrations, payment gateways and email platforms should each have a business-held owner, with agency staff added as users. Removing access later is easy; recovering ownership of a property created under someone else's personal account is not.

A Simple Access Inventory

A one-page inventory, kept somewhere the business controls, covers most risks. Review it at handover and again at least once a year.

A Hypothetical Handover Example

Illustrative scenario only. A small manufacturer has a website built by a freelancer two years ago. The freelancer registered the domain, hosts the site on a personal server, and uses a paid form plugin under their own licence. The manufacturer has a CMS login and nothing else. When the freelancer stops responding, the site keeps running, but the domain is nearing expiry and nobody else can renew it.

A sensible recovery would start with the domain: contact the freelancer, or the registrar if necessary, to move registrant control to the business. Next, take a full copy of files and database, then confirm it restores on a test environment. Then move code into a business-owned repository, replace the plugin licence with one held by the business, and create owner-level analytics access. The order matters because domain control is the hardest to rebuild once lost.

Testing the Handover Rather Than Trusting It

A handover document proves little until someone tries to use it. Ask a person who was not involved in the build to log in to each account, find the renewal dates, and restore a backup to a staging site. Note anything that needed a favour from the previous developer. Also check who receives security and billing emails, because a notification sent to a departed employee is a hidden failure.

Finally, decide what you actually want. Some businesses prefer to hold every account and buy support when needed. Others prefer a managed arrangement with clear exit terms. Both can work, as long as the exit path is documented before you need it.