Your cousin handles the website Tuesdays. Your employee posts products. Your developer needs 'just for a quick fix'. Shared access is necessary — shared CHAOS is optional. Here is the safe structure.
The unsafe way (the classic disasters) - One master password shared on a family WhatsApp group - The ex-employee who still has the login (and the grudge) - The developer's 'quick fix' that edits live files without backup - No record of who changed what — every incident becomes an unsolvable whodunit
The safe structure 1. **Owner account (you):** the hosting panel, billing, domain — NEVER shared. It is the deed to the property 2. **Worker access:** scoped per person — a WordPress author/editor role for content staff (no admin), the file manager only for actual developers 3. **Passwords per person:** each human their own credentials — access you can revoke individually. A shared password is a key photocopied for the whole street 4. **The change log:** a simple note (date, person, what changed) — the whodunit ends before it starts
The developer-visit protocol Before: full backup (the ritual). During: their scope stated ('files under /themes only'). After: password rotation if root/admin was touched, and a diff-glance at what changed (file manager's timestamps make this five minutes).
The offboarding checklist (the one that saves businesses) □ Remove their CMS accounts (not just deactivate) □ Rotate any shared credentials they touched □ Revoke API tokens/app passwords □ Check the admin user list for surprises □ Their backups? Delete from YOUR storage (yours stay) Five minutes, done while the parting is friendly.
The Kairalmas fit Per-site admin logins, scoped CMS roles, file versioning as the safety net, and the portal login that stays yours alone — the architecture supports the discipline; the checklist above supplies the discipline.
Shared work is fine. Shared passwords are how small businesses lose websites. Structure the first, abolish the second.