Two colleagues discuss a paper folder across a garden-shop counter, with empty hands and a few plants behind them.
Illustrative image created for this guide.

Your website can look perfectly healthy while an important account sits under an old email address. The problem may stay hidden until a renewal notice goes missing, someone leaves or a small change needs approval. Then the question becomes surprisingly difficult: who can actually do the work?

You do not need to take every technical task away from a trusted helper. You do need to understand which accounts the business relies on, who controls each one and how authorized access continues when circumstances change. A short account map is a sensible place to begin. It is a record of responsibilities, not a sheet of passwords.

Start with the business address, then follow its connections

A domain is the address people use to find you, such as a name ending in .com. The registrar handles its registration. Website hosting supplies the service where the site runs. A website builder or content system may have another login. Business email can be provided by yet another company, even when everything was purchased together.

There may also be a Google Business Profile, booking system, form service or payment provider. Being able to edit a page does not prove control of these other services. An invoice in your inbox does not prove the account has a working recovery route. Treat each as its own item until you have checked how it is actually managed.

Make a simple table with these headings: Service, Provider, Business purpose, Account holder, Your access level, Renewal responsibility, Recovery contact checked, Next action. Do not include passwords, backup codes or full payment details. Store the record in an approved private location, accessible only to people who need it. A useful fictional row might read: Domain registration; Example Registrar; Business address; Bakery Ltd; Owner access confirmed; Owner handles renewal; Recovery contact checked October 9; Confirm renewal notice destination. Use your provider's actual role names, and leave an uncertain answer marked “Not yet checked.”

A fictional bakery finds three different answers

Imagine a bakery hired a designer several years ago. The owner can update opening hours on the website, but the designer registered the domain. The hosting invoice arrives at the bakery's current email address. An assistant manages the Google Business Profile through a personal Google account.

None of those details alone proves something is wrong. The exercise is to replace assumptions with a clear arrangement. For the domain, the owner asks the designer to identify the registrar, the registration account and the documented process for giving the business appropriate control. For hosting, they check the actual account rather than relying only on the invoice.

For the business listing, the assistant and owner inspect People and access together. They discover the assistant is the primary owner and the bakery owner is a manager. That is a specific access difference, not a reason to delete the listing or start again. The next step is to understand the provider's transfer process and plan an orderly handoff.

Roles are more useful than a shared password

Where a service supports separate users, ask which role provides the access each person needs. A writer may need to edit pages without changing billing. A bookkeeper may need invoices without publishing content. A trusted administrator may need broader access, but that should be an understood responsibility.

Google's Business Profile ownership guidance explains that owners and managers have different powers and that only the primary owner can transfer primary ownership. It also describes a seven-day restriction on certain actions for newly added owners or managers. A handoff therefore may require preparation before someone's final working day.

Separate accounts make it easier to see who has access and remove only the departing person's permissions later. Do not solve every access problem by emailing a master password. Use the provider's invitation and role features when available, and verify the invitation reached the intended person through an already trusted contact route.

Check recovery without creating a lockout

For each important account, inspect the recovery settings using the account's normal trusted sign-in path. Is the recovery email current? Does the authorized person still control it? Does the account depend on a former employee's phone or a device nobody can locate? Record whether the route was checked, without copying its secrets into the account map.

Do not sign everyone out or deliberately lose access to test recovery. A safe first pass confirms visible settings and who controls the required resources. That is narrower than proving a full emergency recovery. If a stronger exercise is needed, agree it with the provider or responsible administrator before changing anything.

Consider circular dependencies. If your only recovery email uses the same business domain, what happens if that email service is unavailable? The answer depends on the provider and the approved recovery options. Flag the question for resolution rather than improvising a new personal email or weakening security just to fill a blank cell.

Keep access changes separate from moving the website

Ownership, user permissions, registrar transfers and hosting migrations are different operations. You may be able to improve business control without moving the live website at all. Conversely, moving hosting does not automatically settle registration ownership or business listing access.

ICANN directs registrants to their registrar for registrant-information changes or transfer to a different registrant. Follow the relevant provider's process and ask whether a change affects the timing of a later transfer. Before approving a transfer, establish exactly what will change, which services depend on it and who will confirm the result.

Do not edit DNS records to prove you own the account. Those records can affect the website and business email. If an account change could touch either, get a clear plan that names the affected services, the checks after the change and the recovery path if something fails. Account housekeeping should not become an accidental migration.

Finish the bakery's handoff with evidence

In the fictional example, the bakery owner receives an invitation, accepts it and signs in independently through the provider's normal site. The designer confirms the intended role on the account screen. They agree who handles renewals and where notices should go. The owner records the observed access level and the actual date of the check.

They do not remove the designer immediately just because the invitation was accepted. First they verify the business has the intended permissions and any provider waiting period has ended. Only then do they adjust the helper's role if the approved arrangement calls for it. The assistant's listing access is handled separately, using Google's current ownership process.

If nobody recognizes the registered account, a dispute exists or the provider cannot confirm the handoff method, stop that part and use official support. Do not create duplicate profiles or attempt to bypass another person's account. Keep the unresolved row visible, with the person responsible for the next legitimate step.

A complete map does not require you to run the technology yourself. It gives you a clearer basis for delegating the work. Before a larger website project, pair it with the repair-or-rebuild guide: understanding access helps distinguish a design decision from a missing-permissions problem. Your immediate win is knowing who can act, through which account, with a clear handoff when that responsibility changes.