Who Owns Your Domain, Hosting and Analytics? A Checklist

When the relationship with a supplier ends, the first thing anyone raises is the termination clause in the contract. Yet what actually makes a split expensive is rarely in the contract; it is in the access list. Whose panel does the domain sit in, whose invoice is the hosting on, who logs in to the admin panel as an administrator, under whose account were the measurement properties created — if the answers to these questions were not written down at the start of the relationship, they get hunted down one by one at the end, and each turns into a separate point of negotiation.

In Turkish-language sources this topic is mostly approached from one of two ends: either promotional pages from domain sellers with headings like "alan adı kimin adına olmalı" (whose name should the domain be registered in), or legal commentary written after a dispute has already broken out. The ground in between — the inventory and handover work done before anyone reaches a dispute — is largely empty.

What follows fills that ground. It covers the full list of a business's digital assets, where the difference between ownership and access lies for each item, and the order to follow on handover day. Ad accounts are one item on this list, but because they open a separate discussion they are only flagged here and left to their own article.

The real cost of parting ways shows up in access, not in the contract

With digital assets, two separate ideas are constantly mixed up: being the owner of an account and having access to it. The owner is the party that can close the account, change the billing and remove everyone else's access. A person with access works for as long as the owner allows it.

A healthy setup fits in one sentence: ownership with the business, access with the supplier. When the setup is the other way round, no problem is visible as long as the relationship goes well. The problem only surfaces at the moment of separation, during a migration, or when something breaks on the supplier's side — in other words, at the worst possible time.

The second issue is continuity. It is not enough for an asset to be in the business's name; the recovery details attached to that asset have to sit with the business as well. If the registration email is the personal address of an employee who has left, or phone verification goes to a number nobody uses any more, ownership belongs to the business on paper but is out of reach in practice. This picture turns up more often than actual disputes do.

Digital asset inventory: a twelve-item list

The most practical way to build the inventory is to rank the items by the question "what happens if we lose this". The list below is complete for most corporate businesses.

1. Domain registration and any backup domains
2. DNS management
3. Hosting or cloud account, server access
4. SSL certificate and any security or acceleration layer
5. Administrator account for the content management panel
6. Source code repository
7. Corporate email service and its admin panel
8. Search console property
9. Analytics property and tag manager container
10. Social media accounts and business manager
11. Maps and business profile listing
12. Ad accounts and product data feed

For each item, four columns go into the table: the account name, the registration email, who the owner is, and the person inside the business who has access. The fourth column frequently comes back empty, and that is the real output of the inventory — the assets where the business does not hold a single login of its own.

Building the inventory while the relationship is running smoothly, rather than once a split is on the table, is both faster and free of argument. The same document goes on the table on day one when you start working with a new supplier, too.

Domain and DNS: registrant, admin email, transfer lock

The domain is the most critical item on the list, because losing it affects everything else: the site, email and verified properties all hang off the domain.

There are three things to look at. Registrant details: the person or organisation shown in the domain's registration record. This has to belong to the business; if an employee's or supplier's name is there, a transfer needs that person's consent. Registrar panel access: which registrar holds the domain and whether the business has its own login to that panel. Transfer lock and authorisation code: whether the code needed to move the domain to another registrar is somewhere the business can reach.

DNS management should be tracked as a separate item. DNS decides which server, which email service and which verification records the domain points to. Even when the domain is yours, if DNS management sits in another panel, where the site and the email are routed is under that panel's control.

A practical check: when the domain expires and which address the renewal notice goes to. The outage caused by an expired domain does faster and more visible damage than every other risk on this list.

Hosting, server and certificate: whose invoice are they on

Whose name the hosting account was opened in, who owns the payment method, and whether the business has its own login to the panel are three separate questions.

A common setup is a supplier hosting several clients' sites in its own hosting account. For the supplier this is an operational convenience, and on its own it is no sign of bad intent. But the consequence is this: the site's files, database and backups sit in an account you cannot reach. If you part ways, exporting the files becomes a request you have to make.

