WordPress hosting for clients: who should own the account?

For a single client’s business website, a useful default is for the client to control the hosting and domain accounts, pay their renewal bills directly, and invite you through your own login. You can maintain the site without becoming the only person who can renew it, recover access or appoint a replacement.

If the client already has suitable hosting, start there. A clearer access arrangement may be all you need; building a website for someone does not by itself require an agency hosting plan.

This guide is for a freelancer planning or taking over a standard self-hosted WordPress site. Gather the current host and domain registrar names, renewal details and the names of the people with access. You will finish with a short account, billing and handover record to agree before buying or changing anything. Here, account ownership means practical control of a provider account, not a determination of legal rights to the website.

Separate the accounts before choosing who pays

The hosting account manages the service running WordPress. The domain registrar is the company through which the website’s domain name is registered and renewed. DNS is the set of records directing that name to the website and other services, such as email. DNS may be managed at the registrar, the host or a separate provider.

The WordPress dashboard controls the website’s content and settings. Its users are a separate access layer: being a WordPress Administrator does not establish control of the hosting bill or domain registration.

Paying an invoice and holding owner access are different questions. For example, Kinsta’s user roles include a billing role that can handle billing information but cannot access sites. Its site roles have a different scope. Check the actual permissions at your provider rather than assuming that a role called “administrator” controls everything.

Choose the arrangement that matches the work

For a build followed by handover, use client-controlled accounts from the start when possible. Let the client retain recovery access and add your individual user. This avoids making account transfer a hidden final stage of the website project.

For ongoing maintenance, the same arrangement can work. The client pays for hosting and the domain; you remain an invited maintainer. Separately agree who checks renewals, responds to failed payments, updates WordPress and handles a broken site. Account ownership alone does not assign these jobs.

If you intentionally supply hosting as part of your service, record the exit route before adding the site. State who pays the host, what access the client receives, and how this one site can move to an account they control. Do not promise that handing over one client means handing over an account containing other clients’ sites or billing details.

If the site is already under your account, first ask the host whether it supports an individual site transfer, what the receiving account needs, and which services or charges remain behind. Kinsta, for example, documents company ownership and individual site transfers as separate operations; transferring a site does not cancel its old hosting plan. Other hosts may use different processes. Resolve the account arrangement before planning a migration.

Give each person their own access

Use invitations or delegated access, meaning permission to work through a separate login. Do not send the client’s owner password to the freelancer or use one shared WordPress account for everyone.

Choose permissions by the job. In a standard single WordPress installation, an Administrator can manage the site broadly, including plugins and users; an Editor can manage and publish content. The WordPress role reference describes the defaults. Plugins can change roles, and Multisite has different administration boundaries, so confirm the site’s actual permissions.

Domain access also needs its own check. Namecheap’s domain sharing lets an owner grant selected permissions to another Namecheap account and later remove that access. This is an example of delegation, not a feature to assume every registrar provides. Ask your registrar which permissions can be separated if its documentation is unclear.

Keep account recovery with the client: they should control the recovery email and retain their own recovery information securely. Enable the provider’s extra sign-in verification where available. ICANN’s domain-account guidance recommends recoverable account information and multi-factor authentication. Record where recovery information is kept, not the secret codes themselves, in the handover note.

Write the handover record before buying

Use one private note that both parties can review. Fill in these six items with actual names and provider details:

1. Accounts: hosting, registrar, DNS and WordPress; who holds owner or administrator access to each, and who controls account recovery.
2. Bills: who pays each renewal, where notices go, the next renewal dates and who acts if a payment fails. Include separately billed email, themes or plugins used by the site.
3. Work: who handles updates, checks backups and responds when the site stops working; how the client contacts that person.
4. Access: each person’s individual login and role, plus any separate file-transfer or automated-service access used for maintenance. Keep passwords and secret keys out of this note.
5. Recovery: where the latest backup is held and who can restore it. A complete typical WordPress backup needs both files and the database; record the restore instructions or support route as well.
6. Departure: who arranges any necessary account or site transfer, which subscriptions need attention, and who removes the departing maintainer’s access after the client or replacement has working access.

For paid themes, plugins and connected services, check whether the current subscription can remain in place after handover or needs replacing. Do not assume moving the website also moves every purchase or service account.

Before closing a handover, have the client confirm they can sign in independently, locate billing and renewal settings, and reach the agreed recovery route. Review hosting, domain, DNS and WordPress access separately; removing one invitation is not a check of every account. Preserve site content when changing WordPress users.

Your decision is complete when the record identifies who can keep the site paid for, maintained and accessible if you stop working together. If a critical answer still depends on sharing an owner password or obtaining help from someone who is leaving, resolve it with the provider before buying or moving the site.

Sources and useful links

Official documentation checked on 24 September 2026. Provider examples illustrate access and transfer features; check your own plan’s current rules.

• WordPress roles and capabilities — default site permissions and differences from Multisite.
• Kinsta user management — an example of separate company, billing and site roles.
• Kinsta ownership and site transfers — distinctions to check before promising a client handover.
• Namecheap domain sharing — selected permissions and removal of a domain manager.
• ICANN domain-account protection — recovery and sign-in security for domain accounts.
• WordPress backups — why a site’s files and database both matter for recovery.