How to safely give developers access to your website?

To safely give developers access to your website, create a separate account for each developer instead of sharing your own logins, grant only the access their task requires, prefer a staging copy over live production, share any unavoidable credentials through a password manager, take a full backup before work starts, and remove or rotate everything as soon as the job is done. Done this way, you can hire outside help without handing over the keys to your whole business.

Many website owners hire a freelancer or agency at some point, whether for a redesign, a bug fix, a performance tune-up, or ongoing maintenance. The temptation is to email over your hosting password and WordPress admin login and hope for the best. This guide shows you a better approach: how to work out what access a developer really needs, how to set up each type of access safely, how to protect yourself while the work is happening, and how to close everything down afterwards.

Why Sharing Your Own Login Is a Bad Idea

Handing over your personal credentials feels quick, but it creates several problems:

• No accountability: If something breaks or data changes, you can't tell whether it was you or the developer.
• Hard to revoke: To remove their access, you have to change your own password everywhere it's used, which often doesn't happen.
• Too much access: Your account can probably do far more than the developer needs, including billing, domain transfers, and account deletion.
• Two-factor friction: Developers end up asking you for codes, or you turn off two-factor authentication to make it easier, which weakens security.
• Leaked credentials spread: Passwords sent by email or chat stay in inboxes and message histories indefinitely.

The goal is simple: every developer gets their own identity, with limited, time-bound access that you can switch off without disrupting anything else.

Step 1: Define What the Developer Actually Needs

Before creating any accounts, get clear on the scope of the work. Ask the developer to confirm which systems they need to touch. Different tasks require very different access:

Task	Access typically needed
Content or layout changes	CMS account (Editor or Administrator)
Plugin or theme customisation	Staging site, Git repository, or SFTP
Performance or server tuning	Hosting control panel or SSH
Email or DNS setup	DNS provider with limited role
Payment integration	Payment dashboard test mode, restricted API keys
Bug investigation	Staging copy and read-only logs

Very few jobs require your domain registrar, billing, or the primary account owner login. If a developer asks for those, ask why.

Agree on Terms Up Front

For anything beyond a small task, a short written agreement protects both sides. It should cover:

1. Scope: Which systems and which changes are included.
2. Duration: When access starts and ends.
3. Data handling: The developer won't copy customer data off the server unless required, and will delete any copies afterwards.
4. Confidentiality: A basic NDA if your site holds sensitive business or customer information.
5. Handover: Where code changes will live and what documentation you'll receive.

If your site processes personal data of people in the UK or EU, a developer who can access that data is acting as a processor, and data protection law expects you to have appropriate terms in place.

Step 2: Take a Full Backup Before Work Starts

Before anyone else touches your site, take a complete backup of your files and database and store a copy somewhere the developer can't reach, such as your own cloud storage or computer. This protects you from accidents as much as from malicious behaviour.

If you have SSH access and WP-CLI, a quick manual backup looks like this:

cd /var/www/example.com
wp db export ~/backups/example-$(date +%F).sql
tar -czf ~/backups/example-files-$(date +%F).tar.gz --exclude=wp-content/cache .

Most hosts also offer one-click snapshots, and backup plugins like UpdraftPlus or BlogVault can send backups to remote storage. Check that you can actually restore from the backup, not just that it exists.

Step 3: Use a Staging Site Whenever Possible

The safest place for a developer to work is a copy of your site, not the live one. Most managed WordPress hosts, including Kinsta, WP Engine, SiteGround, and Cloudways, offer one-click staging environments.

Benefits of staging:

• Mistakes don't affect visitors: Broken layouts and fatal errors stay contained.
• You can review before going live: Changes are pushed to production only after you approve them.
• Access can be limited to staging: The developer may not need production access at all.

Sanitise Customer Data on Staging

A staging copy usually includes your full database, meaning customer names, emails, and orders. If the developer doesn't need real data, anonymise it. With WP-CLI on the staging site, you could replace user emails:

wp db query "UPDATE wp_users SET user_email = CONCAT('user', ID, '@example.test') WHERE ID > 1;"

Adjust the table prefix to match your site, and only ever run this on staging. For WooCommerce stores, dedicated plugins and hosting tools can anonymise order data more thoroughly. Also make sure staging is protected by a password or restricted by IP, and that it doesn't send real emails to customers.

Step 4: Set Up Each Type of Access Safely

WordPress or CMS Access

Create a dedicated user under Users > Add New User:

1. Username: Something identifiable like dev-jane-agency.
2. Email: The developer's own work email, so password resets go to them, not you.
3. Role: The lowest role that lets them do the job. Use Administrator only if they need to install plugins or change settings.
4. Two-factor authentication: Require it if your security plugin supports role-based enforcement.

For short jobs, a plugin like Temporary Login Without Password lets you create a login link that expires automatically after a set period.

If you're comfortable with WP-CLI, you can create the user in one command:

wp user create dev-jane jane@agency.example --role=editor --display_name="Jane (Agency)"

Hosting Control Panel

Many hosts let you invite collaborators with their own logins and restricted permissions. Kinsta, WP Engine, Cloudways, and SiteGround all support some form of team or collaborator access. Use this instead of sharing your main hosting account, and limit the collaborator to the specific site they're working on.

If your host only supports one login, ask whether they can create a separate SFTP user instead, or consider whether the developer really needs the control panel at all.

SFTP Access

Never use plain FTP, which sends passwords unencrypted. Create an SFTP account that's limited to the site's directory. In cPanel, Files > FTP Accounts lets you create an account restricted to a specific folder, and many hosts allow SFTP with those credentials.

SSH Access

For SSH, ask the developer to send you their public key, which is safe to share. Never generate a key pair for them and send the private key. Then add it to the server:

# On the server, as the user the developer will log in as
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3Nza...developer-key jane@agency" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Better still, create a separate Linux user for them so their access is clearly separated and easy to remove:

sudo adduser --disabled-password --gecos "" dev-jane
sudo mkdir -p /home/dev-jane/.ssh
sudo nano /home/dev-jane/.ssh/authorized_keys   # paste their public key
sudo chown -R dev-jane:dev-jane /home/dev-jane/.ssh
sudo chmod 700 /home/dev-jane/.ssh
sudo chmod 600 /home/dev-jane/.ssh/authorized_keys

Only add them to the sudo group if the job genuinely requires root access, and consider granting specific commands through sudoers instead.

Code Repositories

If your site's code lives in GitHub, GitLab, or Bitbucket, invite the developer to that specific repository with write access, not as an owner of your organisation. Protect the main branch so changes require a pull request you approve before they're merged and deployed. This gives you a full history of every change.

DNS and Third-Party Services

For DNS changes, use role-based access where the provider supports it. Cloudflare, for instance, lets you invite members with a DNS-only role for a single domain. For payment gateways, email services, and other APIs, create restricted keys for the developer's work, preferably in test mode, rather than sharing your live secret keys.

Step 5: Share Credentials Securely

When a password must be shared, don't put it in email, SMS, Slack, or a project management ticket. Instead:

• Use a password manager's sharing feature: 1Password, Bitwarden, and similar tools can share items with specific people and revoke them later.
• Use expiring encrypted links: Bitwarden Send or 1Password's item sharing can create links that expire after a set time or number of views.
• Share the password and username separately: If you must use different channels, never send both in the same message.

Step 6: Monitor Activity While Work Is Happening

Trust matters, but visibility helps everyone. While a developer is working:

1. Enable an activity log: Plugins like WP Activity Log or Simple History record logins, plugin installs, setting changes, and content edits.
2. Watch for unexpected new users: A new administrator account you didn't create is a red flag.
3. Check file changes: Security plugins like Wordfence can alert you when core, theme, or plugin files change.
4. Ask for regular updates: A brief summary of what was changed and why makes the handover much smoother.

Step 7: Revoke Access When the Job Is Done

This is the step most often forgotten. Old developer accounts are a common way into websites, because they tend to have high privileges and nobody is watching them.

When the work is finished:

1. Delete or downgrade their CMS account: In WordPress, when deleting the user, choose to attribute their content to another user.
2. Remove their hosting collaborator access.
3. Delete their SFTP account.
4. Remove their SSH key or Linux user: sudo deluser --remove-home dev-jane removes the user and their home directory.
5. Remove repository access.
6. Revoke API keys created for them.
7. Rotate any shared credentials they knew, such as database passwords.
8. Log out all sessions: In WordPress, the Log Out Everywhere Else button on a user profile, or wp user session destroy <user> --all in WP-CLI.

Once the developer's accounts are removed, review your users list and plugin list for anything unfamiliar.

If You Want Ongoing Maintenance

For agencies that maintain your site long term, the same principles apply. Give them individual accounts for each team member rather than one shared agency login, ask them to use two-factor authentication, and review their access every few months.

Red Flags to Watch For

Most developers are professional and careful, but be cautious if someone:

• Insists on your personal login rather than their own account.
• Asks for registrar or billing access without a clear reason.
• Wants two-factor authentication turned off.
• Installs nulled (pirated) premium plugins or themes, which frequently contain malware.
• Adds admin users or plugins you didn't discuss.
• Refuses to work on staging when one is available.

---

FAQ: Giving Developers Access to Your Website

---

Conclusion

Giving developers access to your website doesn't have to be risky. The safest approach is also the most organised one: define what they need, give them their own accounts with the smallest possible permissions, work on staging whenever you can, share credentials only through secure tools, and keep a backup that's out of their reach.

Most importantly, treat access as temporary. When the job ends, close every door you opened, from CMS users to SSH keys and API tokens. Build that offboarding step into every project, and you'll be able to bring in outside expertise whenever you need it without leaving lingering security holes behind.