Imagine a landscaping company that hires a new website designer. Months later, the owner notices that the previous contractor still has an administrator account. Nothing has gone wrong, and the old account may have been forgotten rather than misused. But the business cannot confidently say who can change its website.

That is an access-management problem, not proof of an attack. It also has a straightforward starting point: find every person who can make changes, decide what they still need to do, and close access that no longer serves the business.

The Website Dashboard Is Only One Place to Look

Your website may have several separate sets of permissions. Removing a name from one dashboard does not necessarily affect the others.

  • Website editor or CMS: Who can change pages, publish content, install software, or manage other users?
  • Hosting and domain accounts: Who can change server settings, DNS records, billing, or the domain registration?
  • Business email: Who receives password-reset messages and security alerts for those accounts?
  • Search and analytics tools: Who can access Google Search Console, Analytics, or Tag Manager?
  • Connected business systems: Who can access booking records, form submissions, customer details, backups, or automation accounts?

Some systems also have API credentials, shared logins, or service accounts that do not appear as ordinary staff members. Your website provider can help identify those. The inventory should record the account, the people or services with access, their permissions, and who at the business is responsible. It should not contain passwords or secret access keys.

Does Everyone Need Administrator Access?

Usually not. Someone updating a service description does not automatically need the ability to change billing details, install plugins, or invite more administrators.

For example, WordPress distinguishes between Administrator, Editor, Author, and other roles. An Editor can manage published content but does not have the same site-management powers as an Administrator on a typical single-site installation. Exact capabilities can change with plugins, custom roles, or multisite configurations.

Managed website platforms have their own choices. Wix's roles and permissions let site owners assign collaborators different responsibilities, such as content writing, design, or broader management. The correct role depends on the work being performed, not whether someone is a trusted professional.

The same distinction matters outside the website. A person reviewing reports might need viewing access in Google Analytics, not full Administrator permissions. In Google Tag Manager, permission to read or edit a container is different from permission to publish changes.

Ask a simple question for each account: What does this person need to accomplish this month, and what is the least access that makes it possible?

Add Extra Protection Where a Login Can Do the Most Damage

An administrator account deserves stronger protection because a successful sign-in may allow major changes. So do the email account used for recovery and any domain, hosting, or billing account with broad control.

The Federal Trade Commission's small-business cybersecurity guidance recommends multifactor authentication (MFA) and limiting sensitive access to people who need it. Enable MFA on important accounts wherever supported. Where practical, consider phishing-resistant security keys or passkeys rather than relying only on emailed or texted codes. Google's passkey guidance describes how supported accounts can use passkeys to reduce exposure to phishing.

Extra security should not leave the business locked out. Check who can recover the account, where recovery codes are stored, and whether the recovery email or phone still belongs to an authorized person. Give individuals their own accounts when the provider supports that option instead of sharing one administrator password.

MFA makes an authorized login harder to steal. It does not cancel permission already granted to someone who should no longer have it. Both controls matter, but they solve different problems.

When an Agency or Employee Leaves, Plan the Handoff Before Deleting Accounts

A former contractor might still maintain an essential integration. A staff member's CMS account might own blog posts that need to be retained. Removing everything without checking dependencies could create a new problem.

A safer handoff follows this order:

  1. Confirm business control first. Make sure an authorized person can administer the website, hosting, domain, recovery email, and key reporting tools independently of the departing provider.
  2. Identify work that must continue. Check who handles backups, website updates, forms, bookings, renewals, and support tickets. Transfer responsibilities before closing the old access.
  3. Preserve content and records. For WordPress, the user-removal process can reassign authored content instead of deleting it with the user. Review the options carefully.
  4. Remove or reduce access across each service. Check CMS users, host and registrar invitations, email administration, analytics, tag management, integrations, and any shared or automated credentials. Where a login was shared, replace or rotate it through the provider's supported process.
  5. Confirm the result. Ask the responsible administrator to verify that the departing person no longer has access, that authorized staff can still sign in, and that customer-facing functions continue to work.

There is one less obvious detail in Google Search Console: removing a verified owner from the user list may leave verification tokens that allow that person to verify ownership again. Google explains how to review unused tokens, but also warns that removing a token can affect other services. Have an authorized technical administrator check the dependencies before changing verification files or DNS records.

If you discover an unfamiliar account, unexplained changes, or signs of compromise, treat that as a possible security incident rather than a routine cleanup. Preserve relevant information and contact your hosting or security provider promptly.

Make Access Reviews Part of Website Care

You do not need an elaborate quarterly security presentation for a small five-page business website. You do need a way to answer a few questions without chasing a former freelancer:

  • Can the business itself reach and recover its critical website accounts?
  • Can someone explain why every administrator or collaborator still needs access?
  • Are important logins protected with appropriate MFA or passkeys and current recovery methods?
  • Did anyone leave, change roles, or finish a project without an access handoff?
  • Is there one named person responsible for the next review?

Repeat the check whenever you change agencies, contractors, or staff, and agree on a sensible recurring schedule for your site's complexity. A simple brochure website needs less coordination than a site handling bookings, payments, or multiple employees' access.

The goal is not to distrust everyone who has helped build your website. It is to make access intentional, limited, and easy to review—so the business can keep working with good providers without losing control of its digital operations.

Sources and Further Reading