Handing a site to a developer usually starts with sending them the cPanel password, and that one habit causes most of the problems that follow, access you cannot revoke, changes nobody can attribute, and a site you cannot maintain when the work ends.
The alternative takes about ten minutes to set up.
Give the least access that does the job
Ask what they actually need, then give exactly that.
Content and design work: a WordPress account with an appropriate role. Administrator if they are installing plugins; editor if they are writing. There is more on choosing in WordPress user roles.
File changes. An FTP account limited to the site's directory.
Server-level work: cPanel access, which is the one to think about hardest.
Each of those is an account in their name, removable individually. That is the property the shared password lacks.
Never share the main password
It cannot be revoked for one person, it is reused, and it leaves no record of who did what.
When someone genuinely needs cPanel, most billing systems can create a sub-account or a separate cPanel user rather than handing over yours. If yours cannot, change the password when the work ends, and mean it, rather than intending to. Securing your hosting account walks through the alternatives.
Keep the domain and the account in your name
The single most important thing here, and it costs nothing at the start.
Register the domain yourself, in your name or your company's, with your email as the registrant contact. Own the hosting account. Then give the developer access to it.
The alternative; a developer who registers the domain and buys the hosting on your behalf, means that when the relationship ends, your website and your identity are legally theirs. That situation resolves through negotiation rather than support tickets, and it happens often.
If you are already in it, ask for the domain to be transferred to your own registrar account now, while things are amicable. Getting an EPP code explains what they will need to provide.
Set up a staging site
Development work should not happen on the live site, and the argument for that is not theoretical: a plugin conflict on a live shop during business hours costs orders.
A staging copy lets the developer break things safely. Two conditions: it must be excluded from search engines, and it must not send email to real customers. A test order that emails a real address is a bad afternoon. Setting up a staging site goes into making one.
Be careful pushing from staging to live: pushing the database overwrites orders and comments that arrived while you were testing.
Take a backup before they start
Not because you distrust them, because "we can go back to how it was" removes the tension from every conversation that follows.
Take one yourself and keep it somewhere they cannot reach. A backup that only exists in the account you gave them access to is not an independent copy. Backing up and restoring explains generating one.
Agree what happens to updates
The gap that leaves sites unmaintained for years.
A build finishes, the developer moves on, and nobody applies plugin updates. Eighteen months later the site is compromised through a known vulnerability that had a fix available the whole time.
Decide before the work starts: does the developer maintain it afterwards, do you, or does nobody, in which case say so, so it is a decision rather than a drift. Keeping WordPress updated walks through what it involves.
Ask for a handover
Written, at the end, and worth specifying in advance so it is expected.
What was built and where. Which plugins are essential and why. Any custom code and where it lives. A child theme, ideally, so a theme update does not remove it. Any accounts or services created in your name. And anything that needs doing periodically.
A page of notes is enough. Without it, the next person starts by reverse-engineering decisions nobody recorded, and you pay for that twice.
When the work ends
Four things, promptly rather than eventually.
Remove or downgrade their accounts: WordPress, FTP, cPanel. Remove their SSH keys and API tokens if any were created. Change any shared credential they held. And check for accounts created during the work that nobody mentioned. A second administrator account is not necessarily sinister and should not be a surprise.
Doing this on a good ending is normal practice, not an accusation. It is also the only time it is easy.
Keep a record of what you own
Domain registrar and login. Hosting account and login. Which email address is the registrant contact. Where backups go. What each plugin is for.
A single document, updated when things change. It is what makes the next developer's first day an hour instead of a week, and what makes an emergency at two in the morning solvable by whoever is available.
When the previous developer has already gone and left nothing behind, the starting point is an inventory. For building one without any credentials, see What to Do When You Inherit a Website Nobody Documented.
Give access that expires by itself
Access granted for a project outlives the project, because removing it is nobody's task once the work is done.
wp user list --role=administrator --fields=user_login,user_email,user_registered wp user list --field=user_login --role=editor
Where the tools allow it, set an end date at the point of granting rather than relying on remembering. Where they do not, put the removal in a calendar for the day after the work is due to finish.
Read the administrator list occasionally and ask, for each entry, whether that person is still involved. On a site that has had two or three developers, the answer is usually no for at least one of them.
Ask for the work in a form you can keep
The difference between a site you own and one you rent from a person is whether you have what they produced.
Ask at the start rather than at the end: the code somewhere you control, an explanation of anything unusual, the accounts for any third party service the site uses, and a description of how a change is deployed.
The deployment method is the one people forget and the one that matters most. A site that only one person knows how to update is a site you cannot change without them, whatever the contract says about ownership. Auditing a site you inherited covers what to do when that handover never happened.