Website logins and access: who needs what

A website is not one login. It is several, held with different companies, and each controls something different. Many problems with websites come down to not knowing which accounts exist, who holds them and who can use them.

The accounts around a typical site

Account	What it controls	Who should own it
Domain registrar	The name, and where it points	You, as registrant. ICANN says the registrant is the holder of the domain
DNS provider	Where the name sends visitors and email	You, or a provider you control
Hosting or deployment	The files that make up the site	You
Email	The addresses used for recovery and notices	You
Search Console	How Google reports on your site	You, as owner
Analytics	Visitor data, if you use it	You
A content system, if there is one	Your pages and users	You, with named users
Social and business profiles	Your public presence	You

Write this table for your business and fill in who holds each login, and which email address it recovers to. Keep the list somewhere safe, not in a chat.

Rules that prevent most trouble

Own the important accounts. Do not let a provider register the domain or open the hosting account in their name. If they do, you may not be able to move later.

Give the least access that works. A developer who builds pages does not need your email password or your bank. Where a service has roles, give the lowest one that does the job. Search Console, for example, has Owner, Full user, Restricted user and Associate roles, and only an owner can add users. Keep ownership for yourself and give others a lower role.

Use named access, not shared passwords. Invite people with their own login where the service allows it. A shared password cannot be taken away from one person without changing it for everyone, and it hides who did what.

Turn on two-step verification. CISA says a password alone is weak, and that turning on multifactor authentication makes an account much harder to take over. Google lists several methods, from passkeys and security keys, which resist phishing best, to prompts and authenticator codes. Text messages are better than nothing and weaker than the others. Use it on your email first, because email recovers everything else.

Use a password manager. Unique long passwords for each account, kept in one protected place.

Plan recovery. Make sure the recovery email and phone number are yours, and keep backup codes safe. A recovery route that depends on a former employee’s phone is a problem waiting to happen.

When someone joins or leaves

When a developer starts, give access for the job and write down what you gave. When the project ends, remove it: change shared passwords, remove their users from Search Console, hosting and the content system, and keep the handover list. See what you should receive when the website is finished.

A worked example

A supplier’s site was built by a freelancer who registered the domain with his own email. Three years later he cannot be reached, and the supplier cannot change the website’s address settings. The fix is slow: proving a link to the business, contacting the registrar and waiting. If the supplier had held the registrar account from day one, with the freelancer invited as a helper, the problem would not exist.

What I do on projects

My sites go live on the domain and hosting that you provide, so those accounts stay under your control. I ask for access only for the job, and the proposal says what that is. I do not claim any one setup is the safest for everyone. The right setup depends on what you run and how many people use it: message or call Harman if you want to talk through yours.