How to give someone access to your WordPress site safely

Handing over access feels risky because it usually is done badly — a WordPress password emailed in plain text, still valid three years later, belonging to someone you no longer work with.

Done properly it takes ten minutes and is fully reversible.

What they actually need

Almost always:

• A WordPress administrator account — their own, not yours
• Hosting control panel or SFTP — because a lot of what goes wrong lives outside WordPress. Anyone doing malware work without it is working with one hand tied.

Sometimes:

• Database access, usually available through the hosting panel anyway
• DNS or registrar, only for migrations or SSL work

Almost never:

• Your personal WordPress login. They should have their own account, so the audit trail shows who did what.
• Your email account.
• Payment gateway logins. A shop's WooCommerce admin shows orders; nobody needs your Stripe password.

If someone asks for something on the third list, ask why. There may be a good answer, but it should exist.

Doing it properly

1. Create a separate administrator account.

Users → Add New. Use their email, set the role to Administrator, and let WordPress generate the password — it will email them directly, so the password never passes through you.

A separate account means every change is attributable, and removing them later is one click rather than a password reset you have to remember to do.

2. Give hosting access the same way where you can.

Most control panels support additional users. Create one for them rather than sharing your main login. If yours does not support it — some cheap hosts do not — create an SFTP-only user instead, which is usually possible even when panel users are not.

3. Send credentials properly.

Not email, not WhatsApp, not a shared doc. Use a one-time link service, or your password manager's sharing feature. If you must email something, send the username in one channel and the password in another.

4. Write down what you gave them.

A note in your password manager listing every access granted, to whom, and on what date. This is the thing that makes revoking clean later, and it is the step everyone skips.

While they have access

• Do not change your own password mid-job unless you have to — it will not lock them out, but it will confuse things
• Expect a backup before anything significant. Any competent provider takes one first
• Ask what they changed. A provider who cannot tell you afterwards was not keeping track

Revoking it cleanly

This is where most people stop, and it is the part that matters.

1. Delete their WordPress user, assigning their content to another account rather than deleting it
2. Remove their hosting panel or SFTP user
3. Rotate the salts in wp-config.php — this logs out every existing session, including any they left open
4. Change the database password if they had it, and update wp-config.php to match
5. Check for accounts you did not create, in case something was added along the way
6. Update your access note so the record stays accurate

Steps 3 and 5 are the ones people miss. An account deleted but a session still live is not fully revoked.

If you have lost access yourself

The reverse problem, and more common than you would think — the developer who built the site has stopped answering, and nobody knows the password.

If you still control the hosting, you can recover WordPress: reset the admin password via phpMyAdmin, or add a new administrator with a small snippet in the theme's functions.php. If you control the domain but not the hosting, you can point DNS elsewhere and rebuild from a backup.

If you control neither, it is a harder conversation — and the reason worth checking now, while nothing is wrong, that your domain and hosting accounts are genuinely in your name rather than held on your behalf by someone you may lose touch with.

When you hand a site to us

We ask for a WordPress administrator account and hosting or SFTP access, and nothing else. Credentials go into an encrypted vault with access logging rather than an inbox, and when a plan ends we revoke our own access, delete the stored credentials and confirm it in writing. The full detail is in our privacy policy rather than buried in terms.