Hosting a client's site is a service with obligations attached. Agencies acquire those obligations by accident and then carry them unpaid.
The domain belongs to the client
Without exception.
Registered in an account they own, paid by them, with a contact address that is theirs. You have administrative access to make changes.
The alternative, an agency holding client domains, is a liability in three directions. If you disappear, they lose the name. If you fall out, you are holding something of theirs and the conversation becomes ugly. And if you forget a renewal, you have lost a client's business name.
| Asset | Held by | Agency role |
|---|---|---|
| Domain | Client | Access |
| Hosting account | Client, usually | Access |
| The site files | Client, copy with agency | Builds and deploys |
| Analytics | Client account | Access |
| Certificates | Automatic | Confirm they renew |
Who holds hosting
There is a defensible case either way and the failure is not deciding.
The client holds it. They pay the provider, you have access. Nothing breaks when the relationship ends, and you are not in the billing chain. This is the cleaner arrangement for most work.
You hold it. Sometimes justified: you are providing a managed service, you are consolidating many small sites, or the client genuinely cannot administer anything. It must be priced, scoped and put in writing, because it includes uptime, renewals and being called when something is wrong.
What happens by default is the second, unpriced. That is how an agency ends up with thirty sites it cannot charge for and cannot stop supporting.
Static makes this manageable
Most client sites are brochures. As static files they cost very little to host, have no database to fail, no runtime to patch and no administration login to be attacked.
Thirty static sites is close to no maintenance. Thirty sites on traditional hosting with plugins is somebody's job, and eventually somebody's emergency.
Where a site does not genuinely need a server, building it static is the single largest reduction in ongoing obligation available.
Write down who is called
Before anything breaks, agree three things in writing.
Who pays for what. Domain, hosting, any services.
Who is called when it is down, and when. Business hours or not, expected response, and whether it is included or billed.
What happens at the end. How the site and every account transfer, and how long you keep a copy.
None of that is difficult at the start of a relationship. All of it is difficult at the end of one.
Two neighbouring cases are worth a look: A freelance site that maintains itself and How to set up a client portal.
Put it at an address
Register every client domain in their account, decide who holds hosting deliberately and price it, build static where you can, write down who is called when it breaks, and agree the handover before you need it.