If you accept this setup, at least two things need to be in writing: how often backups are taken, and how quickly they will be handed over in full on request.

The certificate side rarely causes trouble because in most setups it renews automatically; but if a paid certificate is in use, the account it sits in should go into the inventory as well.

CMS panel and code repository: administrator or owner

Holding the "administrator" role in a content management panel is often a weaker position than it sounds. Some systems have a single top-level account, and that account can remove every other administrator. What belongs in the inventory is not the role name but the answer to one question: do we have an account in this panel that can remove the supplier's access?

The source code repository is a separate item. If the site is a custom build, it matters where the code is kept, which account the repository sits under and whether the business can get into it. If the code counts as delivered to the business, the form of delivery should be written down too: an archive file, or a repository under the business's own account. The difference between the two is the difference between code you can keep updating and code you cannot.

One more item under the same heading tends to be forgotten: design source files. The editable versions of templates, the source formats of the logo and brand assets, and any custom font licences. When these are left off the handover list, a small edit years later means producing everything from scratch.

The measurement layer: search console, analytics and tag manager

With measurement tools, ownership works differently at the technical level, and that difference is often misunderstood.

On the search console side, verification is tied to the domain or to a URL prefix. The business's own account can verify independently through the domain — so it can set up its own access without relying on the supplier's property. What needs to happen is for the business to create its own verified property from the outset.

On the analytics side the structure is hierarchical: properties live under an account. Which account a property was created under matters, because the account administrator can edit access to that property. If the property was opened under the supplier's account, it needs to move to the business's own account, and that move is not equally easy in every setup.

On the tag manager side, the container is the identity of the code placed on the site. If the container stays with the supplier, after the split the business has no control over what the measurement code on its own site is doing.

When these three tools are set up at the start of a relationship, one rule is enough: the properties and the container are created under the business's corporate account, and the supplier is added as a user. A supplier that pushes back on this setup has given you an answer worth weighing in its own right. We gathered a set of questions for testing a supplier's reporting and access discipline in our article on auditing your current agency.

Social accounts: page ownership versus admin rights

On social platforms the ownership structure differs from the web side, and this is where the difference causes the most trouble.

On most platforms a business page is managed through a personal account. So even when the page itself belongs to the organisation, management rights are handed to individuals. When an employee, or someone on the supplier's team, leaves, removing their rights is a separate step, and when it is forgotten it stays open for years.

The second layer is business manager accounts. Once pages, ad accounts and assets are gathered under a business manager, which organisation owns that manager becomes the deciding factor. If the page sits under the supplier's business manager, the page may be yours but the management umbrella is not.

Three lines to add to the inventory: who owns the business manager the page is attached to, whether at least two in-house people hold full rights on the page, and whether the username and profile details are registered through a corporate email. We set out our approach to opening accounts in the business's name and keeping profile details consistent on our social media management service page.

The maps and business profile listing also belongs under this heading: check who owns the profile, whom the verification method is tied to, and who appears on its list of managers.

Why ad accounts are a separate matter

With ad accounts, ownership is structurally different from the other items here: the account holds not just access but a layer of learning and data that builds up over time. Campaign history, conversion definitions, audience lists and billing records are tied to the account, and if the account does not change hands, none of them move.

The topic also connects directly to fee models: charging on spend, whose card the billing runs through, and how the umbrella account is set up are items that have to be weighed together. That is why we only flag it here as one line of the inventory; the detail, and the clauses to write into the contract, are covered separately in our article on ad agency fee models and account ownership.

The same logic applies to product data feed accounts: who owns the account that sends products to sales channels decides whether visibility in those channels continues.

Handover-day protocol: sequence, verification, irreversible steps

A handover is not something settled with a single email; it is a sequenced operation, and when the sequence breaks, the risk of an outage appears.

Step one — preparation. The inventory table is updated and a target state is written for each item. On the business side, a permanent corporate email address is chosen; every registration will be moved to that address.

Step two — parallel access. Before the handover, the business sets up its own access to every asset. The supplier's access is not removed at this stage. The point is to keep a way back if something goes wrong in the next step.

Step three — ownership transfer. The domain registration, hosting billing, analytics property and social assets are moved to the business's account one after another. After each transfer there is a check: does the site load, does email arrive, is measurement still collecting data.

Step four — access clean-up. The access of the supplier and of departing employees is removed. Because this step can be undone it comes last; but when it is postponed, it often never happens at all.

Step five — record. Who took over which access on which date is put in writing. That record is the starting point for the next handover.

Irreversible steps should be flagged separately: transferring the domain to another registrar, account merges on some platforms, and deleting properties. None of these is done without a backup.

Four clauses to put in the contract

The way to avoid rebuilding the inventory every time is to write the rule into the contract from the start. Four clauses cover most situations.

Ownership clause. Every account created within the project's scope is opened with the business's corporate email address and in the business's name; the supplier is added to these accounts as a user.

Delivery clause. If the relationship ends, all access, source files, backups and a record of the measurement setup are handed over within a defined period.

Inventory clause. At least once a year, both parties review and update the current asset inventory.

Continuity clause. On critical accounts, at least two people on the business side have access; recovery details are tied to corporate addresses.

These clauses are not a statement of distrust towards the supplier; raised while the relationship is going well, they are an arrangement that reduces uncertainty for both sides. When writing the scope and delivery criteria for a new project, we detailed where these clauses fit into the brief in our article on writing a website brief; how we turned keeping access with the business into a working principle at handover is explained on our corporate website service page.

If you want to map your current asset inventory and see where access is missing, get in touch with us.

Frequently Asked Questions

Can we get the domain back if the agency registered it in its own name?

In most cases yes, but it is a matter of agreement rather than a technical operation: the party named in the domain's registration record has to consent to the transfer. In practice the process runs through obtaining the authorisation code from the registrar's panel and moving the domain into the business's own account. When the parties cannot agree, the matter slides onto legal ground and the outcome is decided by trademark rights, payment records and the wording of the contract; from that point on the process becomes both longer and unpredictable. That is why the real solution is to set it up correctly from the start: the domain is opened in the business's own account on day one.

What is the difference between granting admin access and transferring ownership?

Admin access is permission to act within an account, and the party that granted it can take it back whenever it wants. Ownership is the position of deciding on the account itself, its billing and the access of every other user. The practical question that tells them apart is this: do we have a user in this account who can remove the other side's access? If the answer is no, what you hold is access, not ownership. Because many platforms show these two situations with role names that look alike, the thing to look at is that question, not the role name.

Can search console and analytics history be moved?

The two tools behave differently. On the search console side, the business can create its own verified property, and that property can also show data from before the verification date — so access to history may be possible without depending on the supplier's property. On the analytics side, data is tied to the property: the property itself can be moved to the business's account, in which case the historical data comes with it; but if the property is not moved and a new one is set up from scratch, the history does not come across and only previously exported reports remain. That is why the preferred route at handover is to move the existing property rather than open a new one.

Does a social media page have to be owned through a personal account?

On most platforms business pages are managed through personal accounts, which means management rights are tied to individuals. The way to reduce the risk this creates for the organisation is to bring the page under a business manager umbrella and make sure that umbrella is the business's own corporate registration. There also needs to be more than one authorised person: a page tied to a single person ends up hard to recover when that person leaves or loses access to their account. In the inventory, at least two in-house names should be written against this line.

Will the site go down during the handover?

Done in the right order, there is usually no outage. The two risky operations are transferring the domain to another registrar and changing hosting; both affect the DNS records. When they are carried out, having the new environment ready and tested first, exporting the DNS records in advance and recreating them one to one, and making the change during a low-traffic window noticeably reduce the risk. By contrast, a handover of access and ownership alone — panel permissions, property moves, billing changes — does not affect how the site runs.