Start with an access and ownership inventory
A contributor may have access to more than the website’s publishing dashboard. Before changing anything, list the systems they used: the content management system, hosting, domain registrar, analytics, search tools, email marketing platform, file storage, password manager, and any design or project tools. Include test sites and old accounts that are easy to forget. Note whether each login belongs to the individual or is shared by several people.
Record what the contributor owns or maintains. Look for scheduled posts, unpublished drafts, uploaded files, forms, integrations, documentation, and recurring tasks. If they are the only person who knows how something works, arrange a handover before their access ends when possible. The goal is to separate their work from their permissions: keep what the site needs, but do not keep access open simply because an account owns a draft.
Transfer work before removing accounts
Review content in progress with an editor or site owner. Decide who will finish each draft, approve scheduled material, respond to comments or submissions, and maintain pages the contributor regularly updated. In the CMS, check what happens to content when an account is deleted. Some systems offer reassignment; others may require you to change authorship or ownership first. Preserve a useful record of the work without leaving an active login behind.
Check for assets and settings tied to a personal account, such as a form notification address, a calendar connection, or a plugin licensed through the contributor’s email. Move those dependencies to an organization-controlled account where the service allows it. If a transfer is not possible, document the dependency and plan a replacement rather than assuming it will continue working.
Remove access across every system
At the agreed end of access, disable or remove the contributor’s individual accounts in each system on the inventory. Review their roles and group memberships, including permissions granted through a team or shared workspace. If your tools support active-session revocation, use it so an existing session does not remain open after the account changes. Check connected apps, API keys, publishing tokens, SSH keys, and other credentials the person could use outside the usual login screen.
Shared credentials need separate attention. Change passwords the contributor knew and replace shared recovery codes or other secrets they could still use. Update those details in the team’s password manager, then verify that the people who need access can sign in. Where practical, replace a shared login with named accounts and limited roles; this makes the next departure easier to manage.
Do not overlook indirect access. A departing contributor may still receive password-reset messages, form submissions, security alerts, or domain renewal notices through an email alias or forwarding rule. Remove them from relevant groups and notification lists, and make sure another responsible person receives operational messages.
Check that the website still works
After the access changes, test the workflows the contributor touched. Confirm that an authorized editor can publish and update a page, scheduled content remains assigned appropriately, forms deliver to the right inbox, and integrations continue to run. Check that domain, hosting, and backup notifications reach a current site owner. For a small site, a short, deliberate test is often more useful than assuming a successful login means the handover is complete.
Make sure at least one appropriate person can reach critical accounts and that backup and recovery information is stored where the organization can find it. Avoid concentrating every owner-level permission in one person’s personal account. Give routine contributors only the access they need, while keeping emergency access available to those responsible for the site.
Close the loop and improve the process
Keep a brief offboarding record: the systems reviewed, accounts removed, credentials rotated, work transferred, checks completed, and any outstanding issues. Store it in a place accessible to the site owner rather than in the departing contributor’s files. This record helps the team distinguish a finished handover from a task someone intended to do later.
Once the immediate work is complete, update your contributor onboarding checklist. Named accounts, clear ownership of services, and a current access list reduce the effort of future offboarding. Treat this as a routine part of maintaining a small website, not as a judgment about the person leaving.
