Managing many client sites
How do web agencies organize domains, logins, backups and renewals for many client websites?
Give every client separate projects and accounts, keep credentials in a password manager with shared vaults, back up on a schedule, and track every renewal date in one place.
What you will be able to do
Keep ten, thirty or more client sites organized: separate projects per client, access controls, staging and live environments, credentials in a password manager, scheduled backups and renewal reminders, so nothing depends on memory.
Before you start
- Do the drill in Deploy, break and recover a site.
- Pick a password manager that supports shared vaults for teams. Compare current plans yourself.
Why this matters
With three clients you remember everything. With thirty, someone's domain expires because the renewal email went to an old address, and you find out when the owner calls. Most disasters at this size are organizational: a password in an old email thread, a site sharing an account with four others, a backup nobody checked.
The fix is boring and it works: one register of every client and service, one password manager, one naming convention, one backup schedule, one renewal calendar. Set it up once and update it at every launch.
Step by step
Tick each step as you do it. Your ticks are saved in this browser.
Create a client register
One row per client: name, primary contact, domain, registrar, DNS location, host and project name, email host, stack, care plan level, renewal dates (domain, hosting, care plan, paid plugins or services), backup location, last backup check, notes. Update it at every launch and every change.
Use one naming code everywhere
A short code per client, such as
atxdentalfor a dental clinic in Austin, used in project names, repositories, password manager entries, folders and invoices. You find anything in seconds.Give every client separate projects and, where practical, separate accounts
Each client gets its own hosting project, repository and folder. Where a host allows teams, create one per client and add yourself, so it hands over cleanly if a client pays the buyout fee later. Never mix clients in one project or server folder.
Put every credential in a password manager
Every login (registrar, host, CMS admin, analytics, form service) goes in a vault for that client, with two factor authentication on wherever offered. If a client emails you a password, move it into the manager, ask them to change it, and delete the email. Share through the manager, never by email or chat.
Set access by role and remove it when people leave
A contractor building one site gets that client's vault and project, not your whole agency. Use personal logins, not one shared agency login, so you can see who did what and remove one person cleanly. Remove access the same day someone leaves.
Separate staging from live
For sites that change often, try changes on a staging copy or preview deploy first. Many static hosts create preview deploys per branch. Show the client on staging, get approval, then publish.
Schedule backups and test them
Write a backup schedule per client in the register: how often, where, how long kept. Monthly, restore one client's backup at random to a test location and record the date. A backup you have never restored is a hope.
Put every renewal in one calendar
Domains, hosting, paid plugins, SSL if not automatic, care plan invoices, each with an early reminder and a second one closer to the date. Auto renew fails when cards expire, so check anyway. Automating admin safely covers sending reminders automatically.
Review the register monthly
Thirty minutes: upcoming renewals, last backup checks, anyone with access who should not have it, stacks that need updates. Fix it before it becomes a client email.
Example
One row of a register for twelve illustrative local businesses:
CODE atxdental
CLIENT Family dental clinic, Austin
CONTACT Office manager (in password manager notes)
DOMAIN clinic domain, registrar account owned by clinic, you delegated
DNS at registrar
HOST static host, project atxdental (own team, client invited)
EMAIL clinic's own provider, managed by clinic
STACK static site, form service
CARE PLAN Standard yearly care
RENEWALS domain (date), care plan (date), form service (date)
BACKUP repository plus monthly export to agency storage, kept 12 months
LAST RESTORE (date), restored to test subdomain, OK
NOTES MX records must not change. Owner prefers calls before 9am.
The matching vault holds the registrar delegate login, host team login, form service and analytics, plus a note on where backups live.
Bad version: a spreadsheet called "logins FINAL v3" with passwords in plain text, emailed to a contractor last year.
Common mistakes
- Passwords in email, chat or spreadsheets. They get forwarded, searched and leaked.
- One shared agency login. You cannot tell who changed what or remove one person cleanly.
- Backups never tested. You find out a backup is broken at the worst moment.
- Trusting auto renew. Cards expire and contact emails change. Keep your own calendar.
Try it yourself
Build your client register with at least three rows (illustrative ones if you have no clients yet). Create the matching password manager vaults with placeholder entries, add every renewal date to a calendar with two reminders each, and restore one backup to a test location.
Deliverable: a client register with three rows, three vaults, a renewal calendar and one recorded restore test.
Time: about 45 minutes.
Resources
- Client handoff checklist what to record at every launch
- Hosting comparison sheet keep the host decision per client
- Deploy, break and recover a site the restore drill
- Automating admin safely automate renewal reminders
Finished this lesson?
Mark it complete to track your progress through the course.
Last reviewed October 18, 2026. Prices, laws and tool terms change, so check current terms before you rely on any figure.