WordPress Developer Access Without Your Hosting Login

A developer needs to repair your WordPress website. They ask for access, and you reach for the password saved in your hosting welcome email. Before sending it, establish what the job actually requires.

For many tasks, an individual WordPress account is enough. Work involving files may need a separate transfer account or assistance from your hosting provider. Your main hosting login should remain under your control.

The aim is practical: give a trusted person enough access to complete an agreed task, then remove that access when the work ends.

Agree on the job before choosing an account

Ask the developer to describe the change, the area they need to reach, and how they will test it. Replacing photographs on existing pages differs from repairing a plugin or changing server settings.

Record the website, task, permitted changes and finishing date. For a small business working with a freelancer in another city or country, include the time zone for the maintenance window, such as Pakistan Standard Time.

If a request says only “send all logins,” ask for a more specific access list. Domain registration, billing and business email access should not become part of a routine page edit.

Prepare recovery and a suitable working copy

Before significant changes, confirm that a current backup includes both WordPress files and the database, and that someone knows how to restore it. Keep the copy protected and accessible independently of the developer. The WordPress backup guidance explains these two components.

Use a separate staging environment for changes that could interrupt visitors. Check that it has its own files, database and credentials. Protect access and prevent test activity from sending customer emails, charging payments or triggering real deliveries.

A staging copy may contain customer records. Remove or mask unnecessary personal information before providing access. Keep production connected to its existing database and do not approve an entire staging database replacing live orders merely to release a design change.

Choose the smallest suitable WordPress role

WordPress permissions depend on the assigned role. Its official roles documentation describes the defaults:

Contributor suits someone preparing their own draft posts. They cannot publish those posts or upload media through the default role.

Author can publish and manage their own posts and upload media. This does not normally provide permission to edit your existing business pages.

Editor can manage pages and posts, including content belonging to other users. It is useful for broader content work, but also carries substantial powers to change or delete content.

Administrator can manage the site, including plugins and themes on a typical single site installation. Grant it only when the agreed work requires those powers and you trust the developer with them.

Plugins and custom roles can change these defaults. A page builder or the WordPress Site Editor may require permissions beyond an ordinary Editor account. Check the actual task before increasing access. An Administrator account is not an isolation boundary around customer data or application secrets.

Create an individual account and test it

Keep your own working Administrator account. In the WordPress Users area, add a separate user with the developer's individual email address and the chosen role. Use a recognisable username rather than one shared by an entire agency.

Provide the correct login address and arrange password setup securely. If credentials must be shared, use a password manager with a protected sharing feature rather than leaving passwords in a project group chat. Enable two factor authentication for the account where your setup supports it.

Ask the developer to confirm that the required screen opens and the agreed operation works. Record any additional permission request. Set a reminder to remove access; calling an account temporary does not create an expiry date.

Treat file access as a separate decision

Ask whether the developer can deliver reviewed files for you or the host to install. Direct server access may be unnecessary.

Where separate transfer accounts are supported, request an individual account limited to the relevant directory. In cPanel, the FTP Accounts documentation explains that the selected directory defines that account's top level of access. Confirm the path carefully before creating it.

Alif Host's guide to creating and managing FTP accounts provides the account setup procedure. Confirm which encrypted transfer method the hosting server supports before using those credentials.

Do not confuse FTP, FTPS and SFTP. SFTP uses SSH, while FTPS protects FTP with TLS. The cPanel SFTP documentation explicitly states that an FTP account cannot be used to connect through SFTP.

Ask the host whether a genuinely separate, restricted SFTP account is available. If it is not, ask about a supported FTPS account with a directory restriction, or a supervised deployment. Do not share the main cPanel password simply to make an SFTP connection work. Avoid unencrypted FTP.

A directory restriction limits file browsing, but permission to change executable website code can still affect the application. Prefer an isolated working environment for development rather than treating a folder restriction as complete protection.

Use application passwords only for integrations

An application password is not a temporary password for the WordPress login screen. It authenticates a tool or script through supported interfaces, such as the WordPress REST API.

The WordPress application password documentation explains that each credential can be revoked separately. Create one for a specific necessary integration, name it clearly, protect it and use HTTPS.

An application password acts as its associated user. Do not assume that it automatically provides a smaller set of permissions. Choose the underlying user's access appropriately and revoke the credential when the integration is no longer required.

Review the result and close every access route

Before approving the work, inspect the changed pages and test the relevant business journey. Ask for a short handover covering changed files, installed components, settings and any new credentials or connected services.

Remove temporary WordPress access after acceptance. First revoke any application passwords that are no longer needed. When deleting a user, carefully review the content attribution choices. WordPress can delete content associated with that user or assign it to another user. Choose reassignment when the business needs to retain that content, then verify the affected pages and posts. The Users screen documentation describes this decision.

Remove transfer accounts, SSH keys and external invitations separately. Removing a WordPress user does not close a separate hosting account.

When removing a cPanel FTP account, distinguish account removal from the option that also deletes its files. Removing credentials should not erase the website. Rotate shared secrets that remain in use, coordinating updates to any services that depend on them. Retain a record of the completed work and access removal.

Common questions

Does an Editor account always cover website design work?

No. It may cover page content, but theme settings, site templates and particular builders can require other capabilities. Ask which operation is blocked before granting broader access.

Should access stay open for future maintenance?

Only under an explicit maintenance arrangement with named users and regular access reviews. For an isolated job, remove temporary access and create it again when another task is approved.

What if the developer insists on the main hosting password?

Ask which exact hosting action requires it. Your provider may offer delegated access, perform the action for you or suggest another supported route. If broad access is unavoidable, understand its reach before authorising it and plan how credentials will be secured afterward